Beacon Keyer: Further Memory Optimisation

On the week-end I managed to further optimise my Beacon Keyer's memory use. It now looks like this:

AVR Memory Usage
—————-
Device: attiny13
Program:     712 bytes (69.5% Full)
(.text + .data + .bootloader)
Data:          6 bytes (9.4% Full)
(.data + .bss + .noinit)

The big item here is that 'Data' is now down to just 6 bytes! That is, the only data being represented is the string VK1IS plus it's null terminator – and also it happens to be using 2 byte alignment. This is due to placing all the look-up tables in PROGMEM.

Doing so is meant to add a little extra code, so in theory 'Program' should've also gone up (compared to back here when it was at 838 bytes). But at the same time I also removed a function I was using to control the PORTB pins and replaced it with two simple one line macros (one for key up, and one for key down). This simple change resulted in a good reduction in program size, and was an exercise is focusing on writing the code in the context of an MCU – rather than say a monolithic system. (Oh, and also included in this was a small bit of code to add an indicator LED for when the system is transmitting.)

Now in theory I can have the full string of "CQ CQ CQ DE VK1IS VK1IS VK1IS K". However I seem to be encountering an odd problem with the null terminator disappearing once the string gets to about 25 bytes long, so I need to look into this a bit more. Debugging MCU code is proving a learning experience in itself – as in this case the emulator does not seem to be working.

Anyway, once I sort that all out then I will consider it complete. Then hopefully I can return to my plans to play with the Arduino for a bit. 😉

Oh, and helping with all this (now being rigged up on a breadboard) is the little Sparkfun AVR Programming Adapter breakout board. For under $2, this little building block is gold!!

Arduino Arrived Today

Photo

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!

Today it arrived and I couldn't wait to finally attempt my first use of an LCD – in any form. Initially my plan was to try and use my LCD with an ATtiny2313, but it seemed like a bit of a way off as I'd also need to understand how to send the necessary raw data for the HD44780 protocol for an MCU. But the Arduino library has an LCD driver built in, so all I'd have to worry about is figuring out the wiring and just writing some very simple code. In other words, just learn the basics about how to connect up/integrate an LCD into a circuit and later I can focus on writing the low level code.

I'm happy to say, in my first night with my Arduino I succeeded in displaying text on an LCD within a couple of hours – and that was indeed after still making some wiring errors (thought I could skip the contrast control). To achieve the same result with a bare bones ATtiny2313 would have required significantly more effort – and when I stuffed up the wiring I wouldn't know if the problem was my code or the wiring. 😉

So, I look forward to building up a cool little radio project I have in mind that requires an LCD display and has an Arduino at it's core. Stay tuned, and consider grabbing yourself an Arduino – they're CHEAP and FUN!

CW Beacon Keyer Breadboarded

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'm pretty tickled, as this is my first MCU project so it was great to see it achieve what the intention was. It was also good that my CPO has an audio output that I can connect to my computer. With that, I ran FLdigi and it was great to see it had no trouble decoding the morse.

In the video you may also note the little SparkFun Breadboard Power Supply Stick I'm using. This provides a nice easy switchable 5V/3.3V and at the price was more convenient than me putting together a small board with just a 5V regulator. I ordered it from ProtoGear and had it on Friday just in time for the week-end. This will be rather useful for prototyping MCU and other TTL IC circuits on the breadboard.

Next step now is to draw up the simple circuit diagram and put together the full keyer – although that will also have an ISP connector. Might be harder to find time to achieve this next step though, but hey, at least the ideas there. 😉

CW Beacon Keyer V2

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’:

The old:

AVR Memory Usage
----------------
Device: attiny85
Program:    2000 bytes (24.4% Full)
(.text + .data + .bootloader)
Data:        240 bytes (46.9% Full)
(.data + .bss + .noinit)

The new:

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:

  1. (SRAM) Encoding each character in 8 bits (where as previously letters were using some 5 or more BYTES each); and
  2. (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.