rvanderbijl

When we first started with PowerPMAC the setup feature looked pretty cool, but this scattering of multiple files and lack of source control made it not suitable for a team environment. The diagnostics afforded by the setup routines would have made a great tool for our field service engineers, but the inability to include this data with a project has made it useless. Jeff, Agreed. I'm also finding that the multitude of temporary files and auto-generated files is confusing source control applications as well. Especially when you don't include an auto-generated file like a text file in the log folder. Opening the project on a new machine, the system starts complaining that the file doesn't exist and won't generate it. Very odd... So I have to put these files IN source control in order to not make the IDE unhappy. But now I have constantly changing files without any changes to the actual project. It would be good if these kinds of issues could be taken into consideration for a future version of the IDE. Robbert

Steve, Thanks for the pointer. However, where is this database stored? Can it be included in a source control solution so there is no need to do an additional export/import for every change made? Thanks, Robbert

I have two development systems (one on my laptop and one on a target machine; primarily for debug reasons). I use source control for the Delta Tau project, and most things seem to come across just fine. But the one thing I haven't been able to figure out yet is the Motor data in the System Setup. On my laptop (where I initially set up the motors), the data is populated properly. On the target machine, where I pulled the project from source control, I get the message when opening System Setup that no motors were configured. What file(s) do I need to include to make sure I have the motor setup data transfer over as well? And on that note, a list of files that should and shouldn't be in source control would be nice too, as it seems that the Power PMAC IDE creates a LOT of temporary files. Some of which it wants to see when opening a project, and some of which it doesn't appear to care about. Thanks! Robbert

Andrea, Did you ever find a solution to this? I have a similar problem -- Copying a project to a new development machine, and the System Setup tool is empty as well (yet the IP address did not change in my case). It would be good to understand where and how this System Setup information is stored. Thanks, Robbert

I am trying to figure out what the best method would be to back up and clone one Power PMAC to another. Based on this forum, I understand that connecting the PMAC via USB to a PC and using WinImage is the right way to go. However, while this works for the backing up part (and restoring), it doesn't work for cloning. If I restore that image to another card, I cannot connect to the Ethernet interface. KEJR was nice enough to point out that it may have something to do with the /etc/udev/rules.d/70-persistent-net.rules file. In that file, it looks like eth0 and other interfaces are being defined using their MAC ID's. Obviously when you clone a card, it won't be the same MAC ID, therefore, no connection... Does anyone have any suggestions, other than connecting through a serial cable after a clone and editing this file?

And another update ... I spoke too soon. It looked hopeful, but after approx. 1/2 hour, I still got a segmentation fault. And on two separate occasions afterwards, this also managed to "crash" the Delta Tau tasks -- The firmware just stopped running (no watchdog error popped up). Issuing a $$$ got it running again. Guessing there are some fundamental reasons why this doesn't work. It would still be good to understand the background of why, and potentially how this could be done. So if anyone has some ideas? Robbert

I'm cautiously optimistic that I found the reason for the segmentation fault. I didn't realize that the code to switch CPU affinity was preceded by an allocation of a fairly significant object in my code. I guess the object was allocated on core 0, then the rest of the code that uses that object was running on core 1. Apparently Xenomai does not like that. After I switched that around (change affinity - then allocate), I have not seen the crash yet, after about 15 mins of running. I'll leave it run for a few more hours to be sure, but this may have been a non-issue with respect to Delta Tau.

Thanks for your thoughts. I'm not accessing any memory by memcpy's. I'm currently only doing assignments, like: pshm->P[nnn] = value Or pshm->ECAT[n].IO[m].Data = value So no explicit memcpy's. Not sure what the compiler makes of these assignments, but I would hope I don't have to put special code in place to make sure the data is accessed in 64-bit blocks... No luck yet googling multi-core Xenomai shared memory issues....

Hello, Perhaps this is not 100% on-topic, but just in case people in this forum have come across this before -- I am running the Power PMAC on the Dual Core 465 CPU. Besides the normal Delta Tau code, I am also running a Xenomai C++ task. When I started to look at performance and CPU use, I noticed that my task was using up 20% CPU or so (using cat /proc/xenomai/stat). I also noticed it was on the same CPU as the PMAC tasks. So I added this to my C++ code: cpu_set_t set; CPU_ZERO(&set); CPU_SET(1, &set); if (sched_setaffinity(getpid(), sizeof(set), &set) == -1) CPUAffinityFault = true; This looks to work great, as when I do cat /prox/xenomai/stat, I now see that my threads are all running on CPU 1, not 0 as is the default apparently. Unfortunately, after running my code for 2-3 minutes, it crashes with a fun segmentation fault... If I remove the affinity code, it runs fine and does not crash. Does anyone have any thoughts on this? I am accessing PMAC shared memory (pshm->....). Perhaps you can't do that across different cores? Or if you do, is there some synchronization code I need to add? Thanks! Robbert