New serial Protocol to figure out
John in WI
Further below is the protocol info from http://www.doityourselfchristmas.com/wiki/index.php?title=Renard#Protocol
My questions are:
What is a pad byte?
How should I code the escape byte?
I'm guessing I look for the sync byte then use a for loop to read serial and turn on my individual outputs?
Can I use the jallib slip library somehow to make this work?
Also, i'm wondering if there is a "software" PWM I might be able to dim the LEDs on my pic with? At the moment I'm using an 18f43k20, but I'm flexible.
Thanks! - John in WI
Special Characters
0x7D - Pad byte, silently discarded by controller firmware, inserted by host PC to prevent Tx overrun
0x7E - Sync byte, start of packet marker.
0x7F - Escape byte, used as prefix for encoding dimmer levels that correspond to the special characters.
To send the value 0x7D as data (rather than as a special character), send the two-character sequence '0x7F-0x2F' in its place.
To send the value 0x7E as data (rather than as a special character), send the two-character sequence '0x7F-0x30' in its place.
To send value 0x7F as data, send the two-character sequence '0x7F-0x31' in its place.
The PICs have a rather large internal clock frequency tolerance, which could cause a transmitter overrun in a PIC which has a slow clock. This could happen under the following circumstances:
1) The host PC is transmitting characters with one stop bit, and
2) One (or more) of the PICs is using its internal oscillator (instead of an external crystal) and
3) That oscillator is running at the low end of it's tolerance (1% slow),
The Renard firmware doesn't have any separate provision for transmit buffer other than the internal PIC transmit buffers. If data is arriving at the PIC faster than it can clear the UART transmitter, some data in the PIC transmitter would be over-written, causing data to be lost. The PAD byte is intended to give the transmitter in a slow PIC time to catch up.
Packet Format
Byte 0 - 0x7E (sync byte)
Byte 1 - Command/address byte (usually 0x80, see below)
Byte 2-n - Dimmer values (0-0xFF, values 0x7D, 0x7E and 0x7F have special encoding, all others are sent raw)
Oliver Seitz
| Hi! |
|
Strange thing is, as a theater and event engineer, I should have heard of that... But the only digital serial protocol I know of, is DMX512. ( http://en.wikipedia.org/wiki/DMX512 ) I've implemented DMX512 send and recieve programs in JALv2, if someone's interested. I have not yet written libraries for that. Greets, Kiste |
Joep Suijs
2012/1/4 John in WI <horn...@gmail.com>:
> My questions are:
> What is a pad byte?
A 'filler' character with no meaning. As your specs says: just ignore
this when you receive it.
> How should I code the escape byte?
Use a flag (bit) that you set when the escape char is received (no
further processing of this char is needed). If you receive a character
while the flag is set (that is: the previous char was the escape
byte), handle it as described in your message (that is: assign the
target value for further processing). Reset the flag after processing
each character expect for the escape char.
> I'm guessing I look for the sync byte then use a for loop to read serial and
> turn on my individual outputs?
What is decribed above is a 'first level' to remove the framing. The
outcome can be processed. I don't see any details in your message on
how to process the data although it is obvious what the sync byte
does...
> Can I use the jallib slip library somehow to make this work?
Slip uses a similar escape methode, so the library might inspire you.
However, since it is buffer-based and also includes sending, it also
contains a lot of code that might not be relevant for you.
> Also, i'm wondering if there is a "software" PWM I might be able to dim the
> LEDs on my pic with? At the moment I'm using an 18f43k20, but I'm flexible.
On the yahoo list,
(http://tech.groups.yahoo.com/group/jallist/message/31719) there is a
reference to a program with an elementary software pwm routine. Keep
in mind it might take some tweaking to get the same results as harware
pwm due to the interaction with other code and mostly lower cycle
time.
regards,
Joep