Newbie with DMD display & needs to speed up loops

Buzby

Senior Member
... I had to move several lines of your code update, because you had DISPenable & ROWdata in a few odd positions.
Oh the joys of programming by proxy !.

Please post your latest code, so I can get back 'in sync'.

I'll give it another look to see if I can tweak a few more Hz out of it.

Cheers,

Buzby
 

hippy

Technical Support
Staff member
The "For Row = 2 To 32" can become "For Row = 0 To 30" which should shave a few microseconds off, or drop the FOR-NEXT and repeat what's inside it another 30 times.

There likely will be some flicker seen out of the corner of an eye; even televisions used to do that. You have to go to quite high refresh rates to avoid it.
 

hippy

Technical Support
Staff member
Also allocate the hardware pins if not already ...

DISPenable = B.0
COLUMlatch = B.1
ROWclock = B.2

That will also make things faster.

That allocation is based on Buzby's code; if you are changing that then a different allocation may be better. Perhaps post the full code actually being used.

It's worth checking if DISPenable needs to be activated per line or can be used per frame. The more you can strip out the faster refresh will be.
 

OLDmarty

Senior Member
New code, speed-modded, aka v4.0 is attached....


...and here's a clip of my Dracula pinny, to give you an idea on the kinds of animation, layers & shading techniques often used on all DMD pinnies...
I believe the 'shading' is a matter of writing (or not writing) certain pixels during each frame update.
For example, with 4 pixels on the screen (from left to right, known as 1,2,3 and 4).
pixel 1 gets data during frame 1,2,3 & 4. = 100% brightness.
pixel 2 gets data during frame 1,2,3. = 75% brightness.
pixel 3 gets data during frame 1,2. = 50% brightness.
pixel 4 gets data during frame 1. = 25% brightness.

So, every 4 frames scanned will give the shading effect in comparison to eachother.

[video=youtube_share;xRPpi17RTG0]http://youtu.be/xRPpi17RTG0[/video]



Regards,
Marty.
 

Attachments

Buzby

Senior Member
So, every 4 frames scanned will give the shading effect in comparison to each other.
Yes, that's exactly how it's done. It's animation of 4 frames with the shaded pixels being the only differences between frames.

The PICAXE DMD animation rate is probably never going get high enough for shading, but it's definitely going to be enough for doing the sort of animation you have shown.

When we get on to the 'source' PICAXE we'll get a better idea, but I think shading is going to need some hardware changes.

--

From what I have been trying over the last few days, I think that a really fast DMD controller could be built using a PICAXE and a couple of hardware chips.
If I ever get a real DMD I'll try building one, but I'm not getting into hardware and software by proxy !.

--

How is the 'source' coming on ?.

Cheers,

Buzby
 

Buzby

Senior Member
Just a point. The 'real' DMX controllers probably allow selective updates to the buffered frames, that's how you can get real speed.
We could do that quite easily with the existing config, but the downside is that the software would need to be 'tuned' for each frame.
 

OLDmarty

Senior Member
OK, an update...

I removed the For..Next loop for lines 2-32 (or 0-30 as later pointed out by hippy)...
Refresh rate increased dramatically from 29Hz to 35Hz.

I then removed the DISPenable hi/low in each of the 32 lines, which acheived several things:
- 39Hz refresh rate
- ghosting due to the DISPenable not being turned off during data updates.
- BRIGHTER LEDs, approx 50% brighter in fact.
I think we're controlling the DISPenable to often or too quickly.....this *IS* mentioend in the wiki writeup, about using PWM on the DISPenable to adjust overall brightness...

I tried putting DISPenable at the beginning of line1 and at the end of Line32, but it still ghosts overall...

Either way, at 35Hz or 39Hz, the DMD is ROCK SOLID, no flicker (even at peripheral vision) and VERY comparable to my Dracula Pin, when i do the 'eye-scan' of them ;-)

I was also thinking more about the PULSOUT commands, don't they hog a lot of time? maybe we replace each pulsout with a "high pinX" and "Low pinX" if that knocks out more delay?


Pictures below are ALL the factors above, 39Hz, Bright LEDs & ghosting....
Note: the top 6 rows have DISPenable still in place, and Rows 7-32 don't have DISPenable used, hence the brightness.
DMD_4.1mods_full.jpg

DMD_4.1mods_empty.jpg
 

OLDmarty

Senior Member
Hi Buzby,

I haven't dabbled with the source side yet, still need to move some wiring for it etc...

I *think* i have a reasonable condition plasma DMD here, i could send it to you, but you're going to need a few mixed voltages to get it running, like -110, -65 +12 etc etc...

You might have luck at a local pinny restorer, finding a junky DMD and decent transformer from them?

Marty
 

OLDmarty

