At least I have a sense of humor :) John Doe sadly has none. Just engineering-content-free habitual OT rants on the people he doesn't like who he'd like someone else to kill for him this week.
feel free to be pals with him, it's cool...
I'm a bit puzzled by the very high error rate at 57k6 baud. I used to run at 230k4 back in the early 2000's without any significant errors. I haven't used RS232 in ages preferring USB for fast serial today.
Is the environment electrically noisy with long cables or something?
-- Regards, Martin Brown
it's not "real" RS-232 serial it's serial over USB, using an FTDI interface chip.
also the serial port clock on the ATMega test receiver (just a mock-up/proof of concept, the actual client device is ARM based) is derived from the 16MHz master clock; I don't think 16MHz is a particularly amenable clock source for a 57600 baud rate:
FPGA bit streams tend to have long runs of 0s and 1s. Assuming that anything else isn't worth compressing, one can write very simple compression/decompression routines that cut the size of a binary bitstream image by about 3:1. Serial bit-banging gets fast, too, when you're blasting out long runs of 1 or 0.
-- John Larkin Highland Technology, Inc picosecond timing precision measurement jlarkin att highlandtechnology dott com http://www.highlandtechnology.com
run-length encoding doesn't work well at all for raw bitmap/pix-map image data there aren't enough runs of identical binary digits in most video frames to make it worth the overhead by itself. JPG uses it after the image has been quantized to something more resembling palette-based.
Transmitting moving pictures over meh-bandwith digital links "properly" is mostly a solved engineering problem; you use some kind of FFT-based lossy compression algorithm like mp2 and error correcting codes over the link.
It would take a while to create a custom implementation from scratch. buuut this client wasn't paying nearly enough to implement all that jazz, and not convinced the desired receive hardware could pull it off. It's an engineering rat hole. Maybe someday for fun I try it.
A look-up table has my vote
I still find it odd that a FIFO on the USB serial receiver cannot cope at 57k6 baud. It isn't rocket science you divide 16MHz by 277.75 and suffer a tiny amount of jitter to get within 0.1% of the right rate. Or using the numbers in the table you have divide by 17+1/3 = 57692bd.
If it is physically connected over USB then why not implement the LCD display as removable storage medium and take advantage of the speed of USB. There are loads of industrial camera chips subverted for amateur astronomy that do this and get 250+ fps at lower resolutions. eg
I have its larger brother.
-- Regards, Martin Brown
Hi Martin, the LCD display output was only a proof-of-concept. The actual client-side item is a large array of LEDs controlled by TI LED driver chips. so I didn't have to have the big-ass thing sitting on my bench all the time!
It's physically large, but not high-resolution. The speed of serial connection seems to be perfectly adequate for it.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.