jgrauman wrote:Any updates on this? I'm looking for usbdriver.h as well. Thanks.
first of all, note that i am a horrible programmer, and have no clue how things should be done. i play around until my stuff works. so, the following works for me, but it probably has some pretty stupid stuff in it...
usbdriver.h is in avrdude - see the links here, plus what i did to get avrdude to compile. (EDIT - this is incorrect. usbdriver.h is NOT in the avrdude package i used. see later post in this thread for more info)
if you can get avrdude to compile and run, you can then modify it to do anything you like. to send one byte to your avr, you can do this:
unsigned char outbyte;
unsigned char result;
timeout = USB_TIMEOUT + (1 * sck_period) / 1000; // i have no idea
// as to whether this is stupid. it works for me.
outbyte = 0x31; we will send this to the avr. 0x31 is a value that your
avr will get through spi. you might already know that spi responds with the value that is already in spdr. so, you need to send another byte to actually get a response to this byte. did that make sense? if not, check out the atmel docs for your avr
bytes = usb_control_msg(usb_handle,
USB_ENDPOINT_IN | USB_TYPE_VENDOR | USB_RECIP_DEVICE,
&result, 1, // the response will be in result
that is how i send one byte, but if you want to get lots of data from your avr, it is faster to use the following, which sends and receives 4 bytes with one usb transaction:
int w1,w2; // we need 16 bits. this works for me, lol.
unsigned char res;
if your avr is in a loop, and knows what it is expected to send, w1 and w2 can be 0, or anything. but, if you want them to convey information, load them like this:
w1 = something + (something_else << 8);
// this is supposed to say 'left shift by 8 bits, but i'm seeing stupid emoticons in the preview.
w2 = more_stuff + (more_stuff2 << 8);
i used the silly names because i don't know the order in which they actually are sent, since all of my routines send one command byte to my avr using my first example above, then dummy bytes to get the data back using this method.
usb_in( USBTINY_SPI,w2, w1, res, sizeof(res), timeout);
the first response byte is in res, 2nd in res, etc.
you might have noticed that some of the code controls the SS pin on the avr, which is recommended by atmel as a way to keep data synchronized. it isn't needed for programming, because the avr is reset. to control SS, you need to pick an unused pin on the 2313, then use something like this:
b0 = 0x01; // green led
b1 = 0x02; // output - i use this for SS
b2 = 0;
//b2 = 0 & 0x04; // input
b3 = 0x08; // output - hmm, this looks wrong. this pin isnt used,
so it probably should be 0, to keep it as an input. like i said, i'm a pretty
b4 = 0x10; // reset - output
b5 = 0x20; // mosi - output
b6 = 0;
//b6 = 0 & 0x40; // miso - input
b7 = 0x80; // sck - output
data_2 = b0 + b1 + b2 + b3 + b4 + b5 + b6 + b7;// 1011 1011 BB
usb_control(USBTINY_DDRWRITE, data_2, 0);
now that pin b1 is configured as an output, if it is connected to SS on your avr, pull it low to start an spi transfer, of one or more bytes:
usb_control(USBTINY_SET, 1, 0); // the '1' refers to pin 1 on port b
then raise it when you're done. on a robust system you can leave it low all the time, but if you raise and lower it periodically you ensure that the avr is re-synced.
to raise it:
i have to go to work now, so this is pretty rough.