USB

Go To Last Post
48 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Has anybody ever created a simple USB library that works. I just need a HID to send data from AVR to PC etc. The only thing i want is to
-change the vendor & device name
-sendusb(value)
-value = receiveusb()

I have looked at LUFA & its impossible, no idea where to start. V-USB is better but still im lost. I know USB is extremely complicated & i get impossibly lost in all of the .h .c files when they don't compile (anymore than one .h file deep & im screwed). I would never be smart enough to create a usb library but cant they make it simple like i have described above. Its likely its up to me to get it to that stage but i really need text & pretty pictures with the answers to get it. e.g create project, add library, configure pins & name, add send & receive.

Does anybody know of a basic library that can be easily added & is basic?

I will be able to get the PC side of things done.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What AVR model?

Quote:
I have looked at LUFA & its impossible

LUFA has several demo projects. Pick the one closest to your needs and then start asking here how to tweak it.

EDIT: And assuming you're using Atmel Studio, there is a LUFA extension that makes it easy to set up the demo projects in Studio. It comes with integrated help, hopefully giving you the "text and pretty pictures" you crave. Go into the Extension Manager in Studio, download the LUFA extension and follow the instructions for installing it and the help.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

Last Edited: Sat. May 11, 2013 - 11:45 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm astonished that you discounted LUFA. Normally it has a demo that is 95% of what you want to do. You use that as a template, fill in the other 5% and you are done.

But I'm confused: do you want to use a chip with USB hardware or a software implementation?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks

Yes im using Atmel Studio 6.1 with the LUFA integrated studio. In the past i have been using the ATmega168p & the ATmega32u4. I haven't used the USB on the 32u4 before though. I may like to use usb on both of those chips but was thinking about the 32u4 might be better as it has a dedicated USB port?

So if i start atmel studio go file > new example project > go through & choose Generic HID Device Demo(class driver) > click ok. It then creates a project using a certain AVR device.

I assume you can now change the device with atmel studio & the LUFA program will automatically change its pinouts to suit the AT32u4 device? If not where & how do you change that. Does LUFA know about the Dedicated USB PIN's on this device & how to handle them or does it just use the some pins on a port to do the job?

I see the int main() inside GenericHID.c & i guess i can add my code there etc. Im still not sure how to send or receive data & i may not want the whole LED blink thing (no idea what pins that is playing with) so its kind of a pain so sift through & find out how to get rid of it.

I usually build my own custom boards.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

its kind of a pain so sift through

THAT is (IMO) a necessary effort. There is no such thing as a free lunch. You can't get something for nothing. Etc etc..

As I said, if you pick an example project, and read through the code, I'm sure people here will be more than willing to help answer the questions that arises.

If you only want something that works, without putting in the effort yourself, then I'm sure you can ask for paid consulting help in the trading post forum...

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

I assume you can now change the device with atmel studio & the LUFA program will automatically change its pinouts to suit the AT32u4 device?

