Will it give the library for the raspberry pi? Maybe in Python?
At this point, the library only works on microcontrollers with no operating system. So it works on Arduino and similar AVR and ARM -based boards, but not on Raspberry Pi or BeagleBone.
Maybe a future version, but it would take a lot of work, and we haven’t even started on it.
Try using Arduino-- it’s pretty easy!
As it’s C++, why can’t it work on Raspberry ? I already have Open DMX on raspberry and it’s working very good with C++ programs… Is there a limitation in your code ? As i’m curious, i’ll try to find some time to explore this way…
The Pi runs Linux, which interrupts userspace code hundreds of times a second. The Arduino runs NO operating system, and thus user code can have complete control of interrupts and timing.
Controlling LED strips requires extremely precise timing; Linux cannot provide that level of precision to userspace code. DMX has much looser and lazier timing requirements; its a much slower protocol.
Under Linux, we’d have to reimplement the library as a kernel module; kernel programming is even more of a pain than Arduino programming. Nevertheless, Dan and I are obviously into tackling hard problems, and we’ve discussed Linux support already.
I don’t think it’s in the cards for us anytime soon, but if YOU are a Linux kernel programming jockey, we’d love to have your help with the port! It would be fun to be able to use a Pi if we wanted.
Ok, According to what i can see in the source in few minutes, there is a lot of use of Arduino’s libs… that would need some “adjustments” 
But i see it has been already prepared : “Pin access class - needs to tune for various platforms (naive fallback solution?)”
Actually, we’re nearly Arduino-free.
We do have strong ties to the particular chips and boards that we support – but that’s whats necessary to meet the timing requirements. We’d have to do the same thing for the Pi (and BeagleBone etc).
The code is very connected with the hardware it runs on, which is pretty much the natural state of code on OS-less microcontrollers. Your code controls the hardware, period. The whole idea of operating systems (eg Linux) is to PREVENT user code from directly controlling the hardware; that’s reserved for kernel code only. So since we need to control the hardware precisely, we’d need to be a kernel module, and that’s where the hard work will be.
Do you have experience writing Linux kernel modules? I’d be useful for me to talk with you about that if so.
Oh, G+ didn’t refreshed realtime i see your answers now only. I understand why the open dmx protocol is a kernel module… I’m not an expert in kernel module programmation, but it may be useful to explore how did they made the open_dmx.c file. It is certainly possible. But you talked about frequency problems, do you think it’s a dead-end because of the raspberry’s core limitations around this realtime dimension ?
On the other way, i think Arduino are limited when i need communication, i really like to have a command shell to drive everything, and be able to get it with SSH… Maybe i’m too old ^^
We can drive LED strips from Linux, we just need to be able to disable interrupts, so that’ll have to be kernel code.
As for communication AND LED control, try the Arduino Yun, or the Digistump DigiX, or a Pi with a Wyolum Alamode, or look into a BeagleBone Black…
Thanks for the tips, i’ll think i’ll try a beaglebone black.
For the interrupts, have you already tried without disabling interrupt and with a “nice -19” ? If the priority is very high, i think the result may be acceptable.
“nice” only affects the relative scheduling priority of userspace jobs. It does not stop, pause, or even slow down the normal kernel interrupt schedule. The kernel interrupts keep running (and would keep messing up the LEDs just the same) no matter what unless you disable them in your own kernel code.
I’m not sure it’s the same, but i already had similar problems for critical sections for zwave daemons which need to listen very time precise events, and using pthread_mutex_lock( &g_criticalSection ); and pthread_mutex_unlock( &g_criticalSection ); is working like a charm. I used C progams to make SPI external devices listen to 433Mhz signals, and you know 433Mhz protocols needs a very good time precisions in data collections. I never had to use kernel module to do that. Don’t you think making a kernel module is luxery and not a must ? I know the module would be closer than the pthread lib, but if all time precise progams would need to have a special kernel module to work i think it would be a pain for a lot of sysadmins … I’m refering to this http://en.wikipedia.org/wiki/Critical_section
We’ll obviously try to so the lowest-impact thing we can.
But some of the LED strips (WS28xx) are extraordinarily sensitive to timing: the output can be screwed up, or made unusably unreliable, by as little as one single misplaced clock cycle. One single machine clock cycle. SPI strips (eg LPD8806) are a little more lax but can still be dicey when timing isn’t rock solid.
In our experience, the only way to make the library 100% reliable for everyone, for all the chipsets, is to disable interrupts. Pthreads on Linux don’t do that; they still allow the “protected code” aka “critical section” to be interrupted by kernel code (though not userspace code), and therefore the timing can be off by hundreds or thousands of clock cycles.
If you get the code working reliably in userspace, we’ll definitely fold your changes back into the core library!
But to be totally candid here: Dan and I both have a lot of personal experience with threading and interrupts and timing-critical code. And while we’re always willing to be shown that our preconceived notions were wrong, and to learn something surprising and new, we’re going into the Linux discussion with strong beliefs that we’ll have to disable interrupts on Linux exactly the same way we have to disable interrupts on AVR- and ARM- based Arduinos, and on AVR- and ARM- based clones.
If we could make it work without disabling interrupts, we would have already done that. But if it doesn’t work on an OS-less environment like Arduino, I’m nearly 100% certain that it won’t work on a system with more ongoing interrupt activity, eg Linux.
Let us know if you make progress with a userspace port!
I bow to your experiences… But yes, i’m quite suprised a job like this on a 700Mhz cpu can be disturbed by interrupts… especially if it’s a raspberry linux. On a web ou file server, i can understand, but on a idling raspberry, dedicated to one or two jobs…
I didn’t know these protocols were as susceptible to nanoseconds as you explain.
I’m currently using only TM1812 strips with DMX up to 320 leds only, so i have not enough experience like you with more pixels.
I assume that the longer is the strip the more sensitive is the signal ?
You’re correct: the longer the strip, the more sensitive it is to imprecise timing. Voltage, grounding, and manufacturing variation all seem to make some strips hypersensitive to timing.
RC3 of the library had a tiny timing problem like this, and we saw all kinds of wierdness: some strips worked fine up to about 100 pixels, and the rest of the pixels went nuts after that; some even shorter strips (60px, 1m) of WS2812B pixels didn’t work correctly; sometimes the signal was close-enough-to-OK at 3.3 volts, but powering the same strip at 5 volts made it hypersensitive again and it went bananas.
The RC4 version of the library made a couple of 1-2 clock cycle changes, and everyone seems to be reporting that it works great now, at all lengths and voltages. In order to properly debug the problem, Dan had to get a higher-resolution oscilloscope!
Anyway, that’s the sort of experience that makes me feel like we’re going to have to hold everything rock solid timing-wise.
On the other hand, at 700,000,000 cycles per second, we will have a little more leeway than at, say, 8,000,000 (Gemma, Trinket, Digispark). We’ll give it a try when we get there!
Me, I’m going to try using the Wyolum Alamode in the meantime, and I know Dan wants to play with the BeagleBone Black…
I know you are working hard in optimization, this is certainly a good job.
I never used 3 to 5 volts (i have dedicated 10A@12v supplies for the leds), everytime i tried i had problems with my LEDs, and i can understand it can be hard to make all this to work on USB supplies… the power sucked by CPU rather than LEDs can be rude, more than cycles for a raspberry because a raspberry has only 1 or 2 Amps for 700M ticks/s…
Keep good work !
Maybe one day i’ll have something good with my userspace critical section
I just have to understand first the TM1812 protocol before to start to program… is there a documentation somewhere or do i have to make my own interpretation with my oscilloscope ?
Maybe your class TM1809Controller800Khz can help me ?