Senior Member
A journey into the unknown?
Sorry to interrupy, but
re. post #79
"At this point, i'm not sure if we've maxed out the 28X2 (code efficiency & speed)
and *maybe* i have to look towards a higher speed alternative to picaxe? unless there's a pic/picaxe that does 100mhz?"
Totally at your own risk, see posts 4, 6, 7 and 8 here:
http://www.picaxeforum.co.uk/showthread.php?17369-New-28X2-64-Mhz-at-5v-is-this-real&highlight=28X2+100MHz
Yep, Thanx i saw that a while ago, i've never been one for over-clocking ANYTHING....

I'd like to see how the 100MHz picaxe is holding up in a few weeks/months time, assuming it would be ON a lot of the time to help it 'burn in'.....
 

hippy

Technical Support
Staff member
I was also thinking more about the PULSOUT commands, don't they hog a lot of time? maybe we replace each pulsout with a "high pinX" and "Low pinX" if that knocks out more delay?
No PULSOUT has three tokens "<PULSOUT> <pin> <time>" whereas consecutive HIGH and LOW would be four "<HIGH> <pin> <LOW> <pin>" so PULSOUT will be quicker to execute.

What often does help is giving <pin> the lowest numeric value possible to create a shortest token which is B.0 and B.1. Hence the suggestion earlier for allocating the most frequently used pins to B.0 and B.1.

In normal programs it doesn't usually matter which pin numbers are used but it can have an affect when trying to shave microseconds off a timing loop.
 

OLDmarty

Senior Member
I think that a really fast DMD controller could be built using a PICAXE and a couple of hardware chips.
Yep, i hear ya....I'm thinking maybe the picaxe basically handles the SPI data & clock to the DMD, while some external gating (or a 2nd picaxe, tiny '08m or FPGA) handle all the DISPenable, ROWdata, ROWclock, COLUMlatch signals to the DMD.
Perhaps during each line being processed in the 'Driver' picaxe, a signal could be sent to the external chip/picaxe to process timing signals in synch with the row-data in the driver picaxe.

This might eliminate a whole bunch of pulsouts and for..nexts from the main picaxe and get things speedy again.


There's 10 ways to skin a cat.....or 11 if you try harder ;-)
 

Buzby

