On the week-end I managed to further optimise my Beacon Keyer's memory use. It now looks like this:
In my playing with MCUs I finally decided to order an Arduino Uno. Originally I thought of them as a simple toy that would not equate to 'real' MCU programming, however I then realised (and it was pointed out to me) how close these are to the real thing and how great they'd be to get the basics of integration of components. To that end, I snapped one up pronto!
I managed to find a bit of time today and breadboard up my little CW Beacon Keyer with my ATtiny13. The idea was to simply have the MCU drive a NPN transistor to switch a key line. So to that end, I simply wired up the circuit and then connected it to my CPO via the cable connected to my morse key. The video shows the result.
I’ve re-written (or, generated from my old ones) the character look-up tables and thereby the resulting encoding functions. Further, I then re-wrote the MCU control code to use the new encoding and wow! what a difference.
All now fits on a ATtiny13 (1K flash, 64B SRAM) as long as I keep the transmitted text to no more than 7 characters (more than enough for VK1IS) – keeping in mind the ATtiny13s only have 64bytes of SRAM (which also needs to store the lookup tables).
So here’s the stats when using the string ‘VK1IS’:
AVR Memory Usage ---------------- Device: attiny85 Program: 2000 bytes (24.4% Full) (.text + .data + .bootloader) Data: 240 bytes (46.9% Full) (.data + .bss + .noinit)
AVR Memory Usage ---------------- Device: attiny85 Program: 838 bytes (10.2% Full) (.text + .data + .bootloader) Data: 48 bytes (9.4% Full) (.data + .bss + .noinit)
As you can see, there are huge savings being made there. This is due to two key things:
- (SRAM) Encoding each character in 8 bits (where as previously letters were using some 5 or more BYTES each); and
- (Flash / Program) No longer using libc as I can encode the result in place – no need for a resulting dynamically allocated encode byte array.
This improvement also means I can now happily have an ATtiny85 send the full ‘CQ CQ CQ DE VK1IS VK1IS VK1IS K’.
There are more memory improvements that could be made to allow the ATtiny13 to support longer strings. Being coded in C, I can use the PROGMEM directive on the look-up tables so that they’re not stored in SRAM. This could result in a SRAM saving of about another 41 bytes – meaning in the above tables it would read ‘Data: 7 bytes’ (very nice). Might look into this soon.
For now though, I have a rather flexible solution for creating AVR based beacon keyers – and indeed keyers in general. I now might see if I can breadboard the basic circuit (time permitting) and hook up to my CPO. As I sit here I have a little ATtiny13 in my basic dev board flashing out VK1IS at QRSS1 speed.
Oh one thing that surprised me switching from the 85 to the 13 was the clock speed. You see both use the CKDIV8 fuse by default to divide the internal oscillator, however the 85 has an internal oscillator of 8MHz, however the 13 has an internal oscillator of 9MHz. This needs to be noted to ensure that the timings for my morse generation remain somewhat accurate.
In my previous post about completing my initial code for my MCU based beacon keyer I made mention to the use of memory. Indeed, my code was of such size I had to use the largest AVR ATtiny chip I could (well, memory wise). The ATtiny85 gave me a whopping 512 bytes of SRAM – and 512 of EEPROM and 8KB of flash. Who could ever need more than that right!
The format of each Morse character is as follows: Zero or more 0 bits, followed by a single 1 bit, followed by the Morse Code representation of the character in binary, with a 0 indicating a dit and a 1 indicating a dah.
You might be wondering why activity has been a bit minimal lately. Well, our first child was born almost one month ago now so I’ve been a tad busy. 😉 I’ve got a couple of more things coming up soon, but hopefully activity will resume in the next month or two. 🙂