View topic - RS-232 OVER USB IN XMEGAs

Search

RS-232 OVER USB IN XMEGAs

AVR Freaks Forum Index » AVR (8-bit) Technical Forums » XMEGA forum

Author

Message

rubenpg1

Posted: Jul 31, 2012 - 01:00 PM

Joined: Dec 28, 2011
Posts: 10
Location: Madrid, Spain

Hi AVR freaks and super-freaks

Could it be possible that someone could give me a fast to-do list in order to have a simple, light and easy-to-use usart-over-usb driver?

Actually, I only need to properly configure a 19200 bps serial connection to a PC USB port monitored via hyperterminal, since I'm migrating from 128A1 to 256A3U. And of course, writing characters into the USB host. Reading is not needed at this moment.

I have thought of introducing into the USART RX management ISR a code just writing the characters into the appropiate registers of the USB device. And with a jumper between USART TX and RX pins, by writing characters into the USART they would be transferred to the USB device, and then to the host.

I have red all the app notes regarding this issue. And ASF code is so difficult to follow that I'm afraid it will take me a couple of weeks to process it, full of included libraries, buffers and calls to functions. And I need to have this working very soon.

I'm using AS5. Any help will be more than welcome!

Regards,
Ruben.

rubenpg1

Posted: Jul 31, 2012 - 03:31 PM

Joined: Dec 28, 2011
Posts: 10
Location: Madrid, Spain

Any idea out there?

It would be something like the AT90USB1287 functionality in the A1 xplained ...

Posted: Jul 31, 2012 - 11:28 PM

Joined: Mar 28, 2001
Posts: 20347
Location: Sydney, Australia (Gum trees, Koalas and Kangaroos, No Edelweiss)

I hope you realise that RS232 and USB are ELECTRICAL standards and even though I think I know waht you want to do the terminology you are using is confusing.

Want I think you may want is a CDC (?? LUFA??) type of setup but you will need to wait for some expert on this.

Also AS5 has been superseeded by AS6 and it may be best to upgrade.

_________________
John Samperi
Ampertronics Pty. Ltd.
www.ampertronics.com.au
* Electronic Design * Custom Products * Contract Assembly

rubenpg1

Posted: Aug 01, 2012 - 09:13 AM

Joined: Dec 28, 2011
Posts: 10
Location: Madrid, Spain

Yes, CDC, sorry for my confuding words ...

Well, I will be waiting for the expert ... although I have almost decided to use LUFA instead of ASF, when browsing through the LUFA libraries I think it will be easier to have a XMEGA CDC library working soon ...

Thanks anyway

mojo-chan

Posted: Aug 01, 2012 - 01:17 PM

Joined: Jan 24, 2008
Posts: 515

Avoid LUFA, all the config is via makefiles and the directory structure is horrible. I am using ASF and it works very well.

You don't need to worry about port settings, they are ignored when using USB. Baud rate etc make no difference, data is transferred as fast as the USB bus will allow.

Just start with the USART ASF example and go from there. I converted a complex project from a real USART to USB in under a day.

abcminiuser

Posted: Aug 01, 2012 - 02:42 PM

Joined: Jan 23, 2004
Posts: 9823
Location: Trondheim, Norway

Quote:

Avoid LUFA, all the config is via makefiles and the directory structure is horrible.