Senior Member
.. the picaxe basically handles the SPI data & clock to the DMD, while some external gating (or a 2nd picaxe, tiny '08m or FPGA) handle all the DISPenable, ROWdata, ROWclock, COLUMlatch signals to the DMD ...
Er, no. Just the opposite !.

My idea is to have two ( or maybe only one ) humungous SPI ROMs, ( well physically they are 8 pin dips ), with the PICAXE doing weird and wonderful things with the SPI data line on-the-fly, so as to get self-refreshing multi-frame animations.

I'm interested in this idea, and from reading the specs on the 25LCxxxx I think it could work.

I'll if I can get hold of a humungous ROM or two I'll do some tests, but it won't be just yet, we need to get your 'source' working first.

Cheers,

Buzby
 

hippy

Technical Support
Staff member
That should work; a parallel 8 x big RAM/EPROM with a counter is what I considered for a PICAXE generating Composite Video or Ethernet and should work with a DMD. It should be possible with SPI/I2C ROM/EEPROM though it may be more complicated hardware.

Never actually tried it so good luck in getting something working.
 

Buzby

Senior Member
Hi hippy,

Not 8x parallel, just 2x, and no counter, just a 20Mhz clock.

I bet that's got you thinking !.

Cheers,

Buzby
 

Buzby

Senior Member
Hi Marty,

I'm still working on a faster source, but it's going to be a while yet, so just pop those three wires on and get the 2nd PICAXE fired up !.

A new version of DMD Creator attached. It's getting to the stage where it might need instructions, but play with it a bit an you should work it out.

Also attached is a new 'source', with some demo frames.

I'd really like to see how they come out.

Cheers,

Buzby
 

Attachments

OLDmarty

Senior Member
Hi Buzby,

Apologies, i'd been away the past few days, just catching up now....

Re: 'source' code, i got as far as migrating the code pattern into it, and creating a basic 'on goto' option to select frame A or frame B, but then came to a halt, as i wasn't entirely sure which remaining could was still required in the 'driver' code, like the 'comms fail, send A/B inverted frames etc...

I'll get into wiring the pics, and try your source instead, probably a faster solution. ;-)

Regards,
Marty.
 

Buzby

Senior Member
Hi Marty,

Leave the 'driver' code as it is. The frames stored in the driver are only used when comms is lost.

The demo 'source' should work OK, but any problems first thing to check is 'hsersetup' is the same baudrate on both.

Just a note about refresh rate on 'driver'.
The frequency of the 'DriverReady' pin is half of the DMD refresh rate.
So if you measure 30Hz, the refresh rate is actually 60Hz.

Cheers,

Buzby
 

Buzby

Senior Member
Hi Marty,

Are you still there ?

I'm waiting to see the results of our efforts.

Cheers,

Buzby
 

OLDmarty

Senior Member
Hi Marty,
Are you still there ?
I'm waiting to see the results of our efforts.
Cheers,
Buzby
Hi Mate, apologies, i'd been tied up with some work stuff the past week and barely been home.....

OK, i've wired the source pic into the driver pic, and loaded your source demo, i see the 'driver' code pop up as usual, then it goes blank (after the 4secs delay in the source code expires)...

I did want to confirm the resonator freq's, because i didn't think HSEROUT/IN would lock to correct bauds when running at 64Mhz (16mhz reso).
Currently, the source pic still has the 4mhz reso, while the driver has 16mhz, but i *think* i need to change them BOTH to 8mhz for HSEROUT/IN to lock up?

Changing DOWN to 8mhz will then increase our flicker problem again ;-(

Regards,
Marty.
 

Buzby

Senior Member
Hi Marty,

Good to hear you !.

Leave the 'driver' alone. As long as it brings up the default screens when comms fails it needs no changes.

The 'source' can run at any speed, so any resonator will do.
A lower frequency just means the frame 'update' rate will be slower, it won't affect the 'refresh' rate in the 'driver'.

The serial stuff is setup by the HSESETUP instructions near the start of both programmes.

The setup looks a bit like this :

' Setup serial
HSERSETUP B57600_32, 0

The 'B57600' is the baud rate. This number must be the same in the 'driver' and in the 'source'.

The '_32' is the frequency this PICAXE is running at. This can be different in each PICAXE.
In your case 'driver' has '_64' because it is running at 4x16MHz. The 'source' will have whatever speed it is running at.

The ', 0' is the background receive control, ', 1' in 'driver and ',0' in 'source'.

Are the various LEDs toggling ?

Cheers,

Buzby
 

OLDmarty

Senior Member
Hi Buzby,

Yep, i'd previously configered the 'HSERSETUP' commands to be:
Driver: HSERSETUP B57600_64, 1 (driver uses 16mhz resonator).
Source: HSERSETUP B57600_16, 0 (source uses 4mhz resonator).


At switch on, i seem to see the driver's internal pattern appear first, then it flashes to a half-complete pattern, then goes blank.
During the pattern flashing then going blank, i see the comms fail (RED) led flash 4 times, while the GREEN led on the source pic also alternates at half the rate of the RED led..

Truth-table of led flashes...

Both LEDs are on Port C.2 on each picaxe.

Comms....Source
Fail...........Pic

RED.........GREEN
1..............1
0..............1
1..............1
0..............1
1..............0
0..............0
1..............0
0..............0

and repeat cycle...


I removed the pullup resistor on C.0 of the driver pic, as it's now wired/controlled from the source pic.

Source to Driver wiring confirmed...
C.0 to C.0
C.1 to C.1
C.6 to C.7
and Driver C.4 still grounded (HSPIIN)


Regards,
Marty.
 
Last edited:

Buzby

Senior Member
Hmm ?...

More detective work needed, but it's going to have to wait till later today.

Please post both codes, I'll have a look.

Cheers,

Buzby
 

OLDmarty

Senior Member
No probs Buzby,

Attached are the latest codes, i basically just altered the HSETUP stuff, nothing more....

Re: Driver pic, you'll notice i still have the first 8-10lines of pattern info as per normal, and the remaining 20+ lines have the DISPenable lines rem'ed out from my previous tests with the brightness issues etc...


Marty.
 

Attachments

Buzby

Senior Member
Hi Marty,

I've not had chance to investigate the code properly yet, but the LED 'truth table' makes me think you have a wrong baud rate somewhere.

The 'driver' has a 16MHz resonator, is that right ?
If so the setfreq should be em64, and the hsersetup should be B57600_64,1

The 'source' has a 4MHz resonator, is that right ?
If so the setfreq should be em16, and the hsersetup should be B57600_16,0


You don't need to have the same resonators on both, just the same baudrates.

Cheers,

Buzby
 

Buzby

Senior Member
Just checked your code.

Mismatch in 'sertfreq' and 'hsersetup' on 'driver'

Should be :

setfreq em64
hsersetup B57600_64, 1
 

OLDmarty

Senior Member
The 'driver' has a 16MHz resonator, is that right ?
If so the setfreq should be em64, and the hsersetup should be B57600_64,1

The 'source' has a 4MHz resonator, is that right ?
If so the setfreq should be em16, and the hsersetup should be B57600_16,0
Yep, all confirmed/changed, but no change in overall operation, still goes blank after initial 'driver' pattern is displayed.

Also to note, the internal pattern (before it goes blank) seems to be scanning so fast that it's almost solid orange, i can ONLY see the words "Thanx Buzby" if i scan my eyes quickly, but can't read the text if i simply look directly at the DMD.
I noticed this before i connected the 'source' pic, once i'd removed the pullup resistor on the 'switchpin' C.0 ....maybe there's something in the source not correctly controlling 'switchpin' ???


UPDATE:
Additionally, i noticed the symbols for driveready and switchpin in each picaxe, was using "pinC.0" instead of just "C.0" (all other symbols are simply C.1, C.2 etc).
I changed the "pinC.0" to "C.0" and now the DMD doesn't go blank, but it does blink between the internal (driver) pattern and a blank screen, hope that helps?
However, i don't see any of your 'source' patterns ever appear on the DMD.

There's also a 700mS delay for handshaking in the source pic, not sure if that's an issue with the 2 different speed pics?, and maybe missing the chance to handshake correctly????


Marty.
 
Last edited:

Buzby

Senior Member
Hi Marty,

We are really close.

I've got two 28X2's running the two codes attached.
Put these in your devices, and adjust the 'setfreq' and 'hsersetup' to suit your resonators.

The 'driver' is sending some debug information to Terminal.
It should show a list of repeating numbers : 253, 251, 247, 238.
Each number is the first byte of each of the four frames sent by 'source', and should change each time 'switchpin' changes.

I you don't see any lines appearing then you are not detecting 'SwitchPin'. Check wiring.
If you see lines, but a list of unchanging numbers, then the serial is not picking up anything. Check hsersetups, then check wiring.
If you see a list of numbers different to 253, 251, 247, 238 then the serial is set up wrong. Check hsersetups.

Note : On Terminal you will need to select the 76800 baud option, because serttxd speed is affected by setfreq.

Regarding pinC.0 and C.0, this is correct. I'll explain later, when it's all working !.

The display on the DMD should not be 'unusual' in respect to refreshing.
The serial comms does not affect the refresh, only the update of new frames.
It might be blank, or wrong data, but it should not be washed-out.
Check the DISPenables and similar in the 32 chunks of code that refresh the DMD.

Cheers,

Buzby
 

Attachments

Buzby

Senior Member
A further note.

The 700mS delay ( now 500mS ) is to slow the 'source' down so I can see what's happening.
It has no effect on baud rate.
 

Attachments

OLDmarty

Senior Member
Thanx Buzby, that's FUNNY, you must have spent some time in DMDcreator hehehehe (Yes, it works!!!).

Oddly enough, the terminal only locked at 19200, and i do see "253, 251, 247, 238" repeating, but the animating pattern kinda proves that anyway ;-)
- Source is set to em16.
- Driver is set to em64.

Here's 2 videos....

This one shows what happens from powerup, "Waiting for comms"
(before i programmed the source pic, i did also see your revised "Comms Fail" screen, flashing (inverting) until i finally programmed the source pic, then the animation took over...
[video=youtube_share;xNjFjfpGZ8c]http://youtu.be/xNjFjfpGZ8c[/video]



So far, so good.....


Regards,
Marty.
 

OLDmarty

Senior Member
This one simply shows the animated patern a little longer....
[video=youtube_share;nOE-oPYmyqE]http://youtu.be/nOE-oPYmyqE[/video]


So far, so good.....


Regards,
Marty.
 

Buzby

Senior Member
FANTASTIC !.

Now take the 500mS pause out of 'source' and it will run as fast as it can.
 

OLDmarty

Senior Member
A further note.

The 700mS delay ( now 500mS ) is to slow the 'source' down so I can see what's happening.
It has no effect on baud rate.
So if we reduce to say 100-200mS or less? (within reason) this should increase the animation speed???
I guess i'll need to try it's limits to see where the driver starts 'missing' frames, then increase the delay to a decent speed animation.

Would there be any advantage on making the source pic run on 16Mhz reso? or just leave it at 4Mhz as it's not hammering that much?

I guess the next step is to pull patterns from external storage (eeprom or SDcard etc), so i expect the source picaxe should be hammering as fast as possible to load the data, then pass it to the driver all within each frame of the animation.
 

Buzby

Senior Member
It won't miss frames !.

Take out the 500mS first, then we'll move on step-by-step with speeding it up.

External eeprom is a little way off yet, I want to get the update rock solid first.
 

OLDmarty

Senior Member
OK, removed the 500mS delay, in fact it's not too noticably different at all...

There must be a fair chunk of time taken to transfer the frame data from source to driver....i'm thinking the source will now need some oomf with a 16Mhz reso, unless there's other inherent timing/delays we can remove?
 
Top