After playing with my Adafruit matrix for a few hours, I began to look at the underlying libraries. There are two - RGBMatrixPanel (https://github.com/adafruit/RGB-matrix-Panel) which handles communication with the matrix and their GFX library (https://github.com/adafruit/Adafruit-GFX-Library) which handles the actual pixel data and manipulation. I looked over both and found the code well commented and pretty to the point. They also have a good article about the GFX library - http://learn.adafruit.com/adafruit-gfx-graphics-library/overview
I plan to mashup the RGBMatrixPanel library with the TLC5940 library that'll be powering my SuperUI module. I should be able to swap out the init, data transfer and interrupt routine, leaving me with a really nice API for the graphical portion of the module. I took a first pass and got it to compile, but haven't tested yet. I'll check it into github when I see twinkles from my mini matrix.
Showing posts with label arduino. Show all posts
Showing posts with label arduino. Show all posts
Friday, March 7, 2014
Wednesday, March 5, 2014
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!
- 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!
Monday, March 3, 2014
Meet Your MASTER - Arduino Uno -> Attiny85 i2c communication
Now that I can successfully program my Attiny85's w/ TinySafeBoot from the Arduino IDE, it's time to do a little coding!
I hooked up my Arduino to Attiny via I2C :
Arduino A5 -> Tiny pin5
Arduino A4 -> Tiny pin7
I installed Rambo's TinyWireS (slave) library and dropped one of the examples onto the chip. On the arduino side, I started by running the scanI2CBus sketch which showed it could find the slave on the i2c bus. I modified the slave program to blink an LED when it receives data. SUCCESS!
Now that bits are flowing, its time to start thinking about what the messaging protocol will look like. I'll have to hash out what actions will occur on each slave. I don't even know where to start at this point, LOL!
references:
http://arduino.cc/en/Tutorial/MasterWriter#.UxSFwoVafVI
http://arduino.cc/en/reference/wire#.UxSDPYVafVI
https://github.com/rambo/TinyWire
I hooked up my Arduino to Attiny via I2C :
Arduino A5 -> Tiny pin5
Arduino A4 -> Tiny pin7
I installed Rambo's TinyWireS (slave) library and dropped one of the examples onto the chip. On the arduino side, I started by running the scanI2CBus sketch which showed it could find the slave on the i2c bus. I modified the slave program to blink an LED when it receives data. SUCCESS!
Now that bits are flowing, its time to start thinking about what the messaging protocol will look like. I'll have to hash out what actions will occur on each slave. I don't even know where to start at this point, LOL!
references:
http://arduino.cc/en/Tutorial/MasterWriter#.UxSFwoVafVI
http://arduino.cc/en/reference/wire#.UxSDPYVafVI
https://github.com/rambo/TinyWire
Saturday, March 1, 2014
Programming Attiny85 from Arduino IDE
Now that I can bootload code onto my ATTiny85's, its almost time to get down to some programming! I do want to get into AVR C **ALOT** more, but also in the interest of maybe getting some participants in the project, I've opted to stick with the Arduino IDE for now. This poses several issues, namely how to upload the sketch via the recently installed TinySafeBoot!?
I'd already modifed my attiny cores (arduino/hardware/tiny/boards.txt) to create a custom config for setting the fuses before i burned the bootloader (with atmel studio at the time). It seemed to me, that I could modify the uploader, since the Arduino enviroment doesn't have "external tools" like Atmel Studio. Unfortunately, this was not the case with Arduino 1.0.5, so I wound up updating to 1.5.6 beta. I found some information about jeeLabs doing similar stuff w/ Tiny84 (https://github.com/jscrane/attiny) which got me pretty close. I also did some heavy reading into the Arduino 1.5 platforms spec (https://code.google.com/p/arduino/wiki/Platforms1). With this, I was able to generate the following bits to allow me to upload to TinySafeBoot from the Arduino IDE:
BOARDS.TXT
PLATFORMS.TXT
I will establish a programming bus to allow me to program multiple slaves soon. I'm slightly concerned with the bootloader default ports (B0 / B1) because B0 overlaps the I2C pin that I'll be using to communicate with the master atmega328p. For now, I'm just disconnecting that one line when I need to bootload.
My friend turned me on to the Arduino MasterReader / SlaveWriter sketch (http://arduino.cc/en/Tutorial/MasterReader#.UxJqzvldU5N) which uses the wire lib across 2 atmega328p. This is a good conceptual idea of what'll be going on. Additionally, this instructable gives some good insight into i2c communication between microcontrollers (http://www.instructables.com/id/I2C_Bus_for_ATtiny_and_ATmega/)
I've got programming capabilities on both master / slave. I've confirmed connectivity. I've got the basic communication protocol hashed out in my head. All the pieces are falling into place!
In the next post, I hope to have hashed out the basic schematic and have some workable sample code across a few slaves.
I'd already modifed my attiny cores (arduino/hardware/tiny/boards.txt) to create a custom config for setting the fuses before i burned the bootloader (with atmel studio at the time). It seemed to me, that I could modify the uploader, since the Arduino enviroment doesn't have "external tools" like Atmel Studio. Unfortunately, this was not the case with Arduino 1.0.5, so I wound up updating to 1.5.6 beta. I found some information about jeeLabs doing similar stuff w/ Tiny84 (https://github.com/jscrane/attiny) which got me pretty close. I also did some heavy reading into the Arduino 1.5 platforms spec (https://code.google.com/p/arduino/wiki/Platforms1). With this, I was able to generate the following bits to allow me to upload to TinySafeBoot from the Arduino IDE:
BOARDS.TXT
attiny85at8TSB.name=ATtiny85 @ 8 MHz (internal oscillator; TSB Bootloader)
attiny85at8TSB.build.mcu=attiny85
attiny85at8TSB.build.f_cpu=8000000L
attiny85at8TSB.build.core=tiny
attiny85at8TSB.build.variant=standard
attiny85at8TSB.upload.tool=tsb
attiny85at8TSB.program.tool=avrdude
attiny85at8TSB.program.using=arduino:arduinoisp
attiny85at8TSB.program.maximum_size=8192
attiny85at8TSB.program.speed=19200
attiny85at8TSB.erase.tool=avrdude
attiny85at8TSB.erase.using=arduino:arduinoisp
attiny85at8TSB.erase.maximum_size=8192
attiny85at8TSB.erase.speed=19200
attiny85at8TSB.bootloader.tool=avrdude
attiny85at8TSB.bootloader.using=arduino:arduinoisp
attiny85at8TSB.bootloader.speed=19200
attiny85at8TSB.bootloader.low_fuses=0xC2
attiny85at8TSB.bootloader.high_fuses=0xD5
attiny85at8TSB.bootloader.extended_fuses=0xFE
attiny85at8TSB.bootloader.file=tiny85.hex
PLATFORMS.TXT
tools.tsb.cmd=tsb.exe
tools.tsb.path=c:\users\bblaze\desktop\tsb\
tools.tsb.upload.params.verbose=
tools.tsb.upload.params.quiet=
tools.tsb.upload.pattern="{path}\{cmd}" "{serial.port}" "FW" "{build.path}/{build.project_name}.hex"
My friend turned me on to the Arduino MasterReader / SlaveWriter sketch (http://arduino.cc/en/Tutorial/MasterReader#.UxJqzvldU5N) which uses the wire lib across 2 atmega328p. This is a good conceptual idea of what'll be going on. Additionally, this instructable gives some good insight into i2c communication between microcontrollers (http://www.instructables.com/id/I2C_Bus_for_ATtiny_and_ATmega/)
I've got programming capabilities on both master / slave. I've confirmed connectivity. I've got the basic communication protocol hashed out in my head. All the pieces are falling into place!
In the next post, I hope to have hashed out the basic schematic and have some workable sample code across a few slaves.
TinySafeBoot Success!
I dorked around most of last night and this morning trying to get TinySafeBoot (http://jtxp.org/tech/tinysafeboot_en.htm) working on my ATTiny's. Originally, I was trying to use the arduinoISP to load the "installer" onto the ATTiny, but that didn't seem to work.
I wound up reseting the bootloader to the attiny85 8mhz core w/ arduinoISP. I then compiled the Assembly with the installer turned off, and used an "external tool" in Atmel Studio to run AVRDude and put the bootloader onto the chip via ArduinoAsISP. I did have to set the AVR fuses, i used C2 D5 FE.
It looks like i'll be rolling with this bootloader for the time being as it will allow me to program all the attiny slaves in my project simply with my ftdi. I've got 9 tiny85's that i flashed with a blink program, ready to move on.
The next post, I'll be hooking up two tiny's to an arduino uno. Later, I'll use a bare Atmega328p or an Atmega644p that I've got kicking around, but for now, the arduino with a breadboard shield it is!
I wound up reseting the bootloader to the attiny85 8mhz core w/ arduinoISP. I then compiled the Assembly with the installer turned off, and used an "external tool" in Atmel Studio to run AVRDude and put the bootloader onto the chip via ArduinoAsISP. I did have to set the AVR fuses, i used C2 D5 FE.
It looks like i'll be rolling with this bootloader for the time being as it will allow me to program all the attiny slaves in my project simply with my ftdi. I've got 9 tiny85's that i flashed with a blink program, ready to move on.
The next post, I'll be hooking up two tiny's to an arduino uno. Later, I'll use a bare Atmega328p or an Atmega644p that I've got kicking around, but for now, the arduino with a breadboard shield it is!
Friday, February 28, 2014
ATMega / ATtiny experiments - Pt2 - Bootloaders
So, last night i was able to get the aforementioned AVR112 application note code (TWI Bootloader) loaded onto my ATTiny slave. However, for the life of me, I can't get the code onto the master (albeit a different processor then the example). I finally gave up on that after spending all night and morning on it.
After work, I started playing with a different one "TinySafeBootloader". This one seems pretty cool, it's able to reprogram itself, basically updating the bootloader itself! It can also program mulitple slaves on a single programming bus, by using different passwords for each. Again, I was able to get it going on my slave (I THINK!). This time, I compiled the assembler file for my particular target and was able to hack up my attiny arduino files to slightly modify the programming fuses and upload the bootloader. The difference b/w this one and the AVR note is this one works on any two-wire serial bus. I programmed the bootloader and attempted to send it a sample program via my FTDI breakout... Nothing.. It doesn't seem to want to connect. I changed a few things in my arduino boards file and reloaded several times, same thing.. I really like the things it offers, but I've also seen a few people say they couldn't get it to work. While the documentation is great as far as WHAT / HOW it does what it does, its certainly lacking the implementation details!
I'm going to hack on it a little bit longer and hopefully see some progress, otherwise - NEEEXXXTT! More to follow, stay tuned.
After work, I started playing with a different one "TinySafeBootloader". This one seems pretty cool, it's able to reprogram itself, basically updating the bootloader itself! It can also program mulitple slaves on a single programming bus, by using different passwords for each. Again, I was able to get it going on my slave (I THINK!). This time, I compiled the assembler file for my particular target and was able to hack up my attiny arduino files to slightly modify the programming fuses and upload the bootloader. The difference b/w this one and the AVR note is this one works on any two-wire serial bus. I programmed the bootloader and attempted to send it a sample program via my FTDI breakout... Nothing.. It doesn't seem to want to connect. I changed a few things in my arduino boards file and reloaded several times, same thing.. I really like the things it offers, but I've also seen a few people say they couldn't get it to work. While the documentation is great as far as WHAT / HOW it does what it does, its certainly lacking the implementation details!
I'm going to hack on it a little bit longer and hopefully see some progress, otherwise - NEEEXXXTT! More to follow, stay tuned.
Thursday, February 27, 2014
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:
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:
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)
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)
Subscribe to:
Posts (Atom)
