Rocrail in the raspberry!

Questions and discussions around compiling of Rocrail, usage of wxWidgets etc.

Moderators: dadolphs, Moderators

Postby mserrano » 28.04.2013, 09:19

I am still working on the writing and reading cv. The code for writing cv (any mode) in the ucontroller is ready... I will see if I can test it and publish it this week.... the reading part is still work on-going.

In the meantime, Rob asked me to check the pigpio library... in order to see if it is possible to implement all directly in the RasPi.

I am copying hereafter the results of the analysis... I think it could be usefull for more people.

In summary, my personal point of view is that time critical functionalities must be generated by specific pieces of HW, like the uart or a ucontroller.

"I have made some test with the library you proposed, and also with wiringPI.

Attached you can find some captures with the oscilloscope.

As expected, generating time critical signals with the rpi is not reliable... though depending on the intended purpose, it could be OK.

The pigpio library does not seem accurate at all for micorsecons. Actually, the author of the library already points to the use of usleep() when using delays<200us:

" NOTES:

For short relative sleeps (say, 200 microseonds) I use usleep.
It's less to type and just as reliable."

He says it is because it is simple to type... but honestly, I think the accuracy is simply not good enough. I can not see the c code of the library, since he is not publishing it. Thus, I do not know how the sleep function is implemented.
In the captures I have tried to low the sleep to 20us...and it stills produces pulses of 94us.

For wiringpi the situation is a little bit better. It produces the 60us.

Actually, I have run a test of 1000 delays with different timing (modifying the example provided with the library)... and the result is not too bad (form 13us to 59us):