Could you elaborate on this please? The latest release no longer uses crazy makefiles (example: https://github.com/abcminiuser/lufa-lib ... t/makefile ), and has configuration in header files like ASF. What about the directory structure do you not like?

- Dean Twisted Evil

mojo-chan

Posted: Aug 03, 2012 - 03:05 PM

Joined: Jan 24, 2008
Posts: 515

The makefile is still a custom one, meaning you can't just use the default Atmel Studio build system with it. You include sub-makesfiles for <deity's> sake, not exactly easy to work with. Plus you still define parameters for LUFA in the makefile instead of in header files.

I can see why having a common LUFA directory seems like a good idea, but it isn't. You might want to modify it for one project, or you might not want it to update in some projects because they are stable. The way ASF does it is ideal, with everything in a neat directory under your project.

clawson

Posted: Aug 03, 2012 - 06:25 PM

Joined: Jul 18, 2005
Posts: 62257
Location: (using avr-gcc in) Finchingfield, Essex, England

Quote:

You include sub-makesfiles for <deity's> sake, not exactly easy to work with

Why? Most C programmers are able to cope with the concpet of a .c file that includes a .h that includes a .h that includes a .h to N levels deep. What's different with Makefiles then?

Personally I think LUFA is a great example of structured library code and ASF is a total abortion but this is just IMAO of course.

But then I'm used to working with the Linux kernel which has perhaps the most complex nested Makefile structure of just about any software you may encounter (but it is also very modular and the .config thing is a wonderful way of doing things - again IMAO).

_________________

Last edited by clawson on Aug 03, 2012 - 06:27 PM; edited 1 time in total

abcminiuser

Posted: Aug 03, 2012 - 06:27 PM

Joined: Jan 23, 2004
Posts: 9823
Location: Trondheim, Norway

Quote:

You're not forced to use it - you can follow the export procedure in the latest manual to add LUFA to a new AS6 project and ignore the makefiles completely. I do need to make something similar to the ASF project generator however, to export examples completely into AS6 projects.

Quote:

I can see why having a common LUFA directory seems like a good idea, but it isn't. You might want to modify it for one project, or you might not want it to update in some projects because they are stable. The way ASF does it is ideal, with everything in a neat directory under your project.

Now that's the funny thing, as ASF is exactly like LUFA (or vice-versa). What you see inside AS6 is generated on the fly by automatically recreating a copy of the used modules inside the user application -- but if you use ASF standalone, it looks very much the same. You are free to copy over LUFA to your application rather than share it if you wish.

The infrastructure to allow LUFA to do something similar to ASF (auto-copy files to the user project as needed) doesn't exist yet, but once it does I'll pilot it with LUFA.

Thanks for the feedback!
- Dean Twisted Evil

_________________
Atmel Studio 6.1 is now released, grab it here.
Report AS6/ASF bugs here.

mojo-chan

Posted: Aug 05, 2012 - 11:50 AM

Joined: Jan 24, 2008
Posts: 515

clawson wrote:

Why? Most C programmers are able to cope with the concpet of a .c file that includes a .h that includes a .h that includes a .h to N levels deep. What's different with Makefiles then?

I knew a guy who operated forklift trucks. He couldn't lift this one palette high enough so he loaded it onto one forklift, then got another forklift to lift the first one. Just because you can doesn't mean you should.

Quote:

But then I'm used to working with the Linux kernel which has perhaps the most complex nested Makefile structure of just about any software you may encounter (but it is also very modular and the .config thing is a wonderful way of doing things - again IMAO).

The Linux kernel is rather different though, not least because the end user is expected to use .config to build highly customized kernels.

mojo-chan

Posted: Aug 05, 2012 - 12:00 PM

Joined: Jan 24, 2008
Posts: 515

abcminiuser wrote:

Rather than duplicating functionality from ASF you might as well just contribute to it. But hay, it's your project.

Quote:

I think you missed my point, but yes I do like that about ASF.

abcminiuser

Posted: Aug 05, 2012 - 02:48 PM

Joined: Jan 23, 2004
Posts: 9823
Location: Trondheim, Norway

Quote:

Rather than duplicating functionality from ASF you might as well just contribute to it. But hay, it's your project.

I do. I'm paid to work on it during the day, LUFA is what work on in my free time outside of work.

Quote:

I think you missed my point, but yes I do like that about ASF.

I think you need to elaborate more then, as I'm confused. You seem to think that ASF is better than LUFA since you can make copies of the core rather than sharing it between projects, but LUFA supports that too. What am I missing?

- Dean Twisted Evil

_________________
Atmel Studio 6.1 is now released, grab it here.
Report AS6/ASF bugs here.

mojo-chan

Posted: Aug 14, 2012 - 09:37 AM

Joined: Jan 24, 2008
Posts: 515

I was talking about how LUFA is geared towards integrating the project code into the LUFA directory structure. All the examples work that way. Okay, you can hack it around to make it more like ASF, but then why not just use ASF?

I also just noticed that you have function code in your header files... If you don't know why that's bad then I can't really help you.

abcminiuser

Posted: Aug 14, 2012 - 09:47 AM

Joined: Jan 23, 2004
Posts: 9823
Location: Trondheim, Norway

Quote:

Well unless I want to release LUFA with 40+ copies of the core, I'm stuck having all the examples reference the one core folder. If you don't want that in your application, copy out the core and change the LUFA path in the makefile. Again, this is *exactly* how ASF works at the filesystem level -- AS6 is just doing the latter for you. In the future when it is possible for third party libraries to do this in AS6 I will add the same behavior for LUFA.

Quote:

I also just noticed that you have function code in your header files... If you don't know why that's bad then I can't really help you.

Please enlighten me why static inline functions that are designed to be inlined at the call site are a bad idea.

- Dean Twisted Evil

_________________
Atmel Studio 6.1 is now released, grab it here.
Report AS6/ASF bugs here.

mojo-chan

Posted: Aug 14, 2012 - 04:15 PM

Joined: Jan 24, 2008
Posts: 515

It isn't the fact that they are inline which is the problem, it is the fact that they are in a header file.

There is a lot of discussion about it on Stack Overflow, but personally my main two reasons are:

1. If you want to un-inline those functions they have to move to a different file. Some are trivial, some are not, some might get extended one day.

2. The C standard is to put all code in the .c files, with headers reserved for definitions. When other people have to work with your code this is the sort of thing that can cause issues. Admittedly they are mitigated somewhat in modern IDEs which can navigate directly from a function call to the definition, but even so...

And what happens when you want to write a function in one header which uses an inlined function from another header? Just avoid doing that?

Which brings me back to one of my original points about doing things in a non-standard way. ASF goes out of its way to avoid anything non-standard, although fails slightly by requiring a particular compiler flag for the USB stuff to work (-fdata-sections). I just prefer a framework to stick to convention and integrate with my project, rather than the other way around.

clawson

Posted: Aug 14, 2012 - 04:53 PM

Joined: Jul 18, 2005
Posts: 62257
Location: (using avr-gcc in) Finchingfield, Essex, England

Quote:

it is the fact that they are in a header file.

You miss the point. "static inline" is a special case. It does not actually generate any bytes of code from the point at which it is written. You can have:

Code:

// header.h

void static inline setB(void) {

  PORTB = 0x55;

}

Code:

//file1.c

#include "header.h"

// other code generating stuff

Code:

//file2.c

#include "header.h"

// other code generating stuff

and absolutely no code for PORTB = 0x55 will be generated anywhere. This would not be true if you removed "static inline" from the definition. That would be real bad as each of file1.o and file2.o would contain a function called setB(). As soon as you start using the functions:

Code:

//file1.c

#include "header.h"

void function1(void) {

  setB();

}

Code:

//file2.c

#include "header.h"

void function2(void) {

  setB();

}

Again there is no problem as neither of these generates a "CALL setB" and neither leads to an instance of setB() being generated separate from function1() or function2(). Instead the entire code that outputs 0x55 to PORTB is generated inline within function1() and an identical set of the same code is generated inline in function2().

So the only downside of "static inline" functions in .h is potential code bloat. If setB() is used 50 times there'll be 50 (admittedly fast!) copies of the very same code. If it had been done as:

Code:

// setB.c

void setB(void) {

  PORTB = 0x55;

}

Code:

// header.h

void setB(void);

then setB.o would contain one instantiation that they all CALL from those 50 different places.

So you are absolutely right (and I'm one of the strongest advocates of this) that no .h should ever contain anything that generates either a byte of code or a byte of data (because you get 50 copies if it is #include'd in 50 places) but "static inline" is the exception to this rule.

(actually you *can* put a variable in .h if it has no initialiser and all the #include's will share a single instance in .common but this is a GCC thing and should not be relied upon).

_________________

mojo-chan

Posted: Aug 15, 2012 - 12:06 PM

Joined: Jan 24, 2008
Posts: 515

clawson wrote:

Quote:

it is the fact that they are in a header file.

You miss the point. "static inline" is a special case. It does not actually generate any bytes of code from the point at which it is written.

I know that, but you missed the point which I have made twice already. The problem is not anything to do with the code being inlined, even if that means it does not generate anything on its own. The problem is nothing to do with how the compiler interprets the code or anything like that, it is a logical organization problem. I don't know how many other ways I can say it.

If I am writing a bootloader where space is limited I might want to get rid of some of those inlines. If I do that it will break the build because there will be multiple definitions of the function every time a .c file includes that header. So I would have to move the function out into a .c file, which in LUFA's case I would have to create because there often isn't a matching one for .c files.

It also means that if I am browsing through code to get a feel for the framework I now have to look in all the .h files for code that might be hidden there. It is much better to keep related code together, and if there are any non-inline functions they should be in the same .c file as the inline ones IMHO.

Quote:

So the only downside of "static inline" functions in .h is potential code bloat. If setB() is used 50 times there'll be 50 (admittedly fast!) copies of the very same code. If it had been done as:

Code:

// setB.c

void setB(void) {

  PORTB = 0x55;

}

Code:

// header.h

void setB(void);

then setB.o would contain one instantiation that they all CALL from those 50 different places.

Well you would hope that the compiler would inline it anyway, but if not then the inline keyword is perfectly legal in a .c file.

Quote:

So you are absolutely right (and I'm one of the strongest advocates of this) that no .h should ever contain anything that generates either a byte of code or a byte of data (because you get 50 copies if it is #include'd in 50 places) but "static inline" is the exception to this rule.

Just because you can doesn't mean you should. Consistency is important.

clawson

Posted: Aug 15, 2012 - 12:10 PM

Joined: Jul 18, 2005
Posts: 62257
Location: (using avr-gcc in) Finchingfield, Essex, England

Quote:

I now have to look in all the .h files for code that might be hidden there.

Any decent source browsing editor (and AS6 with VassistX is one such) will have no problem with "go to definition" whether it be in .c or .h.

_________________

snigelen

Posted: Aug 15, 2012 - 12:22 PM

Joined: Jan 08, 2009
Posts: 1152
Location: Lund, Sweden

Now this isn't a regular c-program, but anyway. On my computer I have in the directory /usr/src/linux-headers-2.6.32-21 and it's sub directories 7607 .h-files. The regular expression 'static.*inline' matches 14408 lines in those .h-files.

mojo-chan

Posted: Aug 15, 2012 - 01:10 PM

Joined: Jan 24, 2008
Posts: 515

clawson wrote:

Quote:

I now have to look in all the .h files for code that might be hidden there.

Any decent source browsing editor (and AS6 with VassistX is one such) will have no problem with "go to definition" whether it be in .c or .h.

Yes, and it really is an excellent IDE. Unfortunately not all IDEs are as good and sometimes I browse source with a text editor.

Look, I don't know how many times I can say this... If you don't get it by now, well, there is no hope. I'm not saying it doesn't work or is unusable, I'm saying it is not best practice or even a good idea.

Jump to:

All times are GMT + 1 Hour

AVR Freaks Forum Index » AVR (8-bit) Technical Forums » XMEGA forum

AVRFreaks.net

Search