____ ____ ____ ___ ___ ___ ___ ____ _
| __ ) ___|| __ )/ _ \ / _ \ / _ \ / _ \ | _ \(_) __ _ _ __ _ _
| _ \___ \| _ \ (_) | | | | | | | | | | | | | | |/ _` | '__| | | |
| |_) |__) | |_) \__, | |_| | |_| | |_| | | |_| | | (_| | | | |_| |
|____/____/|____/ /_/ \___/ \___/ \___/ |____/|_|\__,_|_| \__, |
|___/Got AVR ATTiny13A talking to SMD5050 via WS2811 controller:
The audio playing component ( FN-M16P ) is driven by a UART RS232 serial connection. Looking at the ATTiny13A specs, it appears it doesn't have hardware UART. Maybe I'll have to go with an ESP8266 instead.
After some tests with the ESP8266 powered ESP-01, I am not sure it is the ideal solution either. It has really easy UART which is great, but the ESP-01 at least, only has 2 completely usable pins (the UART ones) or 4 if you push it with some special sauce. Also, it's got a bit of a weird requirement for deep sleep. Once placed in deep sleep, it can only be woken by a timer (provided GPIO16 is connected to RESET) or by grounding RESET.
Making the button reset when it's off, or generate a button press when it's on, is a bit of a challenge with so few pins. I tried a few discrete component solutions without success.
I also played around with having an ATTiny13A controlling the push button and resetting of the ESP8266. The ESP8266 would send a pulse to tell the ATTiny that it was going to sleep and the ATTiny would keep track of it's state, therefore knowing if it needed a kick to wake up. This sort of worked but seemed a bit clunky. Again pins were an issue here too since the ESP8266 needed a pin for button/ATTiny comms, the 2 pins for audio, and 1 for the light. 2 of these had to be GPIO0 and GPIO2 which are both used in the ESP8266 boot process to determine desired functionality.
I also have some ESP8266 chips in the ESP-07 format, which exposes many more pins (maybe 6 more) but this wouldn't solve the push button/reset issue without a seperate uP (such as the ATTiny). At this point it seemed to me that since I didn't need any of the ESP8266 wifi functionality, and was going to use a better ESP8266 anyway, I may as well use a better Atmel AVR instead and use one with UART. Perhaps one of my ATMega328P's.
Playing around with the ATTiny85's lately and successfully got it to bitbang the serial comms to the FN-M16P. Obviously I should be able to do this on the ATTiny13A too but I ran out of space just programming in some lighting effects into it so the ATTiny85 it is. Perhaps I can get away with using a Tiny after all.
Last night, I finally tried to merge my 2 pieces of code - the FN-M16P controller, and the WS2811 controller... and... I ran into an issue :P Given the low baud rate of the M16 (9600) it's easiest to run the processor at 1MHz, unfortunately this is too slow for the WS2811! OK, maybe I'll go back to my ATMega328P after all :P
I have returned back to the ATMega328P for this project. One thing I cannot easily do however, is use the UART to debug since it's being used to communicate with the FN-M16P. I have therefore obtained a TM1638 powered module driving 8 LEDs, 8 7-segment (+ period) characters and 8 buttons:
This serves as my debug tool, displaying return values, state information etc.
Already the debug display ( TM1638 ) has proved itself again. When testing the FN-M16P, a request for a "file in folder count" when the folder contains only 4 files, results in NOTHING being returned, not even an error. Having visibility to this avoided much hair pulling where I try to find what I did wrong.
Added first schematic, outlining design (v0.1).
Now that I'm starting to look at physical layout, I have moved a few pins around for ease of assembly. Schematic updated accordingly:
Also, populated the fritzing breadboard view. This SOMEWHAT matches mine although a fair bit neater as it wasn't an evolution :P