Delay: 13. Min: 13, Max: 60, Unders: 0, Overs: 3, Exacts: 997, Average: 15, Descheds: 0
Delay: 14. Min: 14, Max: 51, Unders: 0, Overs: 2, Exacts: 998, Average: 16, Descheds: 0
Delay: 15. Min: 15, Max: 64, Unders: 0, Overs: 2, Exacts: 998, Average: 17, Descheds: 0
Delay: 16. Min: 16, Max: 59, Unders: 0, Overs: 3, Exacts: 997, Average: 18, Descheds: 0
Delay: 17. Min: 17, Max: 64, Unders: 0, Overs: 2, Exacts: 998, Average: 19, Descheds: 0
Delay: 18. Min: 18, Max: 57, Unders: 0, Overs: 3, Exacts: 997, Average: 20, Descheds: 0
Delay: 19. Min: 19, Max: 58, Unders: 0, Overs: 3, Exacts: 997, Average: 21, Descheds: 0
Delay: 20. Min: 20, Max: 63, Unders: 0, Overs: 3, Exacts: 997, Average: 22, Descheds: 0
Delay: 21. Min: 21, Max: 71, Unders: 0, Overs: 3, Exacts: 997, Average: 23, Descheds: 0
Delay: 22. Min: 22, Max: 83, Unders: 0, Overs: 4, Exacts: 996, Average: 24, Descheds: 0
Delay: 23. Min: 23, Max: 170, Unders: 0, Overs: 2, Exacts: 998, Average: 25, Descheds: 0
Delay: 24. Min: 24, Max: 79, Unders: 0, Overs: 3, Exacts: 997, Average: 26, Descheds: 0
Delay: 25. Min: 25, Max: 85, Unders: 0, Overs: 3, Exacts: 997, Average: 27, Descheds: 0
Delay: 26. Min: 26, Max: 197, Unders: 0, Overs: 2, Exacts: 998, Average: 28, Descheds: 0
Delay: 27. Min: 27, Max: 75, Unders: 0, Overs: 3, Exacts: 997, Average: 29, Descheds: 0
Delay: 28. Min: 28, Max: 68, Unders: 0, Overs: 2, Exacts: 998, Average: 30, Descheds: 0
Delay: 29. Min: 29, Max: 79, Unders: 0, Overs: 2, Exacts: 998, Average: 31, Descheds: 0
Delay: 30. Min: 30, Max: 68, Unders: 0, Overs: 2, Exacts: 998, Average: 32, Descheds: 0
Delay: 31. Min: 31, Max: 51, Unders: 0, Overs: 3, Exacts: 997, Average: 32, Descheds: 0
Delay: 32. Min: 32, Max: 75, Unders: 0, Overs: 3, Exacts: 997, Average: 33, Descheds: 0
Delay: 33. Min: 33, Max: 62, Unders: 0, Overs: 2, Exacts: 998, Average: 34, Descheds: 0
Delay: 34. Min: 34, Max: 111, Unders: 0, Overs: 3, Exacts: 997, Average: 35, Descheds: 0
Delay: 35. Min: 35, Max: 68, Unders: 0, Overs: 4, Exacts: 996, Average: 36, Descheds: 0
Delay: 36. Min: 36, Max: 60, Unders: 0, Overs: 4, Exacts: 996, Average: 37, Descheds: 0
Delay: 37. Min: 37, Max: 48, Unders: 0, Overs: 3, Exacts: 997, Average: 38, Descheds: 0
Delay: 38. Min: 38, Max: 53, Unders: 0, Overs: 3, Exacts: 997, Average: 39, Descheds: 0
Delay: 39. Min: 39, Max: 96, Unders: 0, Overs: 2, Exacts: 998, Average: 40, Descheds: 0
Delay: 40. Min: 40, Max: 129, Unders: 0, Overs: 1, Exacts: 999, Average: 41, Descheds: 0
Delay: 41. Min: 41, Max: 57, Unders: 0, Overs: 2, Exacts: 998, Average: 42, Descheds: 0
Delay: 42. Min: 42, Max: 70, Unders: 0, Overs: 2, Exacts: 998, Average: 43, Descheds: 0
Delay: 43. Min: 43, Max: 60, Unders: 0, Overs: 4, Exacts: 996, Average: 44, Descheds: 0
Delay: 44. Min: 44, Max: 58, Unders: 0, Overs: 3, Exacts: 997, Average: 45, Descheds: 0
Delay: 45. Min: 45, Max: 65, Unders: 0, Overs: 3, Exacts: 997, Average: 46, Descheds: 0
Delay: 46. Min: 46, Max: 72, Unders: 0, Overs: 3, Exacts: 997, Average: 47, Descheds: 0
Delay: 47. Min: 47, Max: 63, Unders: 0, Overs: 4, Exacts: 996, Average: 48, Descheds: 0
Delay: 48. Min: 48, Max: 61, Unders: 0, Overs: 2, Exacts: 998, Average: 49, Descheds: 0
Delay: 49. Min: 49, Max: 94, Unders: 0, Overs: 2, Exacts: 998, Average: 50, Descheds: 0
Delay: 50. Min: 50, Max: 124, Unders: 0, Overs: 3, Exacts: 997, Average: 51, Descheds: 0
Delay: 51. Min: 51, Max: 103, Unders: 0, Overs: 3, Exacts: 997, Average: 52, Descheds: 0
Delay: 52. Min: 52, Max: 114, Unders: 0, Overs: 4, Exacts: 996, Average: 53, Descheds: 0
Delay: 53. Min: 53, Max: 69, Unders: 0, Overs: 3, Exacts: 997, Average: 54, Descheds: 1
Delay: 54. Min: 54, Max: 66, Unders: 0, Overs: 4, Exacts: 996, Average: 55, Descheds: 0
Delay: 55. Min: 55, Max: 89, Unders: 0, Overs: 2, Exacts: 998, Average: 56, Descheds: 0
Delay: 56. Min: 56, Max: 70, Unders: 0, Overs: 4, Exacts: 996, Average: 57, Descheds: 0
Delay: 57. Min: 57, Max: 65, Unders: 0, Overs: 3, Exacts: 997, Average: 58, Descheds: 0
Delay: 58. Min: 58, Max: 93, Unders: 0, Overs: 2, Exacts: 998, Average: 59, Descheds: 0
Delay: 59. Min: 59, Max: 80, Unders: 0, Overs: 3, Exacts: 997, Average: 60, Descheds: 0

