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/communication/
[3]: 
https://github.com/roboterclubaachen/xpcc/blob/develop/src/xpcc/communication/sab/interface_impl.hpp#L175
[4]: 
https://github.com/roboterclubaachen/xpcc/blob/develop/src/xpcc/ui/led/tables.hpp
_______________________________________________
xpcc-dev mailing list
xpcc-dev@lists.rwth-aachen.de
http://mailman.rwth-aachen.de/mailman/listinfo/xpcc-dev

Reply via email to