What are you basing your assumptions on? (I assume you're wrong, based on the fact that the Generic HID projects have the target AVR explicitly named in their descriptions. AT90USB1287.) It is not unlikely that the LUFA framework will adopt to the USB pins for the device if you change it in the project, but I have a hard time seeing how a projects application code would adopt to changed device (whether its about changing pins, or differently named bits in e.g. a SFR register, or...).

Face it. You must read the code and the documentation.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I would assume i was wrong too about the pin change. However i have seen library's that change pins per device.

Library's have a effect of going deep very fast & i just cant trace my way through them. The documentation (within code) gets very bewildering too. You end up wasting more time trying to find what you want or how it works than it actually helping you. e.g. I still don't know where the port pin settings are or if this library uses the hardware USB port or if it can create its own virtual one. Thats basic information & should be written somewhere in plain view to users.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

LUFA does not care what pins are being used by USB because that is all hard-wried, internally. You take what the chip is "wired" for and that is it.

Simply, LUFA has no reason to know about the USB pins, just as your code does not need to know what pins are used by SPI or TWI or USART. You hook up to the right pins for the chip and it runs. Software is ignorant of all that.

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Software is ignorant of all that.

And a lot of other things

The largest known prime number: 282589933-1

It's easy to stop breaking the 10th commandment! Break the 8th instead. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I agree that the LUFA website does not, explicitly, say that it uses the built-in USB hardware. It does, however, strongly imply it.

Quote:
[LUFA] is an open-source complete USB stack for the USB-enabled Atmel AVR8 [...]

As it uses the built-in hardware, it uses the hardware dedicated pins. No need to change configuration -- no ability to do so.

To be fair, I haven't worked with LUFA before, but having looked through the code several times, I have been pleasantly surprised by both its comprehensiveness and its clear design. A quick google showed the USB 1.1 specification at 327 pages. It doesn't even attempt to discuss different USB device classes. There are also another 50, or so, odd pages in the AtMega datasheet that cover just the USB peripheral. It's complex stuff.

I'll go out on a limb by saying that history is shown that you can't go far wrong by using LUFA on a supported processor and beginning with one of the example applications. People here are always more than happy to help with specific questions. Moreover, Dean, the author of LUFA is lurking around and is quick to answer questions or solve problems in the library itself. Were I to begin a USB project on AVR, that's the path I'd take. But there is a learning curve involved.

Martin Jay McKee

As with most things in engineering, the answer is an unabashed, "It depends."

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

With all of the above comments, it IS important to point out that if the USB pins are shared-use pins, you may have to do something like set those pins as inputs.

To determine if something like this is needed, YOU have to do some looking in the spec sheet. You will usually find hints in the first numbered section usually titled "Pin Configurations". Then, you should be able to find more information in the USB chapter. Then, YOU will need to supply the code to configure those pins,i if it is needed. I have not checked LUFA out for this, but I'd bet that it does not do it for you.

Just by looking at the pinout of the 32U4, I see that D+ and D- are on dedicated pins. So, odds are really high that you have to do nothing about the pins. Thus, other than electrical connections, you need to know nothing about where the USB is connected. And, the code does not either.

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok so LUFA only uses the AVR chips with USB hardware on them & if you change the device type in AVR studio somewhere it may reconfigure itself to work (depending if ATMEL changed say hardware buffer name, interrupt values, etc). Wouldn't be smart if they did.
Wow how hard was that! Some people may just know that info but spare a thought for the people that don't, so write it down in a feature list or something

V-USB library doesn't build, undefined references no matter how many files i include etc (i cannot go through all of the .h etc to find it or why).
LUFA doesn't seem to be basic enough. No basic info on it.

Im not sure i want to go down this track now due to its complexity & wait instead for a few years into the future when it will hopefully become easier to do so. I would like to get it going as its something which i keep thinking about from time to time & each time the same result so far.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Check out Dean's tutorials on this site about LUFA. He is the author of LUFA.

The Tutorial forum is listed at the bottom of the 8-bit section in the Forum Index.

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

As Jim says, take a gander at the tutorial. Also, read through some LUFA examples ( just the main files ) to see if you can understand what the code "should" be doing. Then, once you do, take a look a level up. Treat everything as a black box until it's general function is starting to make sense.

As for V-USB... undefined references refer to functions or data that are expected to be found that are not. That usually means a missing .c ( or .S ) file, it has nothing to do with .h files.

Perhaps LUFA and USB are too much to take on right now -- but, perhaps not. As they say, there's no time like the present. The trick is to take it slowly. And ask questions ( the more specific the better ) here. Questions that have lots of specific information ( and minimal functional... or broken,,, code examples ) get answered more quickly and easily here.

Martin Jay McKee

As with most things in engineering, the answer is an unabashed, "It depends."

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
LUFA doesn't seem to be basic enough. No basic info on it.

You keep repeating things like "too big", "no tutorial" etc.

Have you bothered to open up a well chosen project in Studio. E.g. if you look at the USB-to-Serial project, how much code (apart from the LUFA) framework is there?

It seems to me that there are four files to study primarily. Descriptors.c, Descriptors.h, UsbToSerial.c, UsbToSerial.h. And they do not look to complicated.

Yes, I know that you do not want a USB-to-Serial converter, but the USB side of such an application should be very much like what you describe as your needs. A quick cut of the Serial side things and you have a skeleton for your application.

If you decide this is too much for you then I would go for having the app doing UART I/O and then have a separate USB-to-Serial converter between the AVR and the PC. Either a chip on the PCB, or a cable dongle. E.g. FTDI makes such chip, and you should be able to find a dongle on the net for a few dollars.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

V-USB library doesn't build, undefined references no matter how many files i include etc (i cannot go through all of the .h etc to find it or why).

Undefined references are linking errors. This almost always means that one or several of the source (.c) files needed are not added to the list of files to compile. If you fix that then it is likely that all those errors go away in one go. Tell us the actual errors, and we can help you with what you need to fix in the project build setup.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Ok so LUFA only uses the AVR chips with USB hardware on them & if you change the device type in AVR studio somewhere it may reconfigure itself to work (depending if ATMEL changed say hardware buffer name, interrupt values, etc).

Yes, that is one of the main points with a framework such as LUFA. It might be that you will have to change some other define or so also to migrate to another AVR, but by-and-large one point with a framework is to abstract (minor?) differences in hardware.

The things that will not be adopted when you change device is the non-USB stuff. E.g. the USB-to-serial example project of-course manipulates USART control register bits. A change of AVR device will not fix those things. You will have to do those changes yourself.

Unless someone writes a USART framework that does to USARTs what LUFA does to USB. :wink:

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I took the main() function from the USB-to-Serial example project. I then cleaned out everything that has to do with the USART side of things, leaving essentially only a short demo of USB receive and send operations. The code below is what I ended up with.

PLEASE NOTE: I just did a raw edit in an editor. I have not compiled it. I have definitively not had a test-run of this on real hardware. I did this to show more or less what little code there is for getting basic USB comms going (all the nitty gritty is in the LUFA framework, where you need not do any changes).

int main(void)
{
	SetupHardware();
	GlobalInterruptEnable();

	for (;;)
	{
		// RECEIVE
		int16_t ReceivedByte = CDC_Device_ReceiveByte(&VirtualSerial_CDC_Interface);

		/* Read bytes from the USB OUT endpoint and do something with it */
		if (!(ReceivedByte < 0))
		  DoSomething(ReceivedByte);
		}

		// SEND
		uint8_t dataToSend[] = {1, 42, 123, 42, 132};
		uint8_t BytesToSend = 5;
		int i = 0;
		
		Endpoint_SelectEndpoint(VirtualSerial_CDC_Interface.Config.DataINEndpoint.Address);

		/* Check if a packet is already enqueued to the host - if so, we shouldn't try to send more data
		 * until it completes as there is a chance nothing is listening and a lengthy timeout could occur */
		if (Endpoint_IsINReady())
		{
			/* Never send more than one bank size less one byte to the host at a time, so that we don't block
			 * while a Zero Length Packet (ZLP) to terminate the transfer is sent if the host isn't listening */
			uint8_t BytesToSend = MIN(BytesToSend, (CDC_TXRX_EPSIZE - 1));

			/* Take bytes from the dataToSend array and put into the USB IN endpoint */
			while (BytesToSend)
			{
				/* Try to send the next byte of data to the host, abort if there is an error without dequeuing */
				if (CDC_Device_SendByte(&VirtualSerial_CDC_Interface, dataToSend[i]) != ENDPOINT_READYWAIT_NoError)
				{
					break;
				}

				/* Dequeue the already sent byte from the buffer now we have confirmed that no transmission error occurred */
				i++;
				BytesToSend--;
			}
		}

		// RUN THE USB TASKS
		CDC_Device_USBTask(&VirtualSerial_CDC_Interface);
		USB_USBTask();
	}
}

