Noob with LUFA Which example to use?

266 views
Skip to first unread message

dumdum4413

unread,
Oct 7, 2014, 9:36:18 PM10/7/14
to lufa-s...@googlegroups.com
I am looking to use the USB port on the Mega32u as a COM port to the PC.  In the AVR I want to take the characters from the PC and load a buffer while looking for the /r to indicate end-of-input.
The AVR then processes the input and sends back to the PC the result.

I am guessing that the Virtual Serial project would fit the task, but I am a little confused on how to eliminate, or disable the joystick, LEDs and the like as this is a custom board.

CAn anyone live an old Noob some pointers here?

Alan Burlison

unread,
Oct 8, 2014, 5:04:07 AM10/8/14
to lufa-s...@googlegroups.com, dumdum4413
On 08/10/2014 02:36, dumdum4413 wrote:

> CAn anyone live an old Noob some pointers here?

Here's how I did it:

http://sourceforge.net/p/abavr/lib/ci/default/tree/USBSerial/

--
Alan Burlison
--

dumdum4413

unread,
Oct 8, 2014, 8:40:52 PM10/8/14
to lufa-s...@googlegroups.com, jgmde...@optonline.net
So your implementation does what I was asking about?  Going to have to dissect this and get a better understanding.

Thanks
JIm

dumdum4413

unread,
Oct 9, 2014, 2:08:13 PM10/9/14
to lufa-s...@googlegroups.com, jgmde...@optonline.net
I am still confused about a few things
1: I am assuming the interrupt is enabled so the AVR can do other things where there is no data going back and forth on the USB.
2: What do I have to do to eliminate the joystick, and the LED's as they are not used in this application?
3: Where exactly is the point of handoff between the USB and the main part of my program? Meaning, where do I put data to be sent out the USB, and vice versa?

Jim

Alan Burlison

unread,
Oct 9, 2014, 4:55:35 PM10/9/14
to lufa-s...@googlegroups.com
> So your implementation does what I was asking about? Going to have to
> dissect this and get a better understanding.

Yes, it's CDC serial only, no joystick etc

--
Alan Burlison
--

Alan Burlison

unread,
Oct 9, 2014, 5:16:03 PM10/9/14
to lufa-s...@googlegroups.com, jgmde...@optonline.net
On 09/10/14 19:08, dumdum4413 wrote:

> I am still confused about a few things
> 1: I am assuming the interrupt is enabled so the AVR can do other things
> where there is no data going back and forth on the USB.

Yes, exactly so. It provides a driver for the AVR-libc stdio.h
implementation so you can use putc, getc, printf, scanf etc to do
buffered serial IO over USB via stdin/stdout.

> 2: What do I have to do to eliminate the joystick, and the LED's as they
> are not used in this application?

You need to remove the USB device descriptors for everything other than
the things you need, see the top of
http://sourceforge.net/p/abavr/lib/ci/default/tree/USBSerial/usb_serial.c for
example. The rest of the code in there defines the handlers and
callbacks that LUFA requires, and implements a driver that hooks it all
into the AVR-libc stdio implementation.

> 3: Where exactly is the point of handoff between the USB and the main part
> of my program? Meaning, where do I put data to be sent out the USB, and
> vice versa?

You need first to initialise the handler:

USBSerial usbSerial(USB_SERIAL_IN_RAW | USB_SERIAL_OUT_TEXT);

Then provided you call the run() method regularly to do the normal LUFA
handling tasks you'll be able to use stdio functions to do IO to the USB
device

For a working example see
http://sourceforge.net/p/abavr/apps/ci/default/tree/MinimusCDCSerialDemo/main.cpp

--
Alan Burlison
--

Peter Kwan

unread,
Oct 9, 2014, 5:27:57 PM10/9/14
to Unname
Where I always start is by running the original code. If you don't have the peripherals then declare a dummy board which LUFA can use just to make the linker happy. You can eliminate the code that you don't want later. It will compile, load and run, and Windows will install the port but it won't do much more.

Then find main() and find the for (;;) loop. You'll see how the joystick sends data and how incoming data is handled. Use that as an example of how to hook your own code in. Most of your code will be called from that loop, except for your interrupts of course.
Peter


--
Alan Burlison
--

--
You received this message because you are subscribed to the Google Groups "LUFA Library Support List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lufa-support...@googlegroups.com.
To post to this group, send email to lufa-s...@googlegroups.com.
Visit this group at http://groups.google.com/group/lufa-support.
For more options, visit https://groups.google.com/d/optout.

dumdum4413

unread,
Oct 10, 2014, 3:05:11 PM10/10/14
to lufa-s...@googlegroups.com
Thanks Alan, and Peter.  Unfortunately I am still at a loss comprehending this and it is no ones fault other than my own.  I am going to sit down this weekend(kids permitting) and try to work this out.

So much for this being easy :P

Alan Burlison

unread,
Oct 10, 2014, 7:51:16 PM10/10/14
to lufa-s...@googlegroups.com
On 10 October 2014 20:05, dumdum4413 <jgmde...@optonline.net> wrote:

> Thanks Alan, and Peter. Unfortunately I am still at a loss comprehending
> this and it is no ones fault other than my own. I am going to sit down this
> weekend(kids permitting) and try to work this out.
>
> So much for this being easy :P

Unfortunately the USB protocol itself is far from simple, and although
LUFA takes away an awful lot of the complexity for you, you still need
to understand the basics of how device descriptors work if you want to
customise them. The examples in the LUFA source archive are a really
good starting point, I'd pick the closest, simplest one to what you
want and work from there.

Also take a look at http://www.beyondlogic.org/usbnutshell, it's about
as good an introduction to USB as any,

