Trans-Lux display & Propeller
mlctrez
Posts: 9
in Propeller 1
Hi All -
Back in 2008 I picked up some surplus Trans-Lux displays from a local electronics salvage store. I've driven one half of a display using an ATMega168, but that was really at the limit of what it could do
Some pictures here: https://goo.gl/photos/TfGjPaihxif2U6dF7
In 2009, I ordered a few Propeller Proto Boards (#32212) thinking that someday I would get around to working with these displays again. I'm thinking that day has arrived!
Driving these involves using clock and data lines to shift in 320 display bits, three more bits to select which row in the 5x7 characters light up, and then pulling an enable line low. This repeats for each of the 7 rows that make up the 5x7 characters. The input connector has two sets of clock/data/enable, one for the top two rows of characters and another for the bottom two rows. From the photos you can see I was using only one of these sets - only half of the display is lit.
I'm thinking that the Propeller is going to work for this and two cogs could drive both halves of the display. Each cog would just be a loop to read data from a shared address space and send it using clock/data/enable. Another cog could read the serial port to allow external input to manipulate the display data.
So, am I going down the right path here with my approach? If so, does anyone know offhand of any project doing something similar?
Thanks for your time,
Matt
Back in 2008 I picked up some surplus Trans-Lux displays from a local electronics salvage store. I've driven one half of a display using an ATMega168, but that was really at the limit of what it could do
Some pictures here: https://goo.gl/photos/TfGjPaihxif2U6dF7
In 2009, I ordered a few Propeller Proto Boards (#32212) thinking that someday I would get around to working with these displays again. I'm thinking that day has arrived!
Driving these involves using clock and data lines to shift in 320 display bits, three more bits to select which row in the 5x7 characters light up, and then pulling an enable line low. This repeats for each of the 7 rows that make up the 5x7 characters. The input connector has two sets of clock/data/enable, one for the top two rows of characters and another for the bottom two rows. From the photos you can see I was using only one of these sets - only half of the display is lit.
I'm thinking that the Propeller is going to work for this and two cogs could drive both halves of the display. Each cog would just be a loop to read data from a shared address space and send it using clock/data/enable. Another cog could read the serial port to allow external input to manipulate the display data.
So, am I going down the right path here with my approach? If so, does anyone know offhand of any project doing something similar?
Thanks for your time,
Matt
Comments
Welcome to the Prop forum
You will probably use 3 cogs for this.
Serial cog running the FullDuplexSerial object
Lux driver cog
Cog to handle the data transfer between the other 2 cogs
The simplest way will be having a hub buffer holding all display characters. Then the lux driver cog will just keep displaying this set of characters. Get this part working first. Then you can expand to have the serial update the buffer. Once working you can use a hub flag to indicate when updates are required to save power as I am guessing the lux panel is intelligent in that it has latches for each character that do not need updating unless the content changes.
Anyway, we are here to help. So just ask. Use the (code) and (/code) tags to post code. Note replace ( and ) with less-than and greater-than characters.
I started just with a main loop to prove out some basics. Here's my code:
What I'm finding so far is that the speed of the built in shift_out library code is not fast enough.
Is it possible to increase the rate data is shifted out? Or drop down to lower level code to achieve this?
Cluso99 -
Unfortunately, the board is not that smart. The shift registers are shared for each of the 7 rows in the characters, so keeping the board lit involves constantly sending data to it even if the data for the characters have not changed.
Thanks,
Matt
I had to restart SimpleIDE to pickup the changes.
but changing to
results in no output on the display. I'm probably missing something else here.
Probably easiest to write a Simple PASM program that just updates the display from a buffer of characters in hub.
Not sure how C handles a PASM cog ???
If I remember correctly you can like LMM or CMM also create COG code.
But starting a cog requires that THIS startet cog sets the Pins it uses.
So on start of your void bottomdisplay() you are missing:
// set P00 to P07 to output
DIRA |= 0b11111111;
// set P02 and P05 high, and everything else to low
OUTA |= 0b00100100;
OUTA &= 0b00100100;
it has to be done in the same cog.
Enjoy,
Mike
Thank you both for more suggestions.
@Cluso99 - I'll see if the C approach works out and keep PASM in the back pocket. What I've found with the C code now is that I should be able to drive 4 displays wide with only a minor amount of flicker.
@msrobots - Thanks. That makes sense. I suspected there was something like that that I missed.
I've attached a photo showing the display with randomized bits shifted in.
This photo and a video have been added to the album linked in the first post of this discussion.
Now to figure out how to get something readable displayed.
I would be grateful for any comments regarding how I'm using shared memory, particularly so if I'm doing it wrong.