Main problem, is that there is always delays that are completely over time (max column). This get worst if there is anything else running on the rpi.

In the captures:
-a no load output... quite OK, I would say
-and the same pulses whilst the rpi is executing a simple "sudo apt-get install update". As you can see, the timing is heavily affected.

Of course, it is possible to improve the situation giving more priority to the wiringpi function.... but then the rpi remains useless for any other purpose... and I would not use a 700Hz 512 ram linux platform just to generate us pulses... Even at 1Ghz overclocked the problem is the same"

Hope this analysis to be useful,

Manolo
You do not have the required permissions to view the files attached to this post.
mserrano
 

Postby Richard-TX » 28.04.2013, 10:35

Since timing is critical, can't the PWM output of the Rpi be leveraged somehow?
Richard-TX
 

Postby mserrano » 28.04.2013, 18:00

Hi Richard,

As far as I know the PWM is not implemented through HW - the schematics for the rpi are here http://www.raspberrypi.org/wp-content/u ... s-R1.0.pdf

The libraries I know which offer PWM are actually creating the pulses by SW and launching them to any GPIO pin.

I am copy/pasting hereafter the info for wiringpi

WiringPi includes a software-driven PWM handler capable of outputting a PWM signal on any of the Raspberry Pi’s GPIO pins.

There are some limitations… To maintain a low CPU usage, the minimum pulse width is 100μS. That combined with the default suggested range of 100 gives a PWM frequency of 100Hz. You can lower the range to get a higher frequency, at the expense of resolution, or increase to get more resolution, but that will lower the frequency. If you change the pulse-width in the driver code, then be aware that at delays of less than 100μS wiringPi does it in a software loop, which means that CPU usage will rise dramatically, and controlling more than one pin will be almost impossible.

Also note that while the routines run themselves at a higher and real-time priority, Linux can still affect the accuracy of the generated signal.

However, within these limitations, control of a light/LED or a motor is very achievable.
mserrano
 

Postby Richard-TX » 28.04.2013, 18:34

The way I understand it, there is one hardware PWM pin on the Rpi.

Lets say you need 60uS low, 60uS high, 100uS low, 100uS high....
write a bit stream into memory of 0,0,0,1,1,1,0,0,0,0,0,1,1,1,1 and tell the PWM hardware to clock it out at 1 bit per 20uS.


The DCC standard recommends that instructions are repeated. DMA is controlled by DMA blocks which have as part of the block a "next control block" address. If you make a loop with these control blocks the PWM will repeat the instructions. The user interface will take speed instructions, compile the bit stream and then switch the DMA controller to use the new set of DMA control blocks. Its going to be fast enough to be responsive to the user and there is no problem with signal timing since the PWM gets its clock from the system oscillator (not software) and the DMA is set up to maintain the required data.

The down side is that the PWM pin is shared with the audio output. So while the PWM output is active, there will be no audio.

If two PWM outputs are needed then the second PWM output has to be synthesized in software.
Richard-TX
 

Postby mserrano » 28.04.2013, 20:00

Hi Richard,

You are right, I missed the pin on GPIO18.

Actually, checking your approach thorugh DMA channels, I have found this info:
http://www.raspberrypi.org/phpBB3/viewt ... 32&t=36670
http://pythonhosted.org/RPIO/pwm_py.html

I still do not know how to use it for generating signals... but it could be worthy to check it. If you try any of these approaches, please keep me informed... I am really interested.

Best regards,

Manolo
mserrano
 

Postby Richard-TX » 30.04.2013, 17:35

There are a number of libraries and tutorials regarding the PWM output of the Rpi.

My Rpis are tied up with other projects but should have some time to devote to your project next week.

