Sending pixel info from a computer to a microcontroller  - Page 1
Forum section: electronics / projects

author: wasting
author_rank: Newbie
timestamp: May 19, 2015, 10:30:20 am
content: Hi there!I'm currently working on a home made "computer screen" and needs some help with sending pixel information from a computer to a microcontroller.The ideaA screen based on a matrix of 45x23 pixels, LEDs controlled by WS2801 ledstrips. (this part is done!)The brain is the Atmel SAM3X8E ARM Cortex-M3 (arduino due). Everything will be writen in C by myself, etc no library or arduino bootloader. (this part is also done!)Pixel information will be read from a computer using Java. not all pixels will be read, etc if the computer screen width is 1280 pixels it will read every 1280/45 = 28 pixel. The same goes for the height. The data rate needs to be at least 2.5 Mbit/s (45*23pixels*24bit*100samples/s).The questionWhat is the best way to send the data from a computer (using Java) to a microcontroller? It doesn't have to be java but as I do know java I would like to use it.An idea I have is using USB (Full Speed 12 Mbit/s) -> converter -> SPI but I'm not sure if it's the best or easiest way + I don't know where to start :/ .Thanks for your time and answers! Cheers

author: CaptainObvious
author_rank: Contributor
timestamp: May 20, 2015, 06:26:43 am
content: While I'm familiar with the "standard" (old) versions of the Arduino's based off the ATMEGA chips, I haven't played at all with the ARM variation, but I don't anticipate (too many) differences!In regards transferring the data to the "screen", I actually created a project a few years ago in Visual Basic (Not java.. I know:/) that would read an image, then go pixel by pixel and send the details out to my display. The big difference, I was actually using a color LCD, so I had to send 3-bytes for every pixel (Nokia 6610 to be exact) but it's likely the same concept. In this case, the data conversion was completed by the on-board FTDI chip, I don't recall the exact speed limitation of the FTDI, but it would take about 2-3 seconds to load an image from the serial port. (The delay could have been the code as well, the project was more a "proof of concept" than anything else!)I know the Due has the ability to emulate a usb device (keyboard/mouse) I could only imagine there's a way to setup bi-directional communication with that same concept in mind. I'm sure it won't do USB 2.0 speeds (480 Mbit/s) but might be a decent solution without needing any external hardware. If this works out, you should be able to access the Serial Port inside of Java fairly easily, after just a few minutes of research, this sounds like a promising java library designed for communicating with Serial ports (COM ports)https://code.google.com/p/java-simple-serial-connector/Best of luck, I'm curious to see what the solution is!

author: macboy
author_rank: Super Contributor
timestamp: May 20, 2015, 04:20:52 pm
content: Quote from: wasting on May 19, 2015, 10:30:20 amI think you overestimate the data rate. You won't need to update 100 times/second. 50 would be plenty and 25 is likely enough too. If using 25 updates per second, you can do it in ~621 kbit/s. Add some necessary overhead for data formatting/framing, and you may get by with a USB UART running 921 kbaud. At 921 kbaud, you get 8/10 of that rate as data (the rest is framing), so 737 kbit/s data. Most USB UART chips will run at this rate, many of them even higher. You could also use an FTDI chip as long as you aren't soured by that company now, and use their direct API and synchronous serial (SPI) instead of asyncronous to get even higher data rate and less software overhead (no COM port emulation).

author: Asmyldof
author_rank: Regular Contributor
timestamp: May 20, 2015, 04:38:01 pm
content: If you are okay with using ASF (Atmel Software Framework) you can very quickly make a high speed Virtual Com Port connection on any internal USB plug, or if there is no USB, many of them can do HW UART at rates above 2MBit, quite a few go even up to 10 or 20MBit on the dedicated HW UARTs.For me, I always choose the Atmels with an USB connector for projects like these (but then do design and deveop all the PCBs myself, which is likely a step too far for you right now), because it allows you to run the Virtual Com Port directly on the Atmel, no extra hardware needed and they usually maintain 6Mbit+ easily.Be aware though, that Windows (your name is Macboy, so I don't think it's a real risk for you ;-), but maybe compatibility for friends/family?) is very bad at continuous streams of Virtual Com Port data. In more than one instance, using the internal Windows APIs data got dropped for me after a while when buffers start overflowing because of multitasking stuff. Data just started disappearing between the incoming connector and the compiled software at rates above 150kBaud sustained dataflow. No such problems in Linux though, thankfully. (same computer, same port as well)EDIT: My name comment was erroneous, I accidentally remembered the last commenter's name in stead of the OP's name. Sorry Macboy.

author: macboy
author_rank: Super Contributor
timestamp: May 20, 2015, 04:50:29 pm
content: Quote from: Asmyldof on May 20, 2015, 04:38:01 pmHave you ever tried increasing the system clock tick rate to improve multitasking responsiveness? This is what browsers like Chrome do in order to get smooth on-screen animations. Movie players and games often do as well. The default is 15.6 ms (~64 tick/sec) and it can be reduced to 1 ms (~1000 tick/sec) or even 0.5 ms depending on Windows version. This may let your program wake up sooner and keep the buffers from overflowing.(use the sysinternals utility ClockRes.exe to query the clock rate).

author: Asmyldof
author_rank: Regular Contributor
timestamp: May 20, 2015, 04:57:57 pm
content: That's not the problem.I'm talking about low level C/C++ programming, using the internal Windows API classes directly.Windows just doesn't really consider your COM's buffer as vital, for some reason, when the incoming data on the hardware line crosses a line that's not normally crossed by the classical serial devices, it starts cutting out. It now supports arbitrary speeds and high speeds, like Linux, but not the data handling capability that Linux ties to it.