SimplyTronics 8x8 RGB LED Matrix
tomcrawford
Posts: 1,126
So I got my four pieces earlier this week. I got the Device IDs set (0 thru 3) and they are connected in a 1 x 4 row. Here is a video using the 5 x 8 font. http://youtu.be/kMIj4PnbAic
I have a few questions:
1) I like scrolling text. Should I plan on the Scroll functions (RollLeft/Right/Up/Down) being implemented in the near future? Clearly they involve transferring data among modules and I think maybe that is why they don't exist.
2) If I download new firmware, will I have to physically disassemble my array to install the new firmware?
3) If I install new firmware, do I have to set the Device IDs again (which involves disassembling the array).
I have a few questions:
1) I like scrolling text. Should I plan on the Scroll functions (RollLeft/Right/Up/Down) being implemented in the near future? Clearly they involve transferring data among modules and I think maybe that is why they don't exist.
2) If I download new firmware, will I have to physically disassemble my array to install the new firmware?
3) If I install new firmware, do I have to set the Device IDs again (which involves disassembling the array).
Comments
1- You correctly identified the hardware limitations for implementing scrolling functions in these modules. We won’t be able to implement them in these modules. Unless somebody figures out a way to do it with a single, shared communication pin (we are sharing the firmware because there are a lot of Propeller experts in this forum and may figure out to push the limits of this hardware in creative ways).
2 - 3- Yes, Downloading firmware requires connecting the module via a Prop Plug and we recommend disconnecting the module from anything else. Also, loading the new firmware resets the ID and PSS values to 0. For setting the ID only one module has to be connected to power so you need to connect only one at a time. The only value that could be updated in parallel to all modules is PSS since all of the modules will receive and use the same value.
During the design of these modules we contemplated different options to set IDs and with the limited PCB space we went with the firmware option (instead of using jumpers or dip switches). That’s how Rev A modules were designed and if there was any clever way to load new firmware and set module ID without having to work on individual modules it would probably require a hardware change. We could certainly revise the design and include this feature in Rev B.
I had a wireless communication project that required each device to have a unique ID, having the ID number saved in upper EEPROM made firmware upgrades much easier.
1. If the four SIO pins were separate, then communications between modules would be straight-forward. But then you would have problems distributing commands. I plan to scroll text by re-loading the entire array each time I write a new column of pixels (using my own font).
2. I agree with Duane Degn above about building the Device ID into the firmware. You would have to compile an individual download for each module, but as it is now you have to individually fiddle each module anyway.
3. I put a new demo on youtube that changes colors each time the character is moved. Sadly, my camera does not do justice to the colors displayed which really look quite good. http://youtu.be/k5heiNbJhH0
Good idea. That would take care of the ID value.
Firmware could need to be updated sometimes though, if a new customer image is loaded and maybe if extra fonts were loaded.
Even though we don't recommend to upload firmware with the modules interconnected forming a screen you could still upload firmware on each module by connecting power to the whole screen and the Prop Plug to each module receiving the new firmware (the serial communication will go to other modules but RESn is only connected to the local Propeller so only one module firmware will be uploaded at a time). Since the current setup requires you to load a new ID one module at a time there was not need to load firmware to the modules still interconnected.
But If the ID was stored somewhere else, we could refresh just the firmware by itself. Since the same firmware should be uploaded in each module, is there any other way to upload the same firmware in all the modules by a single connection point so the operation doesn't need to be repeated one module at a time?
David, I think that the next revision of the display should include a 4K7 Ohm resistor in series with the Propeller chip pin. This resistor protects the Propeller chip running at 3.3 V while connected to 5 V microcontrollers, as suggested by Parallax Semiconductor AN010: http://www.parallaxsemiconductor.com/sites/default/files/appnotes/AN010-MixedVoltageInterface-v1.0.pdf (now we ask customers to add this resistor if they connect to a 5V microcontroller in the product doc).
We still need to check if adding this resistor in the PCB could cause any unwanted secondary effect. But if the resistor can be added on-board you should be able to hack the firmware to do some interesting things, right? :-)
I'm having the same problem with video!
I have the 2x2 module (16x16 pixels) demo running and just need to find a way to take a decent video so I can share what the demo would look like. I'll play with light levels over lunch and hopefully will have something to share in the afternoon.
The ROM loader doesn't allow multiple parallel modules to be loaded, but there's no reason why a program can't be "permanently" stored in each module that can download to all (or selected) modules in parallel. The Propeller Backpack works somewhat this way in that a loader is pre-loaded into the Backpack which can download a program over an ordinary serial connection (like from / through a Stamp) at lower Bauds than the ROM loader expects. This loader is designed to protect itself from being overwritten and there's a modified version of the BST PC downloader that works with this. The existing Backpack loader and PC utility could be modified to allow for parallel loading.
BTW, Ari, if you want to get the software community involved in firmware development, you really do need to publish the schematic for this product. That doesn't mean that it's open hardware or that you have to provide a board layout.
-Phil
Yes, it makes sense that to push the limits of the module anyone would need more information.
I'm attaching the schematic. Enjoy!
If anyone is interested in playing with the firmware let me know and I'll try to get you some modules (Parallax is out now but we have 100 more in transit by air. I also have 4 modules I can forward to somebody with time to play with them once I'm done with videos).
ST-00050 8x8 RGB LED Matrix Display Module Rev A.pdf
-Phil
I am re-writing the entire array each time a new column of text is available (I am using my own 5x7 font). Here are some code fragments:
DataXfer.spin
I think this is about as fast as I am going to be able to scroll by reloading the array for each column. Here is a little arithmetic. At 57600 baud, one bit takes 17.4 usec. The comments on the simple_driver say 57600 max baud rate and that is as fast as I was able to make it run.
I have to send 32 columns of 8 pixels each at 3 bytes each equals 6144 bits. Add another 25% for overhead because of asynchronous protocol (start/stop bits) for a total of 7680 bits. Times 17.4 usec per bits says .133 seconds per frame. Or 7.5 frames per second. And that is just for 32 columns. I plan 128 columns as soon as I can afford another 12 modules.
So I think I can try one of two different approaches. 1) I could modify the firmware (well, I could try) to accept two bytes per column (the bit pattern and one of color index) which would mean transferring 1/12 as much data. or 2) I can re-send the frame in the form of ASCII by moving the X position of each character by one. But I need to see how well the current firmware deals with beginning characters to the left of the screen (to scroll gracefully off the screen) and will need to fiddle the font because I use some custom characters.
So is that as fast as it can scroll with the current firmware?
I wonder about modifiying the firmware so all the modules know what will be displayed ahead of time and then just use the serial connection to synchronize the modules. That way you wouldn't need to transmit so much information and you could keep all the color resolution.
I'm planning a making an array using 16 8x8 RGB modules I purchased off of ebay. I see I haven't mentioned it in this thread so I'll post a link to the thread I started about it.
Here's the video (it's a boring video, start watching at 2:56 when I show it scrolling text with a rainbow effect). The font is something I found on the internet. I plan to have several fonts to choose from.
I don't have full 24-bit color since I'm using shift registers but 15-bit color still looks pretty good IMO.
Thanks for making a posting the video.
So each module keeps a complete image of the entire frame and only displays its portion. Sounds good to me. I would need an array of 8 * 128 * 3 or less than 4K bytes.
I am using the built-in 5x8 font. To scroll, I re-write the entire array five times (once for each column) for each ASCII character. It is fast enough for an array of eight characters but certainly not fast enough for a full stick of 16 modules (22 characters). The (main?) reason it is not fast enough is I have to transmit 45 bytes for each ASCII character. (ASCII_0508 expands into five calls on TxDatPackHead). So I don't think this approach is going to work.
Here is what I hope to do, and I am asking advice as to whether it is likely to work. I will modify RGB_LED_Matrix_firmware.spin dated 2012- 11- 02 as follows.
1) I expand wGDRAM to 1024 longs. This is enough to contain the entire image of the frame in each module.
2) I modify the code that watches data transfers from the host so that each module keeps the entire frame.
3) I change the code that transfers from wGDRAM to MatrixGDRAM to that it transfers the correct "slice" according to DeviceID.
4) I add code to shift the entire frame to the left (West). Left-most column is lost, right-most column is zeroed.
Then I modify my driver to scroll by sending the left-shift command and writing the right-most column.
Specific questions.
1) Is the above-named .spin firmware what is actually loaded on my four modules now?
In other words, will I break my modules by compiling and downloading version 1.0 dated 2012 - 11 - 2?
2) What am I missing from the above plan?
3) Is today my lucky day?
There are 4 bxGDRAM buffers in the Propeller RAM, you can send the data to the wGDRAM and then copy to b0GDRAM, b1GDRAM, b2GDRAM and b3GDRAM. When you need to display the "frame", you can just tell the module which one you need to show on the screen.
The 57600 bps baudrate is recommended, you can try the baudrate to 115200 bps. The serial communicate driver is a modify version of serial driver with 512-bytes Tx and 512-byte Rx buffer. This could make sure the module could still receive the command while dealing with the data(The ASCII converting, drawing could take some time).
Because only one pin(all right, if the PropPlug port counts, maybe two pins) available and the color data is 24-bit, so the asynchronous packet is a little long. If you want to change the firmware, why not add an character mode? You can enter and exit character mode by using special command, and with a very short asynchronous packet.
The default firmware is the GCC version. But don't worry, if you have the PropPlug, you can restore the firmware(If you don't like to set up the PropGCC environment compile the frimware by yourself, we can send you the binary file and the loader, ~150KB only). Spin version runs slower.
Yes, you need to set the Device ID and PSS again after the update the firmware.
PS: We are going to release a very simple software which can be used to configure the module(set the DeviceID and PSS) and update the (Spin & GCC)firmware.
Here is a simple struct of the module, you may need.
Yes, could you please send (or post) the binary of the C version. I'm a spin/PASM kind of guy.
I'll start by downloading the spin version into just one module and see what happens.
Here is the binary file of C version, with a stand alone loader which is a part of the PropGCC compiler.
Un-zip the files and run the DownLoad.bat would start the download process.
ST-00050-C-Firmware-V1-0-binrary.zip
I downloaded RGB_LED_Matrix_firmware.spin into a module and it seems to run just fine at 38.4K baud but not at 57.6K So far so good.
I am planning two new functions:
1) SetPacketSize which merely records the number of ASCII characters in a Packet and which I call just once in the beginning
2) ReceivePacket which will
ReceivePacket
PointerX := -RxLengthValue 'offset for leftmost ASCII char
FillGDRAM (0)
repeat PacketSize
{ receive character and ForegroundColor in next four bytes
DisplayASCII_0508
PointerX := PointerX + 6 'to next character position }
UpDateScreen
which I call five times for each character as it scrolls onto the screen from the left.
I did this by making some changes to the spin version of the firmware.
1) I keep a copy of the entire image in each module. There is lots of room for at least 16 modules or maybe even 32. Each module displays its slice of the image according to its DeviceID.
2) I scroll by implementing RollLeft. The way the wGDRAM is organized, you can scroll left with longmove(@wGDRAM, @wGDRAM+32, NbrCols*8). I think that is pretty cool.
3) Now I just need to write eight dots at the right edge to insert the latest column. I implemented my own DOTRIGHT which transmits three bytes of color and one byte of Y position. The firmware knows to use NbrCols-1 for the X position. This means I need just one packet per dot rather than three which finally gives me enough speed for a pretty decent scroll (at 38.4K baud).
So for each character (five columns of font plus a blank column),
......RollLeft
......Eight DOTRIGHT
......UpDateScreen
If I could make suggestions for SimplyTronics 8x8 RGB LED Matrix Revision B:
1st) Note that the current code (at least the spin code) has all the modules arguing on P31 at the same time when the code starts up or anytime the controller issues an report command.
2nd) Use either P30 or P27 for a clock pin and implement synchronous I/O. That would give you an order of magnitude faster data transfer. (You'd need a four-pin interface)
3rd) Make provisions for physical mounting.
This version is much faster than your earlier one.
Could you modify the code so each module waits its turn to communicate when a report command is issued? I'd think you should be able to use the module's ID number to determine when its turn to communicate is.
I wonder if a different font would be easier to read when your text is crusing along the way it is now? The text demo I linked to above uses a font that's mostly two pixels wide. Here's another example I did with Christmas lights.
I don't know how hard it would be for you to try a different font, but if you're interested in trying the one I'm currently using, let me know and I'd be glad to post it. I'll likely post in the next couple of days anyway as part of my Christmas lights driver.