Do you have some parameters for the PWM stream that I can use?
Richard-TX
 

Postby mserrano » 30.04.2013, 20:24

Hi Richard,

What I am actually generating is the entire set of DCC commands, MM1 and MM2 and MFX.

I do not know if manipulating the PWM output it would be possible to achieve this...

I suppose you know the bit coding for each.. but basically:

For DCC:
- 1 is 56us high+56us low
- 0 is 100ushigh+100us low

The standars allow some flexibility - specially for the 0 bit coding.

The bit stream could be anything...basically:
Pramble (14 '1')-0-Byte1-0-Byte2-0....Byten-1
And even such message can change.... longer preamble for programming.

For MM:
-1 is 182us high 26us low
-0 is 182us low 26us high

I am not addressing so far MM accesories (1/2 of the other timing).

The bit stream, again.. anything
byte1-bit1-bit2-byte2

For MMX:
-1 two short pulses of 50us (level depending on previous level)
-0 one long pulse of 100us (level depending on previous level)

Bit stream:
long-short-long-long-short-long (up to 52bits)-long-short-long-long-short-long-long-short-long-long-short-long

I am focusing so far in DCC and MM.... as I said, I do not quite see how to use the PWM to get this bitstreams... or even if this is possible...It would be great.. but as you can see there is no pattern that can be used.

Thanks in advance for anything you can discover.

Manolo
mserrano
 

Postby Richard-TX » 30.04.2013, 21:16

From what I have been able to glean from the documentation available, what needs to happen is to write a bit pattern into a array and then pass a pointer to that array to the Rpi PWM library. At that point, the hardware reads that array in memory and clocks out a bit stream and keeps clocking out that bit stream until commanded to stop or use another address for the pattern.

According to the specifications the maximum resolution is 1us so that is close enough for DCC.

The way I see it, to get this to work, one sets up a few arrays. They are:

- basic power on array. This provides the switching of the Booster so that the track sees 15 volts of AC Power.

- Command array - Once defined, then sub-arrays can be concatenated to create a proper DCC command packet. Once the concatenated sub parts of the packet are stuffed into a array, then pass a pointer to that array to the library.

Assuming 1 us resolution, a bit stream that consists of a 3 us high pulse, followed by a 2 us gap followed by a 5 us high pulse followed by a 1 us gap, the array should look like (in pseudo-code)

