Okay! I'm back, I'm alive and kicking!
I worked on two main things: the case, and the software
Casing
Solidworks was used for the entire process.
I first modeled the actual board, before designing the case around it. The D-Pad rests against the 5 buttons. I still have to figure something out for the central button, as it's not "pressable" yet.
The whole thing was 3D-printed using a Fabrikator Mini (cheap 150€ printer from HobbyKing).
The board fits snugly inside the case; the screen is lined up with the opening, and the D-Pad is a perfect fit: not too loose, not too tight.
Software
Last time, I managed to get "bits" flying between two devices. That meant having one specific RX unit, and another TX unit. This time, I can send strings either way, spit them through the serial interface and display it on the LCD!
All right, this is not real proof. I could've written a simple sketch that displays this at startup, without any radio interface. You'll have to trust me on this one. (Promised, I'll make a video showing the thing in action!... Sometime soon).
As for the user interface, I may run into some problems.
The OLED displays everything smoothly, no worries. But I will probably run out of memory before being able to implement the whole interface! I'm using the Arduino environment, with the Adadruit library. The OLED eats 1KB of RAM (the framebuffer is the most resource-hungry)! I only have one KB left to handle the CC1101 comms, serial handling, buttons scanning, battery management, ... I'm already having crashes from time to time.
So what are the solutions?
- Optimize the code the best I can: that's a good idea, as most of my code is badly written. Global variables, strings that are used as variables while they can be defined at compile-time, ... However, no matter how much I optimize the code, I feel like I'll always run into those issues when I'll start to add additional features.
- Change the microcontroller for a "better" one: by better I mean more RAM, more flash. The ATMega328 is (AFAIK) the AVR 8-bit controller with the most RAM available. I'll have to switch to another family completely. I can continue with Atmel's SAMD 32-bit series. However they look a bit pricey, I'd like this thing to be as affordable as possible. STM32 microcontrollers look promising: you can get a STM32F103 for about $1,60, with 20kB of SRAM and 64kB of flash! That's twice as much flash, 10 times as much RAM! That'll give me some headroom! The only downside is the lack of EEPROM. I can live with that. Or with an external ROM.
One of those cheapo STM32F103C8 dev boards is on its way, I'll make some tests and see how it goes! I still don't know if I'll stay with the Arduino ecosystem or if I'll go with something a bit more low-level.
So, still lots of work to do!
Discussions
Become a Hackaday.io Member
Create an account to leave a comment. Already have an account? Log In.
Hi, about the RAM problem, if you want to stay with AVR-8bit (mostly if you are used to the hard-features and the registers) you can search via the "Microcontroller selector" form Atmel
http://www.atmel.com/selector.html#(actives:!(),data:(area:%27%27,category:%2734864%27,pm:!(),view:list),sc:1)
But to program a µC that does not have the arduino bootloader you will have to use Atmel Studio (for windows, but realy good in my opinion) and a programmer like the AVR Dragon.
About the optimisation, the purpose of the framebuffer is to get around the fact that the pixels can only be written by groups of 8. But if you only display text, or refresh the whole screen to display images, you can get rid of the framebuffer and save that 1kByte of RAM.
I hope this can help you.
Are you sure? yes | no