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.

MCU Memory Constraints and Morse Encoding

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!

Sending just my callsign (VK1IS) worked fine with my code running on this MCU, however last night I thought I'd try the longer string of:
CQ CQ CQ DE VK1IS VK1IS VK1IS K

Could be useful for common CW comms.

Unfortunately, that resulted in the chip running out of memory when it got the third iteration of my callsign. With compile time memory usage being up at 260 bytes with this string; then the need for memory for active instructions; and then finally the dynamically allocated memory to store the encoded version of that string; there simply wasn't enough space. Indeed, with my current encoding method, to encode that string required more than 150 bytes and that was more than was available (after the 260 bytes at compile time and active instructions). (Note here, my look-up tables – by manual calculations – require 223 bytes!!)

So, it seems I should do some memory optimisations after all.

Conveniently, I received an email from Owen this morning (VK1OD) informing me that it is possible to encode all Morse characters in 8 bits. So after a bit of pondering I realised this would be possible by just using (for example) 1 for dit and 0 for dah. But seeing it's variable length what do you use for a marker for the start. In trying to figure this out, eventually I decided to be lazy and search the web. That search revealed this:

Seems all I need is to just mark the start of a sequence with a 1:

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.

That first "single 1 bit" is what then marks the start.

With this method one can definitely encode all 41 characters in the Koch set plus a good number of prosigns (AR, KN, etc.). As time permits I think I'll look at writing another cw library to implement this. Big memory will be saved – about 75% – and maybe I'll look to see if I bother with an intermediary encoding of the string or not (I have some ideas on how to deal with that to save significant memory.) Maybe it'll fit on an ATtiny13 yet (64 bytes of SRAM, 64 bytes of EEPROM and 1KB of Flash).

While looking at this I also looked at the code for the Freakin Beacon. It seems rather than a look-up table they've gone down the path of a subroutine for every character. This would save on SRAM, but then the code size would be bigger. I may also consider looking at this as another option – should be able to generate the code for this from my current CW library. 😉

CW Beacon Keyer

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

That said, in the meantime I’m reading and where possibly playing with simpler things.

For example, some months ago I decided to start looking into microcontrollers. I pondered between AVR and PIC and in the end with with AVR. So I grabbed myself an AVRISP mkII and a few ATtiny chips and built up a basic development board following instructions on I Make Projects. Within a short time I had a flashing LED but then got busy.

Anyway, I had decided a great first MCU project would be a CW Keyer (mainly for QRSS on LF, but also wherever else). These can be implemented many ways (and indeed, there’s many bits of code one could download) and many simply hardcode the sequence for the callsign. However, I wanted to learn and build from scratch – plus it was a great opportunity to do some C programming.

To that end I decided to write up a library that would provide encoding of a string into a CW element sequence. I could then enumerate over this sequence generating the matching delays for the key-ups and key-downs. Further, I did calculations based on the PARIS methodology for the element durations for various common speeds covering 5WPM to 40WPM and QRSS1 to QRSS60. I initially wrote the library and unit tests on the PC with GCC, and then when it was ready just added it into an AVR Studio 5 solution.

With such a library, the resulting MCU specific code was minimal and I have two ‘configuration’ variables – one for speed and one for the string to send.

Yesterday I got this all working and successfully tested on my dev board with an LED. Doing so I learnt several things such as _delay_ms() requires a constant parameter and more significant how to use the AVR Studio simulator – very handy tool.

Oh, I also came to better appreciate the minimal memory contraints of the ATtiny chips. In the end my program had to be run on an ATtiny85 (although it may fit on a ATtiny45), this is due to the encoding library and it’s look-up tables being on the chip. This results in AVR studio stating SRAM usage of 240 bytes (ATtiny45 has 256 and ATtiny85 has 512). Strictly speaking there is no need for the encoding library on the chip so you could go smaller – you could run it on a PC, grab the encoded array and place it on the EEPROM and have it read from there. But hey, for now this is okay me thinks.

So the video shows the result with an LED flashing out my callsign at 5WPM. From here I just need to whip together a small number of components to have a nice standalone beacon/QRSS keyer – however, not entirely sure when I’ll have the time for this. When that’s done, I’ll be sure to share all. 🙂