That's not much code. In fact, if I count correctly (removing comments and blank lines), it's 31 lines of code.

If I find the time and my USBkey I might test-run this tonight. (There will of-course be a few more lines then, since I need at least to blink a led to see that it is working :wink:)

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for the support guys. Im repeating previous attempts through code & am getting a breakout PCB with a ATmega32u4 on it (Arduino Leonardo). Normally i would make my own PCB but this one looks ok & i need to spend time on the code not the board at the moment.

I agree Martin the difference between English text & and C code to describe your problem is like pictures vs words. Funny that.

JohanEkdahl I have been down the serial to USB converter & it works fine but i have been off & on with the USB idea for a while. One of my projects logged a lot of data & a faster download would be cool but i can wait a 2 + minutes to get the data haha. Its a interest thing that i keep coming back to.

V-USB was a strange one as i included more files which got rid of the problems i had but only to create a bigger list of issues lol. I dont think im going to worry about V-USB at the moment & stick with learning LUFA for now.

Ill go over the code given & when i get the PCB tomorrow ill try it.
With the factory bootloader would it be best to erase that so that it doesn't interfere with LFUA?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There's no reason a factory bootloader and LUFA shouldn't get on together as the bootloader is only triggered by HWB. Obviously if you use ISP or JTAG the DFU is going to go anyway.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Cool thanks for confirming that clawson.

