The scrollys a foot....

After putting the display on a timer interrupt as well, I've managed ti get the whole thing going. So now the whole thing is interrupt driven. I optimised the IRQ routine so that the delay between each packet has been reduced and the overall update increased to around 20ms (rather than 100). So I've now started to wire up the prototype I started a while back but it'll take a while.

I put a new nib on my soldering Iron, but its already starting to lose its heat conductivity. Im not sure why but I think I may have it too hot and its losing its "tip", but I dont really know - this is the 1st time I've used an iron this long!

Alas poor scrolly, I knew him well..

I can't beleive how stupid I was last night. Banging my head off the wall trying to debug by just reading the source over and over without any feedback at all when suddenly today, I got one of those DOH! moments. I realised that I already HAVE a simple way of debugging (well...simpler). I can display an 8x5 pixel graphic! Or numbers and letters! What an idiot. So, I built the numbers 0 to 9 and then was able to find out the flow the program was taking (much like you'd do with PRINT's in your code). So, after an hour or so I've finally got it to run - more or less. It does work, but at the same time it doesn't. Theres still something wrong with the interrupts as if I get 2 packets very quickly, then the whole thing locks up. But if I delay 1ms between each packet, then all is well. This sounds like its getting a buffer overrun error (or I cant read it quick enough error). However, for testing, a 1ms delay is fine, particually as I have 100ms between displays to waste. This gives 64ms to send the whole row of pixels - fine.

But alas no.... Because of the system Im using I can actually test what it would be like to send 64 packets, and the load on the first units is far too heavy. It spends soo much time doing comm's, it has zero time left for anything else - like displaying the image. It flickers like mad! This isn't good. It simply can't handle passing on that many packets in an interrupt.

So, it looks like I'll have to try and reverse things. I'll put the comm's in the main loop, and the display in the interrupt. The display is VERY VERY simple, and will consist of a timer IRQ where by it sets 2 port variables - and thats it. This means when it does interrupt the comms, (which only happens every 3ms) it won't be in there for long.

*sigh*....its never easy.

EDIT: actually... it might not be all that bad.... The reason for the flicker could be that the delay in the main loop is being extended hugely due to the comms taking up more time. (the delay is a simple CPU loop). So before changing everything, I'll try using a timer for the counter instead which will of course be independent of CPU delays....

Almost there....

I've spent a frustrating couple of nights trying to get my units forwarding the packets, but I've almost got it. Theres hardly any documents or pages about doing interrupt driven coms with pick so it's taken a lot longer than I'd hoped. I'm also sure that theres a compiler bug as some of the code I was trying didn't work when it should have.

However once I got that going, I was able to forward the current packet to the next unit and display it there. But when I tried to address both at once, it just didn't work. I can address the 1st one (where by it doesn't forward anything), or the second, where the data is sent via the 1st but not displayed on the 1st; however I can't sent something to the the 1st and then the 2nd in turn for some reason. It gets the 1st packet and then locks up....*sigh*

PIC programming.

You know, the more I do of this, the more I think I need a proper PIC debugger. Its a pain to debug code on a PIC, especially interrupt routines. I started to write the interrupt driven transmition routine last night, but I've been struggling with even getting it to start up properly. This is mainly because I couldn't even find out where it died! After an hour or so I was eventually able to get a clue as to which part I need to debug, and was able to use the LED's on my PIC programmer to figure out how far I'd gotten, but its far from ideal!

There has to be a better way.....

Its working!!! Scrolly delight!!

Yep! At long last (although to be fair, I dont work on it ALL the time!) I've figured out what was wrong. My theory about it overheating appears to be correct since I've attached a heatsink (pinched from an old ZX Spectrum!) and its now been running for around 10 minutes without a problem. The heat sink is hot, but not too hot to touch (perhaps a new modern one will work better), and now I can finally work on the slave to slave forwarding of the message packets!

The idea behind this is that the master will send a packet with a unit number attached (say 5), and each unit it goes to will check it, and if its not 0, decrement it and send it on. This means theres no unit "allocation" or built in ID, and they are all then addressable. The only thing Im not sure about is just how fast this will be when there are 64 units all chained together... whats that going to look like? I intend on pinching a game developement trick for this and doublebuffer the display so that every unit will get its packet, and then a "flip" will be sent to them all via a single line which they are all attached to. This should solve any ripple which might occur. The other thing which may work is to send them, last unit first. Since each forwards the last packet on, it would mean they would all get the packets almost at the same time.... I'll try this before I solder a "FLIP" commandline.

Regulation.

Well, appears I was right. My 5 Volt power regulator is failing. I dont think its a dud or anything, I just think its being overloaded. I wonder if I attach a heatsink if it would last longer. I dont know if its simply getting too hot, or if theres too much current going through it. So what makes a good heatsink anyway? Getting a bigger/better power regulator might solve it for now, but I need to have a better solution at somepoint.

I did consider making a stepdown via resistors, and then feeding that into the power regulator, but I suspect the resistors will just heat up. Anyone any ideas?

