MIDIFighter Source
I just wanted to say thank you for making the source code so easy to read, I have been trying to dissect everything, and the comments have been invaluable.
Im pretty new to micro-controller programming, so I do have some questions:
Where are the input/output pins specified? (Im sure its been starring me in the face this whole time)
How does the TLC5924 work?
What does the ADC file do?
Im sure Ill be adding more questions to this.
Thanks for your time,
Ben.
Thanks for the compliment. I spent a long time making the code as easy to use as possible. Most of the example code I see on the Arduino is written by non-programmers, so I thought I’d make a full sized, well documented piece of microcontroller code for a change.
Your questions:
Q: Where are the input/output pins specified? (Im sure its been starring me in the face this whole time)
A: The addresses of the IO pins are specified in the WinAVR headers, specifically the headers:
avr/include/avr/iousb162.h
avr/include/avr/iousbxx2.h
It’s useful to generate “TAGS” for a project you’re not familiar with, so for Emacs (which I use) I run something like:
find . -name "*.[c|h] -exec etags -a {} \;
find ../WinAVR -name "*.[c|h] -exec etags -a {} \;
find ../LUFA -name "*.[c|h] -exec etags -a {} \;
to let the “etags” program visit every .c and .h file in my project and libraries and build a database of where these things are first defined. Then I can do a “M-.” search for the definition of the value or function under the cursor and the editor jumps me there.
Q: How does the TLC5924 work?
A: The datasheet will tell you everything you need to know.
There’s an LED BLANK pin that can be used to turn off all LEDS at once but we never use that feature, so we set it LOW during setup and keep it there. After setup the chip works using SPI - we shift in two bytes, 16 bits, where each bit represents one of the LEDs and it turns on or off the LED assocuated with those bits. That’s pretty much it. The chip has other features for coping with different LED voltages that we never use. Check out the datasheet.
Q: What does the ADC file do?
A: It controls the ADC chip we added to the board that allows us to read the four analog inputs on the expansion bus. The chips that the Arduino uses have ADC built in, but our chip doesn’t (it has USB hardware instead). So to read analog signals we added a MCP3004 chip to the SPI bus. It’s data sheet is here:
It’s got a fairly straightforward protocol for reading an Analog channel and returning 10 bits of binary data - essentially you shift out 3 specifically formatted bytes over SPI and shifts back in three bytes, the bottom two bytes being the 10-bit ADC value. First byte sent tells it which channel to read and the unused bits in the bytes introduce exactly the right amount of delay for the read and conversion to happen. Nifty.
Awesome, thanks for helping me out, Im so far in over my head 
So Im trying to adapt the MIDIFighter code for the Teensy, so::
Include the headers for the AVR chip the Teensy uses?
(And whats that second included header “avr/include/avr/iousbxx2.h”? Is that generic?)
And I shouldnt have to worry about the ADC stuff because the Teensy already has that, right?
And what about the LED driver, is that going to be necessary with the Teensy?
And if I try to document what Im doing and turn it into a tutorial of sorts, would you check over it and make sure I dont say something stupid?
Thanks,
Ben
You’d best look at the Makefile and change the name of the platform to match the chip in the Teensyduino. The final “midifighter.hex” will be correctly compiled for your board, and the PORT numbers will be correct.
The ADC functions will need to be rewritten to read the ADC ports of your microcontroller rather than trying to communicate with an missing ADC chip. That boils down to replacing the SPI mechanism with a single PORT read.
The LED driver is a useful device to add to your design as it’s made to provide constant current to however many LEDs you use, so they don’t change brightness when you turn lots of them on or off.
Saying something stupid never stopped me! Sure, no problem.
I’ve gotten pretty far in life saying stupid things. 
Alright thanks I really do appreciate the help.
So in the makefile I need to change:
# MCU name
MCU = at90usb162
to match the processor in the Teensy? Thats it?
Thanks,
Ben
Well, that’s where you start. Change that, recompile, see what happens.
Getting it to compile is the first step to getting to be functional. Remember, the Teensy doesn’t have the latch-and-shift-in key readers, the LED controller or the ADC chip, but you should be able to enumerate connect over USB.
What do you mean enumerate connect?
Also I only need the latch-and-shift for multiplexers right? (From what Im reading it doesnt sound like it, woo Google)
Thanks,
Ben
USB devices first connect, then send a big packet of description about themselves to the Host which, if the host thinks they are worthy, they are deemed “Enumerated” and will appear in your list of active hardware.
“Connecting” is the just first part of that whole process, so I tend not to use that word.
Alright, thanks! Now I understand what you meant about getting it to enumerate. Ill probably be back with more questions Thanks for helping me out, I really appreciate it.
Thanks,
Ben
So how sad is it I cant even get the original source to compile? Haha
I followed the tutorial to the letter, I tried older versions of LUFA (The version that the makefile specifies), I reinstalled WinAvr, re-downloaded the Midifighter source, but everytime I try I get this:
-------- begin --------
avr-gcc (WinAVR 20100110) 4.3.3
Copyright (C) 2008 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
make: *** No rules to make target 'midifighter.elf', needed by 'elf'. Stop.
Any ideas?
Thanks for your time,
Ben
Hello!
I had the same problem, it seems that the makefile points and old library
[quote]
LUFA_PATH = ./LUFA091122[/quote]
i “think” because it is the first time i open a makefile hahaha
i solve the problem downloading the version 091122.
http://lufa-lib.googlecode.com/files/LUFA-091122.zip
its important to delete the space between LUFA and the data otherwise doenst work for me. I tried to modify the makefile but give me a separator error, so decide to change the library instead hahaah
Hope it works for you
I had this problem and fixed it via editing the make file, there were a number of references which needed to be changed …
Oops, that’s been there for a while. Better fix that in the Sourceforge stream.
Yes, I renamed my LUFA directory for no good reason, mainly so I could have several in the same directory as I upgraded the source from one version of LUFA to another.
Which software or IDE or whatever do you used to edit the code? notepad¿??¿!?!¿! maybe is an stupid question but i am curious…
as far as i dont have to be tight to a special IDE maybe there is a good program to use easy, to keep tracked all the files and so on…
can you recommend me one?
Thank you
I just wanted to update, I’m still working on this, but I’m taking some time to learn C, I kinda figured I need a better understanding if I really wanna pulll this off!
Well, I just got my Teensy today, and I got it to connect as a USB device, my plan is to base my code of the LUFA MIDI demo, and add on, probably referencing the Midifighter source as I go.
So I was just wondering about the function:
Endpoint_Write_Stream_LE
In your code you have it as
Endpoint_Write_Stream_LE(&midi_event, sizeof(midi_event));
but when I was writing mine, I found that the function had to have a callback. Is this just because of different versions of LUFA, or am I missing something?
(Once I added a callback, just NULL, it worked fine, I was just wondering)
Im still terribly terrible at programming, but Im getting more familiar with LUFA, and going back and forth between the demos and midifighter source has been helping a lot, thanks again for commenting it so well
Thanks,
Ben
EDIT: Callback as the last argument, so its:
Endpoint_Write_Stream_LE(Buffer, Length, Callback);
You can see the code for Endpoint_Write_Stream_LE() here in it’s strange C-friendly “templated” form (essentially define some macros and include a source file that uses them!):
The prototype declaration for Endpoint_Write_Stream_LE() should have it’s last argument have a “default value”, e.g.
void Endpoint_Write_Stream_LE(buffer, length, callback=NULL);
but this is controlled in the latest LUFA libraries by a compile-time flag called “NO_STREAM_CALLBACKS”. If this is defined anywhere in the makefile then the callbacks are not declared. The Midifighter doesn’t use the stream callbacks so feel free to add that flag to the makefile.
Another reason for me to update the source. le sigh
As I suspected! I was worried I missed something, thanks for answering! I have very rudimentary midi out working (No buttons, just a loop) that stops when it gets midi in (It has an LED programmed to blink when it does receive midi in), I still have a long ways to go, and not much time to work with school starting up 
Anyways!