Intresting CDC_Device_SendByte() was found by JohanEkdahl. I don't think i ever would have found something like that 7 folders deep stored in CDCClassDevice.c maybe you found this a quick way somehow?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

But he didn't find it, exactly. He opened up the USART to CDC example and it was right there. That's the beauty of the examples. They won't show you everything that you could possibly use, but they will demonstrate the minimum to get things working.

Martin Jay McKee

As with most things in engineering, the answer is an unabashed, "It depends."

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ah yes he was using a different project. I think what this project is trying to do is program a stand alone chip as an interpreter between USB & another micro. Ill have another look & see if that sort of Send/Receive exists in other projects but i haven't seen it in the past. I maybe able to use those two methods in a stand alone chip.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok i found this in the HID Device Class. This looks like the send & receive data point mixed in with other information.

CALLBACK_HID_Device_CreateHIDReport(). To send
CALLBACK_HID_Device_ProcessHIDReport(). To receive

With ReportData being your data for send & receive?

The send part gets activated in a main() for loop which has this in it. HID_Device_USBTask(&Generic_HID_Interface);
Is that right or do i need not go that far & just concentrate on the code below?

/** HID class driver callback function for the creation of HID reports to the host.
 *
 *  \param[in]     HIDInterfaceInfo  Pointer to the HID class interface configuration structure being referenced
 *  \param[in,out] ReportID    Report ID requested by the host if non-zero, otherwise callback should set to the generated report ID
 *  \param[in]     ReportType  Type of the report to create, either HID_REPORT_ITEM_In or HID_REPORT_ITEM_Feature
 *  \param[out]    ReportData  Pointer to a buffer where the created report should be stored
 *  \param[out]    ReportSize  Number of bytes written in the report (or zero if no report is to be sent)
 *
 *  \return Boolean \c true to force the sending of the report, \c false to let the library determine if it needs to be sent
 */
bool CALLBACK_HID_Device_CreateHIDReport(USB_ClassInfo_HID_Device_t* const HIDInterfaceInfo,
                                         uint8_t* const ReportID,
                                         const uint8_t ReportType,
                                         void* ReportData,
                                         uint16_t* const ReportSize)
{
	uint8_t* Data = (uint8_t*)ReportData;
	uint8_t  CurrLEDMask = LEDs_GetLEDs();

	Data[0] = ((CurrLEDMask & LEDS_LED1) ? 1 : 0);
	Data[1] = ((CurrLEDMask & LEDS_LED2) ? 1 : 0);
	Data[2] = ((CurrLEDMask & LEDS_LED3) ? 1 : 0);
	Data[3] = ((CurrLEDMask & LEDS_LED4) ? 1 : 0);

	*ReportSize = GENERIC_REPORT_SIZE;
	return false;
}