--
Alan Burlison
--

dumdum4413

unread,
Oct 11, 2014, 9:32:05 PM10/11/14
to lufa-s...@googlegroups.com
Ok, I did some more futzing around and from a suggestion I looked at the Virtual serial CLASS_CDC1 example in Atmel Studio and this piece of kit looks promising.  I have come to a stumbling block though. 

Deans code has this in it:
"/* Create a regular character stream for the interface so that it can be used with the stdio.h functions */
    CDC_Device_CreateStream(&VirtualSerial_CDC_Interface, &USBSerialStream);"

So I added an include of <stdio.h> to the project and added two lines so I now have this:
"/* Create a regular character stream for the interface so that it can be used with the stdio.h functions */
    CDC_Device_CreateStream(&VirtualSerial_CDC_Interface, &USBSerialStream);

    stdin = &USBSerialStream;
    stdout = &USBSerialStream;"

I then put a printf in there:
"printf("Hello World!!");"

Thinking that it would send that to the USB port which I would see in my terminal window.  NOPE!  I am pretty sure I am missing something key here and I do not know what.

Alan Burlison

unread,
Oct 12, 2014, 3:52:44 PM10/12/14
to lufa-s...@googlegroups.com, dumdum4413
On 12/10/2014 02:32, dumdum4413 wrote:

> I then put a printf in there:
> "printf("Hello World!!");"
>
> Thinking that it would send that to the USB port which I would see in my
> terminal window. NOPE! I am pretty sure I am missing something key here
> and I do not know what.

Are you also calling CDC_Device_USBTask and USB_USBTask to actually
perform the IO?

--
Alan Burlison
--

dumdum4413

unread,
Oct 12, 2014, 9:52:15 PM10/12/14
to lufa-s...@googlegroups.com, jgmde...@optonline.net
No, again I am new to LUFA and looking for a "For Dummies" book on it is a lesson in futility.

Ok, so I have to call two other functions to perform the task of PrintF?  Are they the same functions to GET a character from teh USB port as it comes in?

Sorry for the questions.

Alan Burlison

unread,
Oct 13, 2014, 8:34:31 AM10/13/14
to lufa-s...@googlegroups.com
> Ok, so I have to call two other functions to perform the task of PrintF?
> Are they the same functions to GET a character from teh USB port as it comes
> in?

LUFA implements the USB stack with what is in effect a polling
mechanism. You have to make sure the appropriate functions are called
to actually do the input and output. The LUFA documentation explains
this.

http://www.fourwalledcubicle.com/files/LUFA/Doc/140928/html/group___group___u_s_b_management.html#gac4059f84a2fc0b926c31868c744f5853
http://www.fourwalledcubicle.com/files/LUFA/Doc/140928/html/group___group___u_s_b_class_c_d_c_device.html#ga7af980864ac7d1938693645580f153fc

There is no "For Dummies" book on USB, as I said already it's a
complex protocol. On top of that AVRs are low-level devices and
although LUFA does the vast majority of the heavy lifting for you it's
constrained by the physical device characteristics and the limited
space that's available on them. Personally I think what Dean has done
with LUFA is very impressive but LUFA can't work miracles. Yes, it's a
steep learning curve but I'm afraid there is simply no way around
that. If LUFA is too low level for your needs then you should probably
be using something else, e.g. a RasPi.

dumdum4413

unread,
Oct 13, 2014, 3:40:29 PM10/13/14
to lufa-s...@googlegroups.com
Thanks for the information Alan, I see now where I made some of the mistakes.

Ok, let me back up here to what I am looking to do and maybe I can get back on track.

What I want/need to do is have the AVR show up as a Com port on the PC when connected so a Terminal program can communicate to the AVR.  This is only done for configurations and the entries from the PC keyboard will be terminated with a Carriage Return.  The USB is not connected while the AVR is running the core application.

The AVR will take the entry and perform a task based on the text entered. and return the results back to the PC through the USB.

I originally thought the LUFA USB to Serial was the ticket, and I could simply steer the incoming traffic to a Buffer that will then be processed once a \r is seen.
In the same breath, the reverse to transmit to the PC.

If the USB cable is not plugged in, then the USB interface goes dormant

The USBtoSerial still seems to be the best choice, but if there is a better suggestion I am all eyes, and ears.

THanks,

Alan Burlison

unread,
Oct 16, 2014, 3:09:04 AM10/16/14
to lufa-s...@googlegroups.com, dumdum4413
On 13/10/2014 20:40, dumdum4413 wrote:

> What I want/need to do is have the AVR show up as a Com port on the PC when
> connected so a Terminal program can communicate to the AVR. This is only
> done for configurations and the entries from the PC keyboard will be
> terminated with a Carriage Return. The USB is not connected while the AVR
> is running the core application.
>
> The AVR will take the entry and perform a task based on the text entered.
> and return the results back to the PC through the USB.
>
> I originally thought the LUFA USB to Serial was the ticket, and I could
> simply steer the incoming traffic to a Buffer that will then be processed
> once a \r is seen.
> In the same breath, the reverse to transmit to the PC.
>
> If the USB cable is not plugged in, then the USB interface goes dormant
>
> The USBtoSerial still seems to be the best choice, but if there is a better
> suggestion I am all eyes, and ears.

That's exactly how it works. You can get callbacks from LUFA to detect
when the USB device is plugged/unplugged and react accordingly.

http://www.fourwalledcubicle.com/files/LUFA/Doc/140928/html/group___group___events.html

I'm sorry but you are just going to have to invest time in understanding
how USB works and reading the LUFA docs. There are no shortcuts.

--
Alan Burlison
--
Reply all
Reply to author
Forward
0 new messages