Arduino SuperUI interface board design alpha

The first module in my Ardmos (http://github.com/billieblaze/ardmos) will be a ui controller for both buttons / leds and my sparkfun RGB button pad.  It will use an atmega328p like the arduino uno and provide a serial interface for:
- up to 384 Mono LEDs **OR**  8x16 RGB LEDs
- 128 buttons multiplexed **OR**  8x16 button matrix
- Further expandable off-board

In a previous article, I showed how I used TLC5940 to control 16 LED's with 12bit PWM across them.   Delving deeper into the associated arduino library, I did some basic experiments with the row switching and updated my schematic accordingly.  

Rows will be scanned with a 595 Shift Register driving a TLC59213 "8-Bit Parallel In/Out Darlington Source Driver With Latch" (http://www.ti.com/product/tlc59213).  Looks simple enough, send in bits, latch, get up to 500ma out!  

I plan to use the row driver to scan the buttons as well, adding 2 x 74HC165 ties up the input side of things nicely.  

Overall, the 328p looks pretty full pin-wise but should offer plenty of power here.    Here's the initial schematic, any feedback on it is appreciated! Also, I REALLY need to learn to use the net / bus thing in eaglecad better!

Starting on some UI Bits for my Arduino project

Now that I've proof-of-concepted the Master / Slave communication between the microcontrollers, I figured I'd start in on some of the UI components.     The biggest reason I had for breaking off functionalities from the main arduino is the SparkFun RGB Button Matrix that I've been using (https://www.sparkfun.com/products/7835).    In the first iteration of my Midi Sequencer, I used this and literally a HANDFUL of shift registers to handle the RGB LED's and the button matrix.   Very tedious wiring, high parts count, lots of overhead associated with it in general.  The library I was using "ShiftMatrixPWM" is pretty damn cool, I'm not gonna lie but it ties up all sorts of other bits (timers / interrupts) and then i still had to scan the buttons.   I found that this caused instabilities in my more timing sensitive functionalities.

Initially, I was looking at the MAX7219 "Serially Interfaced, 8-Digit, LED Display Drivers" but they lacked PWM on individual LED's.  Who wants to do an RGB matrix with a limited color set?!   not me!    I kept searching and ultimately found TLC5940 "16-Channel LED Driver w/EEprom DOT Correction & Grayscale PWM Control" (http://www.ti.com/product/tlc5940).   This chip seems to do just about everything I need besides the row scanning.   It seems like I can use a few transistors to source the current required to use this chip.    I found the corresponding arduino library and some shcematics here: http://fritzing.org/projects/tlc5940-and-arduino and a few minutes later had 16 led's dancing away!

I'm planning to use an atmega328p for this particular core but might go with Attiny2313.  I don't think the ATTINY85's will have enough io to make this simple and I'd like it to be able to handle all the matrix functionality - rgb led and button matrix.    I do also like the fact that I can just scale my current setup (8x4) out to 16x4 and beyond with ease!     I'll be working on a PCB for this after I finish breadboarding the row scanning.  This guy seems to have the row scanning down, so i'll surely be referring to this alot: http://www.thebox.myzen.co.uk/Hardware/Hexome.html

I'm also starting to amass quite a bit of test sketches and conceptual code which i'll post to github soon as well!

Post by Billie 'Blaze' Berzinskas.

ATmega Master / Multiple ATtiny Slave experiments - pt 1

So, I've got this idea for a totally modular synth / controller / whatever environment.   A master ATMega runs an event driven framework and manages any time sensitive operations.   It delegates tasks to a series of "modules" much like Digitial IO, Analog IO, MIDI, Matrix LED, etc. Rather then connecting the master straight to a shift register chain, or some other peripherals,  the functionality would be controlled by the ATtiny slave.  

Why would I want to do this?  Well, I've got several musical related projects (Midi sequencer, wavetable oscillator, midi controllers) and I'd like to reign in the codebase a little.  Each project has many similarities that could easily be abstracted.  I feel the advantages are huge for a few reasons:  

1) UI and other long running tasks don't tie up the more crucial time sensitive bits
2) Modules could become their own standalone gizmos
3) Modules could be interconnected in almost limitless ways

Proposed Core functionality:

• Event Driven framework or RTOS
• MIDI IO with thru / clock sync / clock gen
• Bootload slaves via I2c
• Allow configuration of slave address / role 

Modules will have an address and a corresponding role.   A simple messaging setup should allow a few bits
to delegate any task and value from the core to the slave.  

Proposed modules for V1:

• Analog In  (rotary pots, audio, cv, etc) 
• Analog Out  (i2c dac, audio / cv) 
• Digital In (button / encoders)
• Digital out (led, trigger, etc)
• RGB LED Matrix 
• I2c text and graphical lcds
• Keypad decoding

Phase 1 - Communicating amongst devices
Initially, I'd planned to use a straight up serial bus from master to slaves and use i2c peripherals on the slaves. I POC'd this a little and talked to some friends and it seems the consensus is to use i2c from master-> slave, then SPI or bitbang i2c out from the attiny slaves.    Seems legit..

Phase 2 - The switch from Arduino to AVR.    
All of my existing work is Arduino.   Its nice to an extent, but as i started to delve deeper, I realized I'm going to need the ability to bootload slaves from the master.  While I could recreate the wheel,  I found that Atmel application note AVR112 pretty much nails the requirement here.  A PC runs an application which executes the update from a host microcontroller to a target over "TWI" (atmels name for i2c) or USI.  

I installed Atmel Studio and was able to send a blink program to my attiny by leveraging the arduinoAsISP application I already had loaded on my Arduino Uno.   I setup an "external tool" in Atmel Studio which would execute:

Command: C:\Program Files (x86)\Arduino\hardware\tools\avr\bin\avrdude.exe
Parameters: -b19200  -C"C:\Program Files (x86)\Arduino\hardware/tools/avr/etc/avrdude.conf" -v -v -v -v -pattiny85 -cstk500v1 -P\\.\COM6  -Uflash:w:"$(TargetDir)$(TargetName).hex":i

Now I can simply F7 to build a debug version of my program, and then run the external tool to send it to the AVR..  COOL..  

Well, cool until I got back to the bootloader end of things.    Having a bootloader in this environment seems like a no-brainer! Shuffling ISP wires, or moving chips back and forth to programming devices doesn't sound very fun!   I WANT CODE!  I managed to get the bootloader slave code into atmel studio from the provided .zip from atmel.  I tried to compile it - ERROR!   Apparently, Atmel doesn't use AVR-GCC as a compiler for their example code because its not really a "commercially viable" compiler or something..    I had to download / install the IAR Embedded Workbench to compile them to .hex, which i will then in turn use AVRDude to upload to my target device.  

Hopefully, I'll at least get the bootloader up and functional tonight and my next post, I'll look at getting the master to progam the slave and load another program (blink and led , followed by some introductory communication)






references:

 midibox (http://www.ucapps.de)