PropBasic ws2811/2812 driver

EE351

Hello all!

I'm a long time lurker, first time poster and I wanted to share the code I wrote in PropBasic to drive 50 ws2811 leds. Please keep in mind that I'm not a professional programmer by any stretch so I'm sure the code could use some refinement. Overall I'm very pleased with the speed of PropBasic, as the ws2811 signals generated by the prop are within spec according to my logic analyzer. Kudos to Bean for developing PropBasic!

My question is, would it be possible to use the serin command in PropBasic to receive data at 921600 baud? I would like to write some additional code that would receive e1.31 data from lighting software on a pc that would be received by the prop. The connection would be unidirectional, as data would only be sent from the PC to the prop via an rn-xv wifly device. The e1.31 packets would be 635 bytes long. I have experimented with transmitting bytes from the prop to hyperterminal at 921600 baud without issue, so I'll try sending data from the pc to the prop at the same baud rate. I'm just curious if anyone else has tried receiving large arrays of data at this speed using PropBasic.

JonnyMac

If memory serves me, PropBASIC allows you to include assembly; I'm sure that would help you with timing. I have a lot of experience with WS2801 and WS2811/12 LEDs, but all of my drivers are written in PASM. If you move your driver to its own cog (assign it to a task), then your foreground program can focus on animation -- that's where the fun really happens.

EE351

Thanks for the reply. I'm hopeful that I can do the serial programming in PropBasic as I'm not that proficient in writing code in assembly language. I'm hoping to be able to drive an array of these ws2811 led (1200 total), having the serial data collection handled by one cog (task) and driving the ws2811 leds in tasks running in the remaining cogs.

JonnyMac

The Propeller is fast enough to handle that baud rate, and running WS2811 LEDs -- so long as those tasks are running in their own cogs.

For critical timing tasks like these, I think you'd be wise to learn PASM or learn how to incorporate code written by others into your applications. When with compilers, there are some things that are best left to low-level code

I've attached my WS2811/12 driver (PASM with Spin interface), and high-speed RX (based on code from others) for your reference.

EE351

Thanks for the tip, you are probably right about learning assembly. In fact, that is one reason why I chose PropBasic. That way I can write small bits of code and see how it translates to assembly language.

JonnyMac wrote: »

The Propeller is fast enough to handle that baud rate, and running WS2811 LEDs -- so long as those tasks are running in their own cogs.

For critical timing tasks like these, I think you'd be wise to learn PASM or learn how to incorporate code written by others into your applications. When with compilers, there are some things that are best left to low-level code

I've attached my WS2811/12 driver (PASM with Spin interface), and high-speed RX (based on code from others) for your reference.

EE351

BTW, I'm familiar with your ws2811 code, I used it to run 200 pixels on my Christmas tree this last year. Very nice work and I didn't have too much trouble modifying it for my needs. However, sometimes I do prefer to write my own code because I find it easier to troubleshoot if something doesn't work right. Before the propeller, all of my code was written in picbasic pro for pic microcontrollers. That's another reason why I chose Propbasic rather than spin (or assembly), because the syntax is very similar between both languages.

David Betz

EE351 wrote: »

BTW, I'm familiar with your ws2811 code, I used it to run 200 pixels on my Christmas tree this last year. Very nice work and I didn't have too much trouble modifying it for my needs. However, sometimes I do prefer to write my own code because I find it easier to troubleshoot if something doesn't work right. Before the propeller, all of my code was written in picbasic pro for pic microcontrollers. That's another reason why I chose Propbasic rather than spin (or assembly), because the syntax is very similar between both languages.

I used Jon's PASM driver for a Christmas project as well and it worked flawlessly. Nice job Jon and thanks for sharing it!

JonnyMac

BTW, I'm familiar with your ws2811 code, I used it to run 200 pixels on my Christmas tree this last year. Very nice work and I didn't have too much trouble modifying it for my needs.

What part of my driver did you feel the need to modify? Just curious.

EE351

JonnyMac wrote: »

What part of my driver did you feel the need to modify? Just curious.

I changed the spin code that called your ws2812 driver (no changes were made to the driver itself). Specifically, I added a few new color routines to display different color outputs.

JonnyMac

Okay. Just wanted to make sure you didn't have any problem with the actual driver. It gets a lot of use so I try to keep on top of it.

EE351

Well after some testing with propbasic and the serin command, the fastest baud rate I'm able to achieve with consecutive bytes is about 500kb. I wrote a little code that will receive 20 bytes in one cog and transmit them in another cog. Using RealTerm, I'm able to send a 20 byte packet. The funny thing is, if I send one byte at a time (meaning I type in the bytes in RealTerm) 921600 baud works.

I think JonnyMac is right, I need to look into an assembly solution if I want to get this to work at 921600 baud.

JonnyMac

If you look at the code example I gave you, the receive section is unrolled for best speed. In the compiled code that runs in a loop. And for that kind of speed, RX and TX (if you're going to have it) should probably run in separate cogs).

Even unrolled, you may need to control byte-to-byte timing from your master program as the stop-bit(s) period may not be enough to write the new byte to your buffer and update the head pointer.

EE351

Success!! I was able to get my code working at 921600 baud, but I had to change the number of stop bits to 2 in RealTerm. I can now transmit a packet of 20 bytes at speeds up to 1200 kb, anything beyond that and garbage is returned. I'm glad I was able to do this without having to use an assembly driver or overclocking the prop (which I had considered also).

Bean

EE351 wrote: »

Success!! I was able to get my code working at 921600 baud, but I had to change the number of stop bits to 2 in RealTerm. I can now transmit a packet of 20 bytes at speeds up to 1200 kb, anything beyond that and garbage is returned. I'm glad I was able to do this without having to use an assembly driver or overclocking the prop (which I had considered also).

That is great news.

Could you post your working code ? I'd like to see it if you can.

At high baud rates it is not so much receiving the data, it doing something with it quickly so you can get back to receive the next bit in time.

Bean

EE351

It's the same code that's posted above, the only change I made was the number of stop bits in RealTerm.

Also I remember reading a forum post here about an IDE being developed specifically for Propbasic. Do you know if that project is still ongoing?