Well, it doesn't tell the time, and it's not likely to until I acquire a Real Time Clock chip (ordered last night, along with some other bits) but it seems to work :)
Peter Solarz

No title available

oozey mess
Game of Thrones Daily
todays bird
Cosimo Galluzzi
dirt enthusiast
No title available

if i look back, i am lost

No title available

blake kathryn

No title available
Claire Keane
h

JVL

Discoholic 🪩
KIROKAZE
2025 on Tumblr: Trends That Defined the Year
taylor price
$LAYYYTER

seen from Mexico
seen from Venezuela
seen from United States

seen from United States

seen from United States
seen from United States
seen from United States
seen from United States

seen from Argentina
seen from United States
seen from United States
seen from United States
seen from United States
seen from United States
seen from United States

seen from United States
seen from United States
seen from United States
seen from Azerbaijan
seen from Azerbaijan
@bcc
Well, it doesn't tell the time, and it's not likely to until I acquire a Real Time Clock chip (ordered last night, along with some other bits) but it seems to work :)
Driving 8x8 LED Displays
After playing around a bit, I moved on to connecting the 8x8 displays. I spent a bit of time thinking about how best to do it, and had come to the conclusion that using a 595 shift register to drive the anodes of each display was the way forward. I'd ordered some ULN8023A darlington transistor arrays which can sink up to 500ma of current. This is less than I was planning to draw through the 24 LEDs that make up a row, so the plan was to connect the cathodes of all the LED matrices to this chip. Again, a 595 shift register controls the 8023, so it means I can directly address each row and column in the same way.
Once I'd got one 8x8 display working, it seemed like checking it all worked properly was a plan.
It did, so I moved the current limiting resistors over to the 'y-axis' board, and started building the other 2 display boards.
Each board joins directly onto the next, so the wiring isn't ridiculous on any of them, but there's still an awful lot of extremely fiddly connections to make, and it's used pretty much all of my 150 bits of wire up. I wouldn't plan on doing this again in a hurry...
Once I'd connected the other 2 displays, I changed the display code to push out 2 additional sets of bytes on the X-axis with some slightly different display patterns and we were in business:
Here you can see (from the top) one of the 595 shift registers, the 8023 darlington array and 8 current limiting resistors. These collectively make up the Y-axis board, which controls the cathodes of all the displays. Each of these is operated in turn very quickly, lighting up an entire row. These are scanned quickly enough that the image on the display seems to be complete, thanks to the persistence-of-vision effect.
I had considered driving this 595 off separate pins, but decided not to. This is the first one that is connected, so it keeps the last byte of 4 that is sent out. This has the advantage that the latch of all 4 shift registers is operated at the same time, ensuring there's no lag between changing the column and row data. This would probably not be noticeable, but it would annoy me knowing there was a slight lag :)
Putting all this work together, I still had to make the software driving the display useful, rather than just pushing out hard-coded bitmaps.
I wrote some code to turn a 2d boolean array into a series of bytes for direct output. There's an intermediate stage which updates the cached bytes from the boolean array for performance, so the continuous display scanning/multiplexing isn't slowed down by excessive data shuffling. A quick demo later, and we have something that actually shows off the displays as one single screen:
Finally, I need to run some of the LCDs at a different brightness level. I modified my code to maintain 2 arrays and 2 byte caches. One contains the 'bright' LEDs, and one the 'dim', and these are lit alternatively for different periods to create this effect. Again, the refresh rate needs to be fast enough that it's not obvious to the human eye, and that's where I started to run into problems. Switching between the 2 display layers for the 24x8 display, multiplexing the rows, and varying the duty cycle of different LEDs seemed to be getting too much. I couldn't do all that fast enough to keep the refresh rate sufficiently high - the dim LEDs were showing horrible signs of flickering.
I turns out the shiftOut and digitalWrite functions provided by the Arduino software are pretty slow, and this becomes a problem when you're pushing a lot of data. My clever byte caching wasn't actually making a difference since it seems the shiftOut function turns that back into individual bits for output, which I could have done myself without the intermediate layer.
Fortunately it seems I'm not the only person who's had this problem, and thanks to the extremely clever MartinFick on this forum post, I replaced the shiftOut and digitalWrite calls with shiftRaw and fastWrite. The difference in performance is staggering - I have much more control over the duty cycle again, and there's no sign of flicker.
I think it's fair to say this has been a successful weekend. I've got a reasonably sane bit of code for driving the display with both dim and bright LEDs 'simultaneously', and it's run off a data structure that should be dead easy to implement the game of life on top of. All I'm missing now is an RTC to keep time, and actually porting the code over...
More Simple Arduino Goodness
After a little more fiddling on Friday night, I had a bunch of LEDs connected to one of the 595 shift registers following one of the Oomlout example circuits.
I added a second shift register chained off the second to run another 8 LEDs, again following an example circuit, but this time from the Earthshine Arduino Guide.
This naturally meant cool lighting effects.
Then I had a go at driving the LEDs at different duty cycles to vary their brightness. This is something I'll need to do with the 8x8 displays, so it seemed like a sensible plan to have a go with a simple circuit. It turns out it's not that hard to do:
Arduino goodness
So, my plans to build the Game of Life Clock took a step closer to reality today with the arrival of my order of stuff from Oomlout following the recommendation of a couple of people. Everything turned up within 24 hours of placing the order. Very impressed.
In addition to the 8x8 LED matrices I needed, I bought a new Arduino Duemilanove, since my old NG only has an ATMega8, with 8k of ram. This has been fine for tinkering, but was looking a bit tight for running the game, RTC and matrix driver chips. The Duemilanove has 32k of ram, which is tonnes more than I need.
It also gave me a chance to order the ARDX starter kit, which in addition to the Duemilanove has a bunch of extra stuff to play with. Given the Arduino-heavy nature of some of the dev8D workshops this year, it seemed like it'd be worth having some extra bits to play with.
I've not really done much this evening other than have a play with the first starter kit circuit, and get the latest arduino software up and running. It is worth noting that the 10mm LED that ships as part of the starter kit is a bit "argh, my eyes".
One thing that did come as a bit of a surprise was not having to hit the reset button to upload a new sketch. That'll take some getting used to.
Next up is driving an 8x8 LED matrix off a pair of 595 shift registers. I'm still torn between using shift registers or the much more sophisticated MAX7219 LED driver. Both have their advantages and disadvantages, so I think the best bet is to have a play and see...
'Highlights' of the BBC's Have Your Say.
Chip pan fire in progress...
I phoned Camelot and they fobbed me off with some story that -6 is higher - not lower - than -8 but I'm not having it. I think Camelot are giving people the wrong impression - the card doesn't say to look for a colder or warmer temperature, it says to look for a higher or lower number. Six is a lower number than 8. Imagine how many people have been misled.
Manchester Evening News
A stunningly simple way of encouraging web authors to stop using deprecated elements.
A pot of burning chilli sparked fears of a biological terror attack in central London.
BBC News
Apache 2.2
Stung by this lovely little gotcha with Apache (httpd) 2.2 default log file format today:
In httpd 2.0, unlike 1.3, the %b and %B format strings do not represent the number of bytes sent to the client, but simply the size in bytes of the HTTP response (which will differ, for instance, if the connection is aborted, or if SSL is used). The %O format provided by mod_logio will log the actual number of bytes sent over the network.
This becomes hugely apparent when you get one user making a broken request for a large file; in my case, one person making one hundred and twenty two thousand requests for the same 1.6 MiB file. As it happens they've not actually downloaded 195GiB of data but that's what apache 2 is claiming - a significant change from the sensible default in httpd 1.3.