#define array1 [0111001111101.....]
/* the leading zero means that nothing is assumed. The output could be latched high for all I know. The trailing 1 ensures that the off duration is exactly 1 us. This is where the end of packet data gets tacked on. If I recall it is something like 445 us of OFF.



I will get out the oscilloscope next week and play some more.

Personally I would like to see a Programming track controller made from the PI as well. One that can handle all manner of accessories would be nice.
Richard-TX
 

Postby thonglor25 » 09.05.2013, 14:35

Hello Manolo,

I'm coming back to the earlier question of Schweineschnäuzchen on how to create a shortcut for the desktop on the RasPi to start Rocrail with a double-click on the icon. You recommended to use the following steps:

[Desktop Entry]
Encoding=UTF-8
Type=Application
Terminal=false
Exec=/opt/rocrail/rocrail.sh
Icon=/opt/rocrail/rocraild.png
Name=Rocrail
Categories=Rocrail;


I have tried this, and also given the permissions (777) as described further, but I'm not able to make this work, even after a lot of trying around (like adding dots in front or sudo). While I understand the code, I have no idea why it's not working. Is it because I'm working as user root? My Rocrail installation was done with user Pi.

Anyway after lots of trying I found a way to make it work by using lxterminal. The code in my desktop file is now:

[Desktop Entry]
Encoding=UTF-8
Type=Application
Name=RocRail
Terminal=false
Path=/opt/rocrail/
Exec=lxterminal --geometry=120x60 --command "/opt/rocrail/rocrail -console -f"
Icon=/opt/rocrail/rocraild.png
Categories=Rocrail;


This way it works. It ony works properly if I add/specify the execution path with "Path=/opt/rocrail/". It's also nice/good to be able to define the window size that fits the RocRail console well.
thonglor25
 

Postby Liviu M » 22.05.2013, 21:15

Hello all,

I'm joining the group of the RocPi users.
Thanks to Manolo & Johannes instructions, it was quite easy to install the Rocrail (just the server) on the RasPi *); the only difference between the "manuals" & my installation - I've installed the server without installing the wxWidgets.
The good news (for me) - RasPi recognize my Ln2Usb interface. :D
The bad news (also for me) is that communication is very buggy :evil: - to many lost packages. That means I can't use the RasPi as server & I should see if I can fix it.
At the end, I just want to thank to Manolo & Johannes for the installing instructions. And, of course, to Rob for the Rocrail.

*) By the way Rob, which is the correct command for installing just the server?
I've tried three ways:
- before reading a post of you on this topic, I've just commented out the rocview part in the ../Rocrail/rocrail/makefile and used the
Code: Select all
make PLATFORM=LINUX fromtar
It compiled quite fast;
- after reading your post & reactivated the rocview - used the
Code: Select all
make PLATFORM=SERVER fromtar
I received an error about not knowing the fromtar option;
- after reading your post & reactivated the rocview - used the
Code: Select all
make server
It compiled but took longer than first method.
Liviu M
 

Postby Pirat-Kapitan » 22.05.2013, 21:53

Hi Liviu,
You have to read the daily news of rocrail :lol:
Dateien machen (hier nur Rocrail (den Server) erzeugen)
cd /home/pi/rocrail/source/Rocrail
make PLATFORM=LINUX server
das dauert nur ca. 30 Minuten, dann installieren:
cd /home/pi/rocrail/source/Rocrail
sudo make install

best regards
Johannes
Clearasilfahrer auf Spur G&H0m, Lenz LZV (3.6), ORD-20, Manhart-Funki und WLM, RS-Bus Rückmelder (Reedkontakte/GBM),
Rocrail auf RasPi mit mobilen Geräten (andRoc). Details auf http://wiki.rocrail.net/doku.php?id=use ... at-kapitan.
Pirat-Kapitan
 

Postby Liviu M » 22.05.2013, 22:08

Hallo Johannes,
Danke für die schnelle Antwort!

Pirat-Kapitan wrote:You have to read the daily news of rocrail :lol:

I'm trying, but seems not hard enough. :lol:

Pirat-Kapitan wrote:make PLATFORM=LINUX server

Now, seeing your post it looks quite obvious. I'll give it a try next time.

Thanks a lot,
Liviu
Liviu M
 

Postby Richard-TX » 21.08.2013, 17:00

The last time I did a compile of Rocrail on the Raspberry pi I just did a "make fromtar" and it just built.

Of course I installed the requisite packages.

http://wiki.rocrail.net/doku.php?id=buildrr-en

While Rocrail ran without issue, the speed of the Raspberry was too slow for me. I will ultimately be running the gui on my laptop and the rocrail server on my Dell 690 server running Linux. The Raspberry will be used as an accessory decoder that is controlling servos, leds, sensors, etc.
Richard-TX
 

Postby rjversluis » 23.08.2013, 12:09

Is this correct at normal boot?
GPIO 14 + 15 = /dev/ttyAMA0

http://wiki.rocrail.net/doku.php?id=roc ... netnode-en
Best Regards, Rob.
:!: PS: Do not forget to attach the usual files.
:!: PS: Nicht vergessen die übliche Dateien an zu hängen.
[ macOS - Linux] - [ N: CBus - CAN-GCA ] - [ 0: RocNetNode - GCA-Pi ]
rjversluis
Site Admin
 

Postby Richard-TX » 23.08.2013, 16:07

Yes assuming you are going to use the RS232 port.
Richard-TX
 

PreviousNext

Return to Building & Compiling