Liquid Soulder

Member Since: May 25, 2018

Country: United States

Details of a silly problem with a silly solution: How to not overwrite your outgoing SPI data buffer when using the Arduino core libraries

Continue reading

  • Rob, cool to hear about your background in theatre! If you have a chance I’d love to talk about what kind of props or other work you created. Hope you like the new position!

  • From your other comment looks like you got this working. Nice going! That’s what I like to cal rubber-duck debugging. Hope you’re enjoying it

  • Good observations - the 50 Hz number comes from testing with data already in RAM. When you add in another interface to the mix there is bound to be some additional overhead.

    Let’s assume that you access the display and the SD card at 8 MHz and that you store ASCII data on the SD card to represent the bitmaps, in exactly the format that we had used in the serial port example. Let’s keep track of how much data needs to travel across the SPI lines for a given pixel to update.

    • A single byte stored in that file looks like 0xZZ,_ because it is in human-readable ASCII form. To get the pixel data (two bytes worth) actually takes 12 bytes from the SD card including the leading 0x’s, the commas, and the spaces before the next bytes.
    • Then you still need to send two bytes directly to the display

    So to update a single pixel from the SD card you need to transfer 14 bytes as opposed to just two bytes directly from memory. That 7x reduction in speed leaves you with about 7 Hz, not to mention the time that your program needs to take to parse the incoming ASCII data. Accounting for the fact that there is probably additional overhead I’m not surprised to hear about a 2-3 Hz refresh time - I apologize if that was misleading in the first comment.

    Let’s talk about optimizations:

    1. Come up with your own file format that directly stores the bytes in binary, as opposed to encoding them as human-readable ASCII characters. This should get you to roughly 25 Hz (transmit 2 bytes from SD and 2 bytes to display for each pixel).
    2. Try reading from the SD card at the highest speed possible (approx 20-24 MHz) by switching the SPI settings each time (and back for the display of course)
    3. Try writing a compressed file format to transfer even fewer bytes from the SD card for each image. (This is only an improvement when the image is suitable for compression)

    Just as a curiosity pleaser for anyone reading this: you might wonder how real video monitors can refresh so quickly when this screen can’t. There are a lot of technologies that support this but two big ones are parallel ports and direct memory access. With a parallel port 8, 16, or maybe even 24 bits can be transferred in every clock cycle - leading to speeds closer to 240 Mbps (or 10 megapixels per second for a 24-bit deep screen). Direct memory access can allow direct communication between an external flash memory and the display or enable data transfer to occur in the background while the microcontroller performs other tasks.

  • Hmm, video streaming can be very resource intensive. Let’s also assume that you are using something with a little more oomph like a Teensy3.6 or a SAMD21 board. My strategy would be this:

    • read up about the various video encoding methods that exist, particularly those that you have in mind for the project
    • keep only enough data in the controller’s memory to handle one frame at a time
    • try to minimize the work done by the brains to update the frame by only modifying pixels that change
    • update the entire screen with that frame buffer at the rate you’d like.

    That’s one of many ways to go about this, however there are many more!

    We’re happy to help, but deciding on the specifics of your video protocol and writing code to convert other video formats is more than I can chew at the moment. Perhaps you could see if anyone else has written an open-source solution to this problem. If nobody has then its a great opportunity for you to do it! (If you do please share with me on GitHub and I’d probably take a peek)

  • Thanks for the fix! I’ll update the link. - Oops looks like M-Short beat me to the draw at high noon

  • isn’t it surprising to see such a large part in cut tape? I’m also trying some FPC connectors that come in 50mm wide tapes. Thats the SMD Barrel Jack that I am putting on some exciting new IoT hardware for powering it in the field! Keep an eye on the new products list in the next couple of weeks and you’ll spot it.

  • Hmm, I see where you’re coming from on that one - 120 people seems like a little much for a completely open floorplan. To me that says “high school cafeteria” not “workspace.”

  • Good thing I didn’t show off my fuzzy pink bunny slippers that I wear when assembling boards ;) But actually I’m open to recommendations for better ways to keep the uCs, how would you do it?

  • Definitely… something I am getting used to is how to interrupt the other people. If I waited until they looked up then I might be there all day, so generally I just try to walk into their peripherals and then make eye contact. I guess its sort of like knocking on an office door to see if they are busy.

  • Glad you asked! That’s a 3D model of the airplane that a friend and I designed in our senior year at school. The goal for the airplane was to halve the fuel consumption of the Cessna 172 while serving the same mission. So basically it is a glider with a big cockpit. I’m particularly proud of the canopy design because it would provide panoramic views (hard to see in a 3D print though haha).

No public wish lists :(