Happy New Year!!!

I've given up on trying to get each LED unit passing on the packet from the previous one if its intended for a unit further up the stream. For some reason, it just isn't working, and I really just can't put my finger on it. I could build some special hardware with mini screens or something to pin it down, but I really dont want to do that; way too much effort.

So, I've gone the lazy route and assigned each unit an ID at compile time. This means each unit will have to have its own compiled version, a pain but not un-livable with. It also makes the code much MUCH easier....

Still, since the hardware design doesn't change, if I ever figure it out, I could change it later. The Master code doesn't change either, its just how the serial line is passed on It may be I have to boost the serial signal as it'll have to go quite a ways. This would mean it has to pass through some sort of AND or OR gate just as a booster, I'll wait and see.

If anyone out there has experiance with PIC's and want to look at the unworking source, let me know..... No idea why its not working - it was pretty elegant as well....

Anyhow, I've created a 3 unit board and Im busy drilling all 261 holes! (eak!) I'm about 1/2 way through, and I'll finish it off tomorrow and then solder it all up, that part shouldn't take long, although I do have to solder 24 jumper wires along with the actual components. I think once this is working, I'll replicate the design in another package, and then see about getting some real baords made!

On a little side note....Its almost a YEAR since I started this project - looks like another one thats gonna run and run. Where HAS this year gone!!!!

Led Scrolly

I've been playing with electronics stuff again. Just before stopping for the Christmas break, Russ was moaning that I still hadn't finished my big scrolly message board, so I thought I'd have a crack at making a real life board using some some printable solder mask I got a while back. It took me a while to get things right (and I had to go and buy a cheap disposable Iron for it too), and the nerve to break out the chemical solution for the copper board, but once all that was done, I mananed to get a reasonable 1st attempt at a board.

It's taken a little bit of time to get it all working, as I'd made a right hash of some of it, so I had to cut some tracks and solder in wires to bypass mistakes. However, its working now, so in theory, I could now think about sending off to get real boards made!

I still need to work on the master PIC side, along with the PC comms. The idea is I'd use a TCP/IP or UDP interface (perhaps even wireless) and allow simple bitmaps to be sent. The mastr pic would then send this to the correct module.

I do have the basics working just not the PC comms side. The image on the right is the finished (one sided) PCB, and as you can see it still has quite a few jumpre wires. I dont want to make double sided boards at home, way too hard. If I ever get my milling machine, then I might give that a go - in fact I simply expect that to work.

Still, its nice seeing the actual PCB in all its glory, and I may end up making a board that can hold 3 modules just to see what it looks like!

One thing I would say, is that with the software Im using just now, it really doesn't route very well, and I do end up putting a lot in by hand. It could just be because this is a cheap bit of software.... I dont know.

Plodding on....

I'm still slowly progressing with wiring up the prototype, and I thought I was getting on well until I decided to finish one of them off - just to see how much more I had to do, and it turns out; LOADS! Oh well.... Onwards and upwards and all that.

I've been coding up a demo for Luca's new competition, and Im struggling a bit to fit it in. The original size was supposed to be 64 bytes(!) so I started working on that only to find out they had increased it to 128! DOH! Oh well.... Its nothing special, but I do prefer these smaller demos to the larger ones as you dont have to do very much, and it doesnt have to look too pretty.

I've also been speaking to Luca about the level2 on XeO3, so I may pick that up again soon. But once again, I've left it in a horrible state! Its got a pretty serious bug in there somewhere (probably the new sprite cache) which causes the whole thing o slowly get corrupted and crash. Bugger.

The wiring begins!

Nothing much new, except I've started the long boring process of wiring up my prototype. I've been dreading this as its going to be really dull, and take AGES! I've decided that rather than wire up one at a time, I'll do them all at once, this means I'll get the correct connection from the schematic, and then wire that wire 5 times. It should save going back and forth all the time so it'll be quicker, but even more boring! Oh well....

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.....