Hi Christian,

First of all, a praise to your work! I just decided that a AVR-based platform is no sufficient for my project and upgraded to an stm32-discovery board. All I needed to modify in my application was a few Pin and device settings (about 5 lines). Thats it, the same application runs on a completely different platform. Awesome!

Thanks, that’s great to hear! Are you using the STM32F100 Discovery Board? It shares a surprising amount of identical peripherals with the F4, I was really quite surprised how quick it was to port. There is no ADC driver though, it simply was too different…

To my question: I'm working on an Ambilight clone (I already submitted a driver for my PWM devices). The device is connected via UART to a PC. Boblight runs on the PC and sends colors via a certian protocol over UART. I'm using a very basic protocol in the moment but would like to implement sanother one (LTBL). I would like to contribute the protocol Implementation, maybe it's of use for someone. So my question is: What would be the xpcc way of implementing a protocol on top of UART?

We have several drivers for protocols over UART of varying complexity. They are reasonably well documented [1] and can be found in `xpcc/communication` [2]. The exception is XPCC (the protocol), which does Inter-Process Communication over CAN and acts as the primary event-loop in our robots. It is quite complicated and shamefully undocumented, but it even works on AVRs. My favorites (besides XPCC of course) are AMNB, which is a textbook implementation of p-persistent CSMA-CD, and RPR, which is a homage to IEEE 802.17.

Currently I'm using a protothread that reads a data stream from uart and parses it token by token. However, I'm think more of something similar to a driver.

The SAB is probably the simplest protocol we have over UART. It was used with our AVR based robots, when not all parts of the program could fit onto one controller or we ran out of pins and we had dedicated “sensor” and “actor” boards. Yeah, those were the good old times… The message framing is done in the `Interface` class. It doesn’t use Protothreads as it’s not required here, it just uses a state machine [3], like most simple protocol parsers, and then passes the message up to the next layer. I’m not sure what the status is for these protocols, I did have them working quite a while ago, but since we switched to Cortex-M devices with enough pins, we have kind of deprecated them in favor of XPCC over CAN. However, they are a good starting point for the Let There Be Light (LTBL) protocol over UART. Not sure if applicable, but there are also correction tables for (very basic) gamma correction of RGB LEDs [4]. Looking forward to your PR ;-) Niklas [1]: http://xpcc.io/api/group__communication.html [2]: https://github.com/roboterclubaachen/xpcc/blob/develop/src/xpcc/communicatio... [3]: https://github.com/roboterclubaachen/xpcc/blob/develop/src/xpcc/communicatio... [4]: https://github.com/roboterclubaachen/xpcc/blob/develop/src/xpcc/ui/led/table...