HiDef heaven....

I've been looking at the HD-DVD releases and Im pretty disappointed so far. Most are just old films that have stinking quality anyway, which are pointless to take onto HD-DVD. Sure you get some parts a little crisper, but the picture is still grainy and horrible. In fact, theres only a few films you should ever buy on HD-DVD and a couple of rules that I'm following when making a purchase.

1) Film must be bright. This might seem like an odd one but its the most important. If I buy a dark film (like a space sci-fi, or horror) I never see the extra pixels/quality as its so dark, its completely lost. This goes for all films, even those shot in HIDEF. I have Serenity on DVD and HD-DVD, and the ONLY bits you notice, are the 3 or 4 sections in bright sunlight. Every other scene could be from a DVD.

2) Dont buy old films. A DVD version is cheaper, and the quality is just as good - unless your an absolute NUT for pixels, you simply won't notice! Id say any film after 2000-2002 is a good candidate. Before that....its touch and go.

3) CG cartoons are GREAT in HiDef. Films like Shrek 2, ToyStory, Cars, Finding Nemo etc. Are all amazing looking in Hi-Def.

4) and lastly, until the price drops and you simply cant get DVD's any more.... only buy new films, don't rebuy a film just because its in HIDEF unless its a real showpiece. Its simply not worth it.

And before anyone says well Im not a film buff...I love films, but after watching a new HIDEF film on my new 50" plasma then having my wife say "I didn't see any difference", I have to agree a little at least. There are some GREAT showpieces (usually the HIDEF demos), but for the most part... DVD's (especially progressive scan) are just fine.


I had a brief play last night with my scrolly message after I'd charged up my battery and its still failing. Although now I think it might be to do with the power regulator. Its getting very hot and Im wondering if perhaps its overloading and failing. This would make sense to what Im seeing, and the fact that if I leave it alone for a while it works again for a little. I'll have to try and source a regulator with a higher thresh-hold for testing that out.

A growing problem....

I've built another module so that I can work on the communications between them. The idea being that the master PIC sends a packet along the serial wire and the 1st module picks it up, decrements the PIC number and if its not 0, sends it on. This allows me to add mode modules later, and keeps the whole thing really simple.

However, Im still having issues with it freezing up. But I'm getting more convinced that its the power supply - even though I have very little evidence to support it. The battery Im using is a 12V, 1.2Ah rechargable battery, and when I switch it on, it gives a very bright image. However, after a little while the whole thing starts to go funny. The Master PIC LED is still lit, but the scrolling stutters, stalls and then freezes on the LED Matrix. However the fact its still being displayed tells me that its running okay. I put in a power on sequence so I'd know if it had reset, and its not.

Now this tells me that either the power to the master PIC isn't holding (which should affect the rest of it), or the serial comms is losing sync somehow - but I cant think of any way to test that.

On a more positive note, I did fix the ghosting! I altered the order of PORTA and PORTB being set, and that seems to have cured it. I suspect the Transistors were not slow, but too quick, and showed the slight delay the PIC has when setting the data. Theres still a slighly glow, but because of the ways its now set, theres not much to see.

Scrolly fun...

Okay, so I decided to play with PNP's, and it looks like I can use the original 74LS138 (3 to 8 decoder) but without the invertor chip IF I use PNP's. Theres not much of a price change so I could swap back and forth depending on availability. However..... Transistors appear to have a decay rate which means I get "ghosting", and in the dark, its pretty bad. They dont switch off right away, but take a little time. either that, or they switch on a little too quickly (which I think is more likely) so you get a small echo before the column actually swaps.

I'll play with the code a little as it may be just a case that I need to pause a little before swapping data channels or something.

However, that problem aside, there does appear to be either a power, or serial issue, as the display is freezing. That is, it stops scrolling. Now since it still displays a solid image, I know the PIC is still runing (or I'd only get a single verticle line), which leads me to think its going out of sync with the serial, OR getting reset or something. its very odd whatever it is.....

Scrolly Message Progress!

I have at last figured a reasonable way forward with my scrolly message do-da. I decided to try out using 5 transistors rather than the 5 pull up resistors. These are a little more expensive, but not by much, so it should work out around the same cost as before, and allows me to keep the cheaper PIC. So next....I have to produce a new schematic using just the PIC, 4028 IC and 5 transistors. Once I've done that I can start to wire up the prototype. The only thing Im worried about is when I have a large version, theres probably going to be a lot of juice feeding it, and I might need some resitors in there to limit it a little. The LED matrix happily runs on 5V, but the number of amps needed to run the whole thing is a worry.

However, I'll cross that bridge when I get to it. For now, Im almost at the point where I can wire up the prototype, and start getting inter-PIC-slave comms going.

I've used some NPN's here, but I've been trying to find out the difference between NPN's and PNP's, and have just found out (I think.) NPN's are the way I normally thing of things, output a 1, and the switch is ON. While PNP's appear to be output 0, and the switch comes on. This might mean I could use some 74LS chips instead of 4028's, but I'll need to sww whats cheaper.....again.....