update, just to complete the thread (not sure if anyone interested, but here goes anyway)-
I think I ended up using some combo of ideas/suggestions provided here. I have been streaming/scrolling data at the display for a while now, and the original idea worked ok but I was just not thrilled at keeping track of time on the pc side (for the 2sec timeout, where a 'sync'/autobaud is required). A 'keep out' time window has to be used as you really don't know when a byte actually goes out the pc uart. So, I concluded that autobaud is not worth the trouble in my case, so fixed baud it is. (I also attempted to 'monitor' the rx pin via pps to the timer1 gate, keeping track of maximum low times of 9bits when 0 transmitted, but could not get consistent values for some reason- the autobaud was always dead on, though).
After looking at it a while, I also trimmed down the '3 byte' protocol to simply 2 types of bytes- command (where bit7 is clear) and data (bit7 set), where I only need to keep track of the previous byte in any case and cannot get 'out of sequence'. Addresses also auto-increment (except for the 'broadcast' address 127), so I can address any digit if wanted or simply let it auto-increment (most cases). After a Latch command, the address resets to the 'origin' address.
something like this-
in rx irq-
just put rx byte in buffer[]
main loop-
process_rx loop()
while new byte in buffer[] found-
if bit7 clear, clear cmd_ok flag
else process_data()
process_data()
if cmd_ok, must be text or raw data- set digit data
else must be data following a cmd byte-
check all commands (look at previous cmd byte), act accordingly
set cmd_ok if any valid command
0b0xxxxxxx 0b1xxxxxxx
cmd&127 data|128
----------------------
//out of reset, text mode, address=126 (unused), brightness=32
//set digit0-7 to '12345678', brightness 64
'T' 127 text mode, address set to 127 (broadcast- no auto-increment)
'B' 64 brightness set to 64 (all digits as address is 127)
'T' 0 text mode, address set to 0 (leftmost digit)
'1' digit0 = '1', address++
'2' digit1 = '2', address++
'3' ...
'4'
'5'
'6'
'7'
'8'
'L' 'L' latch data (all act on latch command),
address reset to origin (0 as set above with T cmd)
//can now send text starting at digit0, then latch, repeat
//or just send T 0 at start again
//light up all segments on all digits at brightness 127
'R' 127 raw mode, address set to 127
'B' 127 brightness set to 127, all digits
'D' 'P' set dp segment, all digits
127 set segments 7-13 (high byte)
127 set segments 0-6 (low byte)
'L' 'L' latch data
This ends up being a lot less verbose on the bus, and only needs a maximum of #digits + 2 to refresh every digit in text mode. So even at a low 9600 baud, I could update 126 digits at 7Hz+ (although many digits would be neat, I will probably never get more than 16 digits strung together at once). All digits can be addressed at once, addressed individually, or auto-incremented (every other data byte in raw mode, as 2bytes needed for 14 segments). If any invalid command attempted, nothing will be done until a valid command.
Seems to work, and the 'driver' is quite simple on the pc side. I am using micropython on linux at the moment to download internet data, send to display- have not used python before, but seems like a nice language (yes, I am behind the times).