/** HID class driver callback function for the processing of HID reports from the host.
 *
 *  \param[in] HIDInterfaceInfo  Pointer to the HID class interface configuration structure being referenced
 *  \param[in] ReportID    Report ID of the received report from the host
 *  \param[in] ReportType  The type of report that the host has sent, either HID_REPORT_ITEM_Out or HID_REPORT_ITEM_Feature
 *  \param[in] ReportData  Pointer to a buffer where the received report has been stored
 *  \param[in] ReportSize  Size in bytes of the received HID report
 */
void CALLBACK_HID_Device_ProcessHIDReport(USB_ClassInfo_HID_Device_t* const HIDInterfaceInfo,
                                          const uint8_t ReportID,
                                          const uint8_t ReportType,
                                          const void* ReportData,
                                          const uint16_t ReportSize)
{
	uint8_t* Data = (uint8_t*)ReportData;
	uint8_t  NewLEDMask = LEDS_NO_LEDS;

	if (Data[0])
	  NewLEDMask |= LEDS_LED1;

	if (Data[1])
	  NewLEDMask |= LEDS_LED2;

	if (Data[2])
	  NewLEDMask |= LEDS_LED3;

	if (Data[3])
	  NewLEDMask |= LEDS_LED4;

	LEDs_SetAllLEDs(NewLEDMask);
}

Another thought is that how much is going to slow down other operations & is it best to but this into a bootloader instead to run & download data to pc when needed?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
I think what this project is trying to do is program a stand alone chip as an interpreter between USB & another micro.

It is a converter between USB and serial. On one end of the AVR app is the AVR USB hardware, on the other end is the AVR serial hardware (i.e. USART). I.e. it does the same thing as your USB-to-Serial dongle does.

Since such converters expose themselves as a (virtual) serial port on the PC side they are extrememly simple to handle there. (E.g. in a C program on the PC you just use the ordinary 'open' function but as the filename you specify "COMx:" and you can start writing and reading. If you're using .NET, e.g. as in C#, then you have a class SerialPort that is straight-forward to use. If you're programming in Java then things are a little worse since the support for serial ports in Java is lousy.)

Then, in the AVR application, you just get rid of the actual physical serial side, i.e. all handling of the USART, and you have a simple PC-to-AVR communications app.

Seems to me the crucial thing is how you ar egoing to handle the comunications at the PC side. As a virtual COM port? OR do you want a HID device like a kaeyboard or mosue and have some kind of driver?

Quote:
maybe you found this a quick way somehow?

Looked through the list of example projects. Found the Virtual Serial Device example, and thought it would fit my needs (based on the above).

Opened it up. Found it consists of two source files and two header files. One .c/.h set is the descriptors and stuff. Other is the complete app code.

Located the main() function, saw it was about 50 lines of code. Read it. Found calls to a few LUFA functions, among those where the more or less obvious 'send and receive' functions.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

Last Edited: Tue. May 14, 2013 - 07:26 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

I maybe able to use those two methods in a stand alone chip.

That is exactly what I sketched in my code example above. I thought it was rather self-explanatory, but I see it is not. Please tell me what you don't understand in it and I'll explain.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes that's right that method will work in any of the serial "class" device demos as the use the same CDCClassdevice.c

If i choose the HID version i don't think it will work?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
If i choose the HID version i don't think it will work?

I don't know, I've just dabbled with USB and LUFA a year or two ago. Are you in any way principally opposed to trying out Virtual Serial Device as a starting point?

If a devious mind would read your posts, they could be interpreted as that you acually want to air discomfort with the complexity of USB rather than getting something to work and use that as your first learning experience.. :evil:

