SparkFun Forums

[bushing]

So, I'd like to build some devices to allow me take signals destined for one of these things: HCMS-2912 led display. (It's basically one big 320-bit shift register, where each bit drives a pixel.)

... and transmit it over a short-distance RF link (<10ft) using something like one of the Nordic / MIRF transceivers, and then have a receiver which drives one of those displays with the data received over the RF link.

Half my work is done for me -- I found this design which is more than enough to do the receiver, using an Arduino: http://www.junksoup.com/address/address_schematic.pdf

I *think* they're using 5 GPIO lines to do something like SPI there -- it's transmit-only to the display. So, now I just need to do the same thing in reverse -- make something that has 5 input lines and multiplexes them into a bitstream for the RF chip. I understand how to do bit-banging serial output, but what's the best way to do bit-banging serial input? Would I need an ATMega-class chip to do that, or would one of the ATTiny series suffice?

Thanks! -b

[inventore123]

I worked with an HCMS3976, which is very similar. These displays are awesome, easy to use and they are the only led displays I've seen to be truly daylight viewable.
My suggestion is to use the nRF24L01 devices and an atmel mcu in both transmitter an receiver, transmitter sends an ASCII string to be displayed, so for an 8 digit display you only need to send 8 bytes, receiver decodes ASCII into "fonts" to be displayed.
Consider that in the receiver you'll have to store a big array in flash for the fonts (example: 128 fonts -> 128*5=640 bytes) this together with the C code that manages the nRF and the display will probably fit into a 2KB ATtiny. The mcu in the transmitter depends on what you want to do.
Also consider that there is no need to read data from the display, so the output of the "shift register" can be left unconnected
Hope this helps

[bushing]

I worked with an HCMS3976, which is very similar. These displays are awesome, easy to use and they are the only led displays I've seen to be truly daylight viewable.
My suggestion is to use the nRF24L01 devices and an atmel mcu in both transmitter an receiver, transmitter sends an ASCII string to be displayed, so for an 8 digit display you only need to send 8 bytes, receiver decodes ASCII into "fonts" to be displayed.

Great! Yeah, they really do look nice. Do you happen to know a good place to get them, at a reasonable price? Digikey and Mouser both sell them for about $32.

I'm trying to interface with an existing device -- a radar detector. I want a "transmitter" that I can solder in place of -- or in parallel with -- the existing HCMS display, send bits over RF, and then decode. The thing I really don't know how to do is capture the datastream going into the original display -- is there some way I can use the HW UART to clock the bits in for me automatically, or do I have to sit in a loop and sample the clock pin and watch for transitions (please say no!), or ...?
-b

[inventore123]

Unfortunately I don't know a place where to get those displays, but you can always add them in the "new product ideas" section of this forum ( I suggest the HCMS3976, it's the best, much brighter)

About the other question, it is definitely possible to read data without polling. I suggest one of these two options to connect an ATmega or ATtiny to the display in a way that the AVR reads all what is sent to display:

1) Use hardware SPI, that can work as slave, connect clock of display to sck pin, data input of the display to mosi (master output, SLAVE INPUT), and the display's chip enable pin to ss (slave select). Then just wait for interrupts and in an internal register you can read your data.

2) Connect clock of the display to an external interrupt pin of AVR, and configure an interrupt on rising (or falling, I don't remember) edge. Then in ISR read data bit and every 8 interrupts you've got a byte of data. More complicated but your SPI is free to be used for something else (driving the nRF24L01, for example)

Let me know if it helps, and if it works

[bushing]

1) Use hardware SPI, that can work as slave, connect clock of display to sck pin, data input of the display to mosi (master output, SLAVE INPUT), and the display's chip enable pin to ss (slave select). Then just wait for interrupts and in an internal register you can read your data.

Really, I'm going to have to fab a board with BatchPCB to do this the right way -- but I don't want to go to the effort if I won't be able to do it. So, to reassure myself that it is possible, I took a little C8051F330 dev board I had and hooked it up to the data, clock, CE and ground lines on my radar detector:




I wrote a silly little program to grab bytes off the SPI lines and store them in memory, and then just dumped the memory. After a little post-processing, I ended up with:

Code: Select all

     31: #         .
     32: #         .
     33: # #####   .
     34: ##     #  .
     35: ##     #  .
     36: ##     #  .
     37: # #   #   .
     38: #         .
     39: ##     #  .
     3a: ########  .
     3b: ##     #  .
     3c: #         .
     3d: #      #  .
     3e: #      #  .
     3f: ########  .
     40: #      #  .
     41: #      #  .
     42: #    ###  .
     43: #   #     .
     44: ####      .
     45: #   #     .
     46: #    ###  .
     47: #         .
     48: #         .

So, it looks like this may actually be doable. I'll still go with an AVR-based solution because I like being able to use GCC -- I'll post back with more results later. Thanks for the help!
-b

[inventore123]

Another thing that you might find useful:
those displays have a "register select" pin that allows to send them data or commands (change brightness and other things). You may need to connect that pin to your micro to avoid sending commands to the display as if they were data, because this might produce wrong image to the display.
Most programs send commands to the display only at startup as part of the initialization code, so you might simply poll the rs pin at the beginning of your code and wait until it becomes low (low=data; high=command) or use an external interrupt on pin change if you absolutely need to avoid polling.