Looong bit-string shift out

yarisboy

I'm going from a serial device that took a 24-bit shift out to three of the chips in cascade. That means I have to shift out 72 consecutive bits to load all three 4x7 segment displays. I suppose I could load the data into a byte array and then shift it out in a nested loop. That would be 8 (bits per byte) as the counter in the inner loop and 9 as an array index on the outer loop. By asking here first, I'm trying to find out if there is a much easier way.

ericball

Although it would require some set-up (and has some restrictions and other quirks), the video generator can be used as an output shifter.

lanternfish

Tell us more, please!

yarisboy

lanternfish wrote: »

Tell us more, please!

While still studying the Prop Manual with scratch paper at-the-ready it appears I need a configuration byte array [8] in my VAR section along with a display-data byte array [10].
In addition I need a byte location reference in a DAT section (syntax 2) with 12 values set at compile time. These values are sufficient, when written to the configuration array, to control all possible needed configurations of all 12 4x7 segment displays. So far I'm reading 3 frequency inputs and one serial input to collect the data I need to run through four case statements. This should allow control of all three displays and the LED intensity based on one of the frequency inputs tapped from the Toyota Yaris dash wiring to it's ECM. With the MC14489 the first nibble of the each display's data register controls the decimal point and the display intensity. The second nibble actually sends the hex code of what will show up on the LED. I've never used the case statement before so I keep you posted, but then I've never used bytefill before either and I will need it. All my objects for a single display are good practice but the triple display application is starting to be a complete top-down design effort. This project is a good study of memory management and control for the Prop.

JonnyMac

I found an SLED4C module in my parts bin and whipped up a quick demo based on the data sheet.

http://www.rentron.com/Files/SLED4C.pdf

The SLED4C uses the MC1449 so this may be helpful to you.

JonnyMac

Here's a variant of that program that will be better if you are cascading the MC14489 chips. By moving the Enable control out of shiftout() you can send the sequences required using multiple calls to shiftout().

yarisboy

Here is a so-far-non operative program I'm working on to shift-out byte sequences 8 bytes long for configuration and 10 bytes long for data. When I find out how to pass a DAT symbol properly to my shiftout method this little program should give me "props rule" on my triple display. As you've guessed, it doesn't compile yet.
Thanks JonnyMac. If it can't be done, that gives me a fall-back attack strategy. Since my earlier shiftout had no trouble with 1 and three bytes that's a feasible plan. I may also make a far simpler test program and spit the bits out to the PST at a slow rate to find out what can be made to work. Even a monkey can exhaust the possibilities given an eternity.
On second thought, I'm going to try embedding one memory symbol in my method (shiftout) and then just pass the index and the number of bytes required at call time to access the right section of the DAT table. This should be much more the way the Spin authors intended syntax 3 to be used.

JonnyMac

...so-far-non operative program...

With respect, you seem to be making this much harder than it is. Remember, the MC14489 is nibble-oriented, and while trying to pack two nibbles into a byte is not hard to do, it's just more work than is worth doing.

Here's (yet another) demo that shows how to send messages from DAT tables -- really easy. Note that the display is blanked before updating to prevent any ghosting.

yarisboy

JonnyMac wrote: »

With respect, you seem to be making this much harder than it is. Remember, the MC14489 is nibble-oriented, and while trying to pack two nibbles into a byte is not hard to do, it's just more work than is worth doing.

Here's (yet another) demo that shows how to send messages from DAT tables -- really easy. Note that the display is blanked before updating to prevent any ghosting.

I'm learning spin and memory management for more challenging projects in the near future.
Thanks for the respect but being hard-headed I invent some of my own anguish. The MC14489 is just a hapless obsolete chip found in my "paid-for" electronics junk drawer. I've modified my speedometer wiring and code to read and write longs from the DAT table successfully. With the alignment of the least significant digit with the least significant nibble/bits the code reads naturally for me. I just use the 24 bits on the LSB side of the DAT table longs. Thanks to JonnyMac and Andy Lindsey even I can learn Spin. I still have to break through the two displays challenge on the breadboard.......but the night is young.
Thanks for the code. It helps. read-code-test-repeat. Even the data sheet tells me I can break up the transfers to the different displays. Gotta work on that.

JonnyMac

The new version of shiftout() -- that removes control of the enable pin -- was coded to support cascaded displays. I don't happen to have two chips so I cannot test here, but given my experience with similar devices, I am very confident that you now have the tools (if you choose to use them) to move forward with your project.

yarisboy

OK,here is the latest. Using a nested loop it correctly shifts out 8 configuration bytes followed by 10 data bytes. It is displaying the hex characters " 0123456789Ab" I cranked up the clock to 5500 Hz so it is running synchronous. The trouble is the second and third display flashes off and on a little. Sometimes all three flash. I was going to program in "JonnyMac" but there is no y in the special character set.

yarisboy

As promised here is the version that displays "PropS ruLE". I toned the clock pulse down to 5 KHz and put about a 1/2 clock cycle delay in after the configuration load and after the data load. You have to watch a long time to detect any display jitter now.
I've never made an OBEX submission but it does demonstrate a way to shift-out any specified number of bytes for devices such as the MC14489 triple display set. Now on to the tach/speedo/temp gage set.

JonnyMac

In my message demo I showed how to prevent the flash:
-- send config bytes to turn off displays
-- send data nibbles to the displays
-- send config bytes to enable the displays

Yes, seems tedious, but keeps your output tidy.

yarisboy

JonnyMac wrote: »

In my message demo I showed how to prevent the flash:
-- send config bytes to turn off displays
-- send data nibbles to the displays
-- send config bytes to enable the displays

Yes, seems tedious, but keeps your output tidy.

I'm going to order another tube of chips soon. I'm out. I like the tidy format. When I get into eleven different configuration modes for three readouts I'll need that to prevent migraines. When I open the files they are in black and white. Do you use the Propeller tool or BST? Fortunately I don't have to understand the display registers to use blanking successfully.

JonnyMac

The forum seems to add ".txt" to Spin files -- I see that when I look at files, too. Just copy and paste from the text editor that the files opens with into the Propeller Tool (which is what I use).