The intention with my sketch above is that the LUFA framework hides most all of this complexity in source files which you will not need to alter (although reading parts of them might be a good excersize eventually). The things you need to write comes in the functions in the two source files and the two header files.

If you want to have simple "streamed" communications of text between the PC and your AVR then you should be able to open up the Virtual Serial Device demo in a few minutes. Add another half hour to a few hours and you should have something that can be run. I'd probably start with a simple echo application - anything that gets received is just sent back. Then on the PC side you can test this out with any terminal program - no need to write your own PC app yet.

Why are you rejecting this path, that likely will give you the first rewards within one evening?

And again: What type of interface on the PC side are you after? Do you want to make a HID device akin to a kayboard or a mouse (and possibly supply your own drivers)? Or do you want a simple communications channel and write your PC app to use that communications channel? If the latter, what makes you stubborny stay on to the HID class, rather than the class that is actually designed to handle "communication" (i.e. the CDC class)?

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have already transferred data between PC & Atmel device using a USB to serial converter/dongle. By creating programs on both.

Why don't i use a virtual serial example:
I don't see much advantage or why put the effort into creating a virtual serial port if i already have a USB to Serial dongle to do the job. The only thing that USB has over serial is its transmission speed in my particular case (Downloading data from atmel to PC). Having said that i am also curious to get it going as a interest.

One thing that could debunk it, is that the AVR device ability to send data in HID mode faster than a serial port connection. I would say it could.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Unless human beings become very nervous, HID is not meant for high speed, high reliability (there is an human being to manage with exceptional errors) communication. A serial port connection, through USB or direct, can be much faster and more reliable -well, if one asks a PC to record data, these data are useful- (modems were used to send strategic data, even if there was no man to cope with errors).
Having the USB chip in the same chip as the Atmel (or TI, or PIC) is very comfortable, as one gains some PCB/broad beard surface ...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

I don't see much advantage or why put the effort into creating a virtual serial port if i already have a USB to Serial dongle to do the job.

To get rid of the dongle?

To not have to supply/write drivers on the PC side?

For what you originally was asking for (getting a USB stack working on your ATmega32U4 in a simple way)?

Quote:

One thing that could debunk it, is that the AVR device ability to send data in HID mode faster than a serial port connection. I would say it could.

I would very much question that HID (intended for Huiman Interface Devices like kayboards, mice, joysticks etc) would have faster transfer rates than CDC (intended e.g. for Ethernet adaptors).

It is one thing that most serial ports have max transfer speeds a bit above 100 kbps. But remember that CDC was specified for more than just virtual serial ports. According to the Wikipedia article on USB, the CDC class is used for Ethernet adapters (and if "Ethernet" means "IEEE 802.3" then that is (nominally) at least 10 Mbps, often 100 Mbps).

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
100kbps
: a human being typing at 10 000 chars per second would be a mutant... (I tried a virtual serial port at 2*57600 and tthere were no character loss)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I took the time to do the test. Consider this a mini-proto-tutorial (mini because it is terse, proto because I just hacked the code a little and probably have not cleaned it up completely). This was done on a ATUSBKEY, i.e. using a AT90USB1287 device. (If/when I get an Arduino Leonardo, I might return here to test on that also.)

PLEASE NOTE: In the procedure below I do not rely on any bootloader in the ATUSBKEY, but rather use an ordinary programmer attached to the JTAG header. Using the procedure below you will erase the bootloader from the ATUSBKEY.

WARNING!
IF YOU DO NOT TAKE PREVENTIVE STEPS, AND IF YOU DO NOT HAVE THE PROGRAMMING HARDWARE NECESSARY, YOU WILL NOT BE ABLE TO PROGRAM THE ATUSBKEY THROUGH BOOTLOADER AFTER FOLLOWING THE PROCEDURE BELOW!
If you do not understand this warning then do not use the procedure below!

The nine easy steps to getting a trivial USB app up and running on a ATUSBKEY:

1. Open up LUFAs UsbToSerial demo project in Atmel Studio.

2. Edit the code in UsbToSerial.c so that the end result is like the file I attach below. (Or just copy my file over the one in your project.)

3. Build the project.

4. Attach the programmer to the ATUSBKEY card.

5. Attach the programmer to your PC running Studio.

6. Attach the ATUSBKEY to your PC.

7. Use your programmer to program the hex from the project into the AT90USB1287.

8. Eventually, Windows will detect a new device and ask for its driver. Use the "browse manually" method, and point it to the project directory where the file "LUFA USBtoSerial.inf" resides. The driver should install, and there should be a new COM port on your system. (Mine showed up as COM13:).

9. Open up your favourite terminal application (mine is Br@ys "Terminal, https://sites.google.com/site/te... ), select the COM port and connect. Type, and dyou should see what you typed. Your key presses have been sent to the ATUSBKEY, and returned back from there before they end up in the terminal window! (If you get two identical characters for each key you press you have your terminal program set for "local echo", getting one char from the local echo and one from the remote echo that the ATUSBKEY does.)

That's it!

Remarks/Notes: Notice that only one file actually needed to be edited. It would have been nicer if I also adjusted some other things. The USBToSerial.h file needs a cleanout, but I'll leave that to the ambitious reader.

I should have altered some names and stuff, e.g. in "LUFA USBToSerial.inf", but was too lazy.

And, of-course the files and the project should be renamed from "USBToSerial" to e.g. "UsbCdcEcho"..

Personally, I would keep some LED handling to indicate state of the app (connected etc), but in one of the first posts the OP was more or less explicit about disliking having to clean out LED stuff from the demos (so I removed those five lines or so to please him).

I would not be surprised if the whole thing runs just as nice on a ATmega32U4, just changing the selected device in the project. I will now leave you with this, warren1. HTH! I'm on to other adventures.

-----

End remark: LUFA is YAQIFDC (Yet Another Quality Item From Dean Camera). The USB stuff is nicely isolated into a framework that you do not need to tinker with. There's a lot of functionality just lying there waiting to be used. Yet, despite the remarks of the OP, it seems to me that it is very "accessible". The demos that I have looked at are nice and clean and to-the-point.

The AVR community should really appreciate what Dean has given it. Anyone using LUFA should consider a donation - just go to the LUFA site and the button is near the top right corner. He deserves it.

Attachment(s): 

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Why HID, well i saw someone using HID in a raw mode to transfer data all because they didn't have the ability or couldn't be bothered to write a driver on the PC.

For some reason i didn't bother to question the fact that why use HID & i should be using a data mode (I didn't think there would be any limitation in speed due to its ID). Looks like there is.

As a example of what im trying to do is one of my projects have a ATmega32U4 connected to a Flash IC AT25DF161 For RPM, temp, etc logging. I download the data from the AT25DF161 connected via SPI to 32u4 & send it out the serial port but the serial port transfer rate is the bottle neck.

I know getting rid of the dongle isn't a bad idea, & it might be quite nice but it doesn't worry me lol sorry. So at the end of the day its speed, what would you do to achieve a faster speed?

Man im difficult haha have been from day one.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

So at the end of the day its speed, what would you do to achieve a faster speed?

MSC device? LUFA has a mass storage demo that you should be able to dissect/adapt.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well i tried the basic virtual serial demo & a modified one. Windows has a issue & comes up with this.
"The last USB device you connected to this computer malfunctioned and Windows does not reconize it."
The driver cant be installed for it either its like there isn't any
information VID PID etc. This maybe due to me changing the device type in atmel studio & not in LUFA.

Looks like the virtual serial isnt the way to go if you want more speed then JohanEkdahl. Ill have a look at some of the other librarys but its looking like this is going to hell.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Ill have a look at some of the other librarys but its looking like this is going to hell.

Excellent attitude. If every athlete had a mantra such as yours when on the starting line there'd be nothing but losers. Combine it with the approach to not read up on e.g. different USB device classes, not reading through code for some of the projects where the actual app part is perhaps around 100 lines etc, then you are guaranteed to fail.

Sorry for the bluntness, but that is how you come through.

Quote:
Man im difficult haha have been from day one.

I can agree on most of that, but I fail to see the humor in it.

I'm out.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If the code worked for Johan in a tried and tested USBKey but it failed with "The last USB device you connected to this computer malfunctioned" when you try exactly the same thing in your chip I would highly suspect the wiring/electronics.

If you put DFU back into it does that work faultlessly?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

A slight return..

Quote:
I would highly suspect the wiring/electronics

It is supposedly a Arduino Leonardo, so the wiring should be good.

Fuses, perhaps?

Did my my step 8 above occur, and was Winows pointed to the correct INF file?

So, should I get a Leonardo just to test the stuff on that? :wink:

Out again..

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The two machines i tired it on was WindowsXP 32bit & windows8 64bit

Yep to test the hardware i tired the Atmel DFU bootloader for the device (for flip programming). The PC was able to recognize it & install the drivers for it (Windows8 64bit).
Im sure its ok but the flip program doesn't work on my win8 so i cant download a hex file to it. I would say the flip program would run on xp. I pointed to the inf file & to the directory type way & using other lufa examples, none of them worked. In some cases a USB a device wasn't even seen.
Before that i even tired a LED flasher & it worked too.

Here are the fuses in the device
BODLEVEL = 2V6
HWBE = [X]
OCDEN = [ ]
JTAGEN = [ ]
SPIEN = [X]
WDTON = [ ]
EESAVE = [ ]
BOOTSZ = 2048W_3800
BOOTRST = [X]
CKDIV8 = [ ]
CKOUT = [ ]
SUT_CKSEL = EXTXOSC_8MHZ_XX_16KCK_65MS

EXTENDED = 0xF3 (valid)
HIGH = 0xD8 (valid)
LOW = 0xFF (valid)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Huh i have a 16MHZ crystal on my board & it was like that from factory. I dont like how atmel studio have changed the fuse wording & its kind of hard to see (more bold please). Is that fuse external crystal 8MHZ to maximum??

Well i changed it & now im locked out of ISP mode. Damn! Going to have to find a way around that now. Ive done it before so ill see how i go. I have also noticed that this board ties the HWB pin to ground. Bugger that could have been causing issues to?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Bugger that could have been causing issues to?

Depends if there was a bootloader there or not. If there wasn't then execution may have started at the bootloader section but as it was full of 0xFFFF which kind of execute as NOP then control would eventually run to the end of flash then wrap to the beginning and execute your app code at 0x0000. But if there was a bootloader it could have "caught" the execution. Or I guess there's also a vague possibility that with a very large app that spills into the bootloader section control actually enters it part way through.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I got the IC working again took a whole day.
I selected the .4 to .9MHZ external crystal & didnt have one to suit. I programmed another chip to feed a .3MHZ square wave into the pin & that got it going to change the fuse. I also had to lower the target frequency.

Is LUFA dependent on frequency? such as programming it or its operation frequency? i cant see any operation frequency in code. My crystal is 16MHZ.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Is LUFA dependent on frequency? such as programming it or its operation frequency? i cant see any operation frequency in code. My crystal is 16MHZ.

The USB AVR8 devices *must* have either a 8MHz or 16MHz crystal, which you indicate to LUFA via the F_USB compile token.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Do i add #define F_CPU 16000000 in the .c file with main() in it?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Dean said "F_USB", not "F_CPU".

Both are defined in the project settings. (Project menu, project Properties. Then the Toolchain tab, and in the tree control AVR/GNU C Compiler, and sub-item Symbols.)

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Dean said "F_USB", not "F_CPU".

Bugger i missed the above.

I haven't seen that before in avr studio6.1. I know there was something like that in 4 but it may of only been for the simulator? Ill try the changes & see how it goes. Thanks.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Bingo That changed its life, it now sees it as a device. Ill have to try test it out further now.