VirtualSerialX Demo Receive Problem atxmega128a3u
342 views
Skip to first unread message
Kolja
May 23, 2012, 12:59:32 PM5/23/12
to LUFA Library Support List
At first I would like to thank you all, especially Dean, for the nice
work and I hope that you guys can help me with my problem. I am using
a atxmega128a3u on a costum board for my actual project and I use the
virtual com port functionality of the LUFA lib. Therefore, I
downloaded the VirtualSerialX demo and the current version of the
library. So far, I got the demo running and the board is recognized by
my windows 7 os. After creating my own board files, I was able to send
data to the PC and display it in a terminal program. But the problem
now is to receive data. I tried to just echo the received bytes but it
didn´t work.
Main loop:
receivedBytes =
CDC_Device_BytesReceived(&VirtualSerial_CDC_Interface);
if (receivedBytes)
{
CDC_Device_SendByte(&VirtualSerial_CDC_Interface,
CDC_Device_ReceiveByte(&VirtualSerial_CDC_Inteface));
}
CDC_Device_USBTask(&VirtualSerial_CDC_Interface);
USB_USBTask();
The VirtualSerialX demo was used and I made only the changes above. It
seems that receivedBytes stays always 0. Hopefully you can help me.
Thanks and best regards,
Kolja.
work and I hope that you guys can help me with my problem. I am using
a atxmega128a3u on a costum board for my actual project and I use the
virtual com port functionality of the LUFA lib. Therefore, I
downloaded the VirtualSerialX demo and the current version of the
library. So far, I got the demo running and the board is recognized by
my windows 7 os. After creating my own board files, I was able to send
data to the PC and display it in a terminal program. But the problem
now is to receive data. I tried to just echo the received bytes but it
didn´t work.
Main loop:
receivedBytes =
CDC_Device_BytesReceived(&VirtualSerial_CDC_Interface);
if (receivedBytes)
{
CDC_Device_SendByte(&VirtualSerial_CDC_Interface,
CDC_Device_ReceiveByte(&VirtualSerial_CDC_Inteface));
}
CDC_Device_USBTask(&VirtualSerial_CDC_Interface);
USB_USBTask();
The VirtualSerialX demo was used and I made only the changes above. It
seems that receivedBytes stays always 0. Hopefully you can help me.
Thanks and best regards,
Kolja.
ECROS Technology
May 25, 2012, 9:03:20 AM5/25/12
to LUFA Library Support List
Kolja,
I have similar results, so it seems that the VirtualSerialX demo does
not work. This is going to be a big problem for me, as I have a
paying customer about to sign up for this and even pay the $1,500
license fee. Obviously, I was stupid not to have verified this
before. I just assumed that Dean would not put out a non-functional
demo and as sending data worked then receiving data was also going to
work. Unlike you, after three weeks struggling with LUFA, my level of
gratitude is pretty low and I'm starting to wish I'd never heard of
LUFA and had persevered with the Atmel code. Dean seems to be too
busy with other things at the moment to offer any real help.
Details: There was no AVR Studio project file in Dean's ZIP archive,
so I had to make one up based on the MassStorageX demo. In the
makefile, I changed MCU to atxmega256a3bu and BOARD to A3BU_XPLAINED.
In VirtualSerial.c, function CheckJoystickMovement(), I look at all
three buttons on the XMEGA-A3BU Xplained board and send a more
sensible message ("Button 1" instead of "Joystick Up"). This appeared
to work, but there is no actual functionality associated with received
characters and I stupidly assumed that *everything* worked.
Today, after reading your post, I made a change in the "forever" loop,
right after the comment "Must throw away unused bytes from the
host ...". I now have this:
int16_t rxChar = CDC_Device_ReceiveByte(&VirtualSerial_CDC_Interface);
if ( rxChar >= 0 )
CDC_Device_SendByte(&VirtualSerial_CDC_Interface,
(uint8_t)rxChar );
Like you, I have no echo of typed characters. A breakpoint on
CDC_Device_SendByte() never fires. It seems that
CDC_Device_ReceiveByte() never returns a non-negative result.
Graham Davies.
www.ecrostech.com
I have similar results, so it seems that the VirtualSerialX demo does
not work. This is going to be a big problem for me, as I have a
paying customer about to sign up for this and even pay the $1,500
license fee. Obviously, I was stupid not to have verified this
before. I just assumed that Dean would not put out a non-functional
demo and as sending data worked then receiving data was also going to
work. Unlike you, after three weeks struggling with LUFA, my level of
gratitude is pretty low and I'm starting to wish I'd never heard of
LUFA and had persevered with the Atmel code. Dean seems to be too
busy with other things at the moment to offer any real help.
Details: There was no AVR Studio project file in Dean's ZIP archive,
so I had to make one up based on the MassStorageX demo. In the
makefile, I changed MCU to atxmega256a3bu and BOARD to A3BU_XPLAINED.
In VirtualSerial.c, function CheckJoystickMovement(), I look at all
three buttons on the XMEGA-A3BU Xplained board and send a more
sensible message ("Button 1" instead of "Joystick Up"). This appeared
to work, but there is no actual functionality associated with received
characters and I stupidly assumed that *everything* worked.
Today, after reading your post, I made a change in the "forever" loop,
right after the comment "Must throw away unused bytes from the
host ...". I now have this:
int16_t rxChar = CDC_Device_ReceiveByte(&VirtualSerial_CDC_Interface);
if ( rxChar >= 0 )
CDC_Device_SendByte(&VirtualSerial_CDC_Interface,
(uint8_t)rxChar );
Like you, I have no echo of typed characters. A breakpoint on
CDC_Device_SendByte() never fires. It seems that
CDC_Device_ReceiveByte() never returns a non-negative result.
Graham Davies.
www.ecrostech.com
Dean Camera
May 25, 2012, 9:18:02 AM5/25/12
to lufa-s...@googlegroups.com
Graham,
I will look into this over the (long) weekend - my apologies as I have been busier than normal this week.
I do wish to re-iterate that the current release and current trunk explicitly states that all XMEGA code is "experimental" rather than "production ready" and that the demo I supplied was with the caveat that it was not guaranteed to be fully functional. I do feel for your situation and I am sorry that my work does not meet your personal expectations and/or ideals, however you are working with code on the sharpest point of the bleeding edge.
- Dean
I will look into this over the (long) weekend - my apologies as I have been busier than normal this week.
I do wish to re-iterate that the current release and current trunk explicitly states that all XMEGA code is "experimental" rather than "production ready" and that the demo I supplied was with the caveat that it was not guaranteed to be fully functional. I do feel for your situation and I am sorry that my work does not meet your personal expectations and/or ideals, however you are working with code on the sharpest point of the bleeding edge.
- Dean
Kolja
May 25, 2012, 9:39:20 AM5/25/12
to LUFA Library Support List
I know what you mean Graham. But I need only the very "simple"
application of a virtual com port and actually I got it to work now
with the following code:
Endpoint_SelectEndpoint(VirtualSerial_CDC_Interface.Config.DataOUTEndpoint.Address);
if(Endpoint_IsOUTReceived())
{
while(Endpoint_IsReadWriteAllowed())
{
if (!(RingBuffer_IsFull(&USB_Buffer)))
{
endP_read = Endpoint_Read_8();
RingBuffer_Insert(&USB_Buffer, endP_read);
}
}
Endpoint_ClearOUT();
fprintf(&USBSerialStream,"endP_read %x \r\n", endP_read);
}
CDC_Device_USBTask(&VirtualSerial_CDC_Interface);
USB_USBTask();
I used the RingBuffer_t structure to store the incoming data and so
far it works fine. But now I encountered another problem. I have to
use also some SPI interfaces and the internal ADC for my project and
therefore I would like to use Atmels framework within AVRStudio 5.1.
So now I am trying to combine the LUFA with the ASF within a project.
Do you have some suggestions how to do that? Should I try it without
the makefile otherwise I would have to specify all the c-files and
include paths?
Thanks for the replys.
application of a virtual com port and actually I got it to work now
with the following code:
Endpoint_SelectEndpoint(VirtualSerial_CDC_Interface.Config.DataOUTEndpoint.Address);
if(Endpoint_IsOUTReceived())
{
while(Endpoint_IsReadWriteAllowed())
{
if (!(RingBuffer_IsFull(&USB_Buffer)))
{
endP_read = Endpoint_Read_8();
RingBuffer_Insert(&USB_Buffer, endP_read);
}
}
Endpoint_ClearOUT();
fprintf(&USBSerialStream,"endP_read %x \r\n", endP_read);
}
CDC_Device_USBTask(&VirtualSerial_CDC_Interface);
USB_USBTask();
I used the RingBuffer_t structure to store the incoming data and so
far it works fine. But now I encountered another problem. I have to
use also some SPI interfaces and the internal ADC for my project and
therefore I would like to use Atmels framework within AVRStudio 5.1.
So now I am trying to combine the LUFA with the ASF within a project.
Do you have some suggestions how to do that? Should I try it without
the makefile otherwise I would have to specify all the c-files and
include paths?
Thanks for the replys.
ECROS Technology
May 25, 2012, 10:21:06 AM5/25/12
to LUFA Library Support List
Dean,
With respect, you offered no such caveat and wrote "I've only got LUFA
to the point of actually functioning properly at all on the XMEGAs
with the in-progress trunk". You did not directly answer my simple
question "What is the current state of ATxmega support in LUFA,
please, as of May 2012?" but published the two "X" demos and told me
to download the trunk. Any normal person would infer that this should
be working at least at a superficial level.
Kolja,
It looks as though what you've done is to dip down into the guts of
LUFA and haul up a bunch of internal functions and data structures.
Using them directly, rather than the CDC_Device_ReceiveByte() and
CDC_Device_SendByte() functions, you've got it to work. Well done.
However, I would argue that this stuff shouldn't even be visible to
the demo code. There should be an API that hides all these details
and the API should work. So, I'm pleased to know that the problem
isn't something really fundamental, but until the API works I'm still
considering this broken.
My suggestion for integrating SPI and the ADC is to do it yourself in
whatever compiler environment you prefer. These are not hard
peripherals to use. You may spend more time struggling with AVR
Studio 5.1 or Atmel Studio 6 than the time it would take you to write
the drivers. This is my personal way of working. I gather the tools
I like and stick with them (I will stay with AVR Studio 4 as long as
possible) because they have a profound affect on my productivity. I
avoid using other people's code, especially Atmel's, because I can
write new code from the datasheet faster than I can figure out someone
else's code and convince myself that it works. LUFA has been an
exception, because it's far more than a peripheral driver, and my
experience so far has not been that great.
Graham.
With respect, you offered no such caveat and wrote "I've only got LUFA
to the point of actually functioning properly at all on the XMEGAs
with the in-progress trunk". You did not directly answer my simple
question "What is the current state of ATxmega support in LUFA,
please, as of May 2012?" but published the two "X" demos and told me
to download the trunk. Any normal person would infer that this should
be working at least at a superficial level.
Kolja,
It looks as though what you've done is to dip down into the guts of
LUFA and haul up a bunch of internal functions and data structures.
Using them directly, rather than the CDC_Device_ReceiveByte() and
CDC_Device_SendByte() functions, you've got it to work. Well done.
However, I would argue that this stuff shouldn't even be visible to
the demo code. There should be an API that hides all these details
and the API should work. So, I'm pleased to know that the problem
isn't something really fundamental, but until the API works I'm still
considering this broken.
My suggestion for integrating SPI and the ADC is to do it yourself in
whatever compiler environment you prefer. These are not hard
peripherals to use. You may spend more time struggling with AVR
Studio 5.1 or Atmel Studio 6 than the time it would take you to write
the drivers. This is my personal way of working. I gather the tools
I like and stick with them (I will stay with AVR Studio 4 as long as
possible) because they have a profound affect on my productivity. I
avoid using other people's code, especially Atmel's, because I can
write new code from the datasheet faster than I can figure out someone
else's code and convince myself that it works. LUFA has been an
exception, because it's far more than a peripheral driver, and my
experience so far has not been that great.
Graham.
Chris McClelland
May 25, 2012, 10:59:05 AM5/25/12
to LUFA Library Support List
I understand you're frustrated, but I don't understand your motivation
in writing emails like this to a public group. It seems to me that
this attitude has three effects:
1) It serves to discourage new users. People who might otherwise have
contributed usefully to the project.
2) It annoys the main developer. One day he'll get fed up of dealing
with the minority of ungrateful users and stop donating his time to
help the grateful majority.
3) Sadly, it is detrimental to the ECROS brand image.
I don't really care about (3), but I do care about (1) and (2). By all
means, if you don't like LUFA, fix it and submit your patches back, or
start a competing project of your own. But before posting here, please
just ask yourself whether what you've written is constructive, and
whether it really is the best way to achieve your aims.
Chris
in writing emails like this to a public group. It seems to me that
this attitude has three effects:
1) It serves to discourage new users. People who might otherwise have
contributed usefully to the project.
2) It annoys the main developer. One day he'll get fed up of dealing
with the minority of ungrateful users and stop donating his time to
help the grateful majority.
3) Sadly, it is detrimental to the ECROS brand image.
I don't really care about (3), but I do care about (1) and (2). By all
means, if you don't like LUFA, fix it and submit your patches back, or
start a competing project of your own. But before posting here, please
just ask yourself whether what you've written is constructive, and
whether it really is the best way to achieve your aims.
Chris
Michael Hennebry
May 25, 2012, 12:02:20 PM5/25/12
to LUFA Library Support List
On Fri, 25 May 2012, Chris McClelland wrote:
> I don't really care about (3), but I do care about (1) and (2). By all
> means, if you don't like LUFA, fix it and submit your patches back, or
> start a competing project of your own. But before posting here, please
> just ask yourself whether what you've written is constructive, and
'Twas at least partly constructive.
> I don't really care about (3), but I do care about (1) and (2). By all
> means, if you don't like LUFA, fix it and submit your patches back, or
> start a competing project of your own. But before posting here, please
> just ask yourself whether what you've written is constructive, and
One need not include patches or start a project to be constructive.
The post included an example of spagetti
code and a suggestion on how to fix it.
> whether it really is the best way to achieve your aims.
Michael henn...@web.cs.ndsu.NoDak.edu
"On Monday, I'm gonna have to tell my kindergarten class,
whom I teach not to run with scissors,
that my fiance ran me through with a broadsword." -- Lily
Dean Camera
May 26, 2012, 11:13:39 AM5/26/12
to LUFA Library Support List
Kolja,
The latest LUFA trunk now contains a fix for this issue; I was
performing an incorrect calculation on OUT direction endpoints when
determining how many unread bytes are in the endpoint buffer. The fix
specifically for this issue is in this commit:
https://github.com/abcminiuser/lufa-lib/commit/b65af68d946603779a06acbb2a977f266409d847
Which should allow you to receive data correctly on the XMEGA devices
(I tested it locally with an XMEGA-B1 Xplained board). Sorry for the
inconvenience!
- Dean
The latest LUFA trunk now contains a fix for this issue; I was
performing an incorrect calculation on OUT direction endpoints when
determining how many unread bytes are in the endpoint buffer. The fix
specifically for this issue is in this commit:
https://github.com/abcminiuser/lufa-lib/commit/b65af68d946603779a06acbb2a977f266409d847
Which should allow you to receive data correctly on the XMEGA devices
(I tested it locally with an XMEGA-B1 Xplained board). Sorry for the
inconvenience!
- Dean
Dean Camera
May 26, 2012, 11:23:48 AM5/26/12
to LUFA Library Support List
Graham,
> With respect, you offered no such caveat and wrote "I've only got LUFA
> to the point of actually functioning properly at all on the XMEGAs
> with the in-progress trunk".
Honestly I would have thought that along is enough to warrant caution,
and be indicative that the current code is not production ready.
> You did not directly answer my simple
> question "What is the current state of ATxmega support in LUFA,
I did not, and you do have my apologies for that. I have said earlier
on the list that XMEGA support isn't complete, which is why it is
explicitly marked as experimental in the documentation (yes, even in
the trunk version you are using) and why my website does not claim
XMEGA support for it yet.
> but published the two "X" demos and told me
> to download the trunk. Any normal person would infer that this should
> be working at least at a superficial level.
I would not call posting some zip files here publishing in the normal
sense, but I suppose that is purely semantics. They are test code on
my private machine I uploaded as a courtesy -- but they are not final
which is why they are not in the actual repository. They are literally
cut-and-paste hackjobs to show how to get it working, while in the
final releases I will make the existing demos cross-platform (as I
don't want to maintain separate demos for each architecture).
> LUFA has been an
> exception, because it's far more than a peripheral driver, and my
> experience so far has not been that great.
Again, my apologies for your experience - as a courtesy I will refund
you twice the amount you paid so far to download and evaluate my
project.
- Dean
> With respect, you offered no such caveat and wrote "I've only got LUFA
> to the point of actually functioning properly at all on the XMEGAs
> with the in-progress trunk".
and be indicative that the current code is not production ready.
> You did not directly answer my simple
> question "What is the current state of ATxmega support in LUFA,
on the list that XMEGA support isn't complete, which is why it is
explicitly marked as experimental in the documentation (yes, even in
the trunk version you are using) and why my website does not claim
XMEGA support for it yet.
> but published the two "X" demos and told me
> to download the trunk. Any normal person would infer that this should
> be working at least at a superficial level.
sense, but I suppose that is purely semantics. They are test code on
my private machine I uploaded as a courtesy -- but they are not final
which is why they are not in the actual repository. They are literally
cut-and-paste hackjobs to show how to get it working, while in the
final releases I will make the existing demos cross-platform (as I
don't want to maintain separate demos for each architecture).
> LUFA has been an
> exception, because it's far more than a peripheral driver, and my
> experience so far has not been that great.
you twice the amount you paid so far to download and evaluate my
project.
- Dean
ECROS Technology
May 28, 2012, 9:13:42 AM5/28/12
to LUFA Library Support List
Dean,
I really don't want to drag this out, but you ought to consider that:
* It isn't unreasonable to consider "functioning properly" as pretty
close to "production ready". In fact, I never asked for "production
ready", all I want is "functioning properly".
* If someone asks what is the state of something *now*, they may be
aware of what you "said earlier" and be looking for an update. The
simplest and clearest answer would be to say that it had not changed.
The least clear answer is to give them work in progress that implies a
positive change that actually hasn't taken place.
* Posting zip files without disclaimers to your public support forum
certainly is publishing.
* I would like to accept your offer to "refund ... twice the amount
you paid so far to download and evaluate my project". You owe me
sixty hours of work. Joking aside, taking the attitude that because
you offer your work for free you are immune from criticism isn't going
to encourage anyone who wants to use your work in a serious project.
Graham.
I really don't want to drag this out, but you ought to consider that:
* It isn't unreasonable to consider "functioning properly" as pretty
close to "production ready". In fact, I never asked for "production
ready", all I want is "functioning properly".
* If someone asks what is the state of something *now*, they may be
aware of what you "said earlier" and be looking for an update. The
simplest and clearest answer would be to say that it had not changed.
The least clear answer is to give them work in progress that implies a
positive change that actually hasn't taken place.
* Posting zip files without disclaimers to your public support forum
certainly is publishing.
* I would like to accept your offer to "refund ... twice the amount
you paid so far to download and evaluate my project". You owe me
sixty hours of work. Joking aside, taking the attitude that because
you offer your work for free you are immune from criticism isn't going
to encourage anyone who wants to use your work in a serious project.
Graham.
ECROS Technology
May 28, 2012, 9:35:32 AM5/28/12
to LUFA Library Support List
Chris,
The motivation for all my posts is to share my experiences and
thoughts.
1) Discouraging new users - Perhaps I am forewarning new users who
want to do something more complicated than compile and play with an
existing demo. If you look at the detail in my posts about my
progress, perhaps I am helping them.
2) Annoying the developer. Annoyance is certainly one way that the
developer could react to criticism, but there are others.
3) Detrimental to the ECROS brand image. That's just a cheap shot.
I have offered to submit my work, to no reply. A problem is that new
work of the sort that I am doing won't be of much use unless it
conforms to the overall design philosophy of LUFA, which as you can
see I am having problems with. Also, it won't be of any durable use
if Dean is making architectural changes, which I think he is.
Regarding whether what I write is constructive, there is no way I can
know that until I see how readers, and particularly Dean, react.
Dean's options include not replying, making excuses, agreeing and
replying that improvements are in the works, disagreeing with or
without justification, telling me to go away, etc. Until I know which
option(s) he takes, I also cannot tell whether it is the best way to
achieve my aims. Certainly, nobody on this discussion group has
offered any direct help, but that probably just means that nobody is
doing anything very similar to what I'm doing.
Graham.
The motivation for all my posts is to share my experiences and
thoughts.
1) Discouraging new users - Perhaps I am forewarning new users who
want to do something more complicated than compile and play with an
existing demo. If you look at the detail in my posts about my
progress, perhaps I am helping them.
2) Annoying the developer. Annoyance is certainly one way that the
developer could react to criticism, but there are others.
3) Detrimental to the ECROS brand image. That's just a cheap shot.
I have offered to submit my work, to no reply. A problem is that new
work of the sort that I am doing won't be of much use unless it
conforms to the overall design philosophy of LUFA, which as you can
see I am having problems with. Also, it won't be of any durable use
if Dean is making architectural changes, which I think he is.
Regarding whether what I write is constructive, there is no way I can
know that until I see how readers, and particularly Dean, react.
Dean's options include not replying, making excuses, agreeing and
replying that improvements are in the works, disagreeing with or
without justification, telling me to go away, etc. Until I know which
option(s) he takes, I also cannot tell whether it is the best way to
achieve my aims. Certainly, nobody on this discussion group has
offered any direct help, but that probably just means that nobody is
doing anything very similar to what I'm doing.
Graham.
ECROS Technology
May 28, 2012, 10:47:18 AM5/28/12
to LUFA Library Support List
I would just like to say that Dean's fix for VirtualSerialX works on
my XMEGA-A3BU Xplained board. Because of where the fix is (USB core),
I trust that it will also work in the composite virtual serial and
mass storage device that is my goal. I described in the second
message in this thread the changes I made to the demo to a) port from
the B1 to A3BU, b) display presses of all three buttons and c) echo
terminal input back to the terminal, so that you can tell that
receiving characters works as well as sending them.
I would be very happy to contribute these changes, however, they are
so simple that it would probably take Dean less time to make them
himself than to review them made by someone else. He also may not
want yet another demo which is barely more than a clone of an existing
one.
Graham.
my XMEGA-A3BU Xplained board. Because of where the fix is (USB core),
I trust that it will also work in the composite virtual serial and
mass storage device that is my goal. I described in the second
message in this thread the changes I made to the demo to a) port from
the B1 to A3BU, b) display presses of all three buttons and c) echo
terminal input back to the terminal, so that you can tell that
receiving characters works as well as sending them.
I would be very happy to contribute these changes, however, they are
so simple that it would probably take Dean less time to make them
himself than to review them made by someone else. He also may not
want yet another demo which is barely more than a clone of an existing
one.
Graham.
Peter Kwan
May 28, 2012, 10:50:30 AM5/28/12
to lufa-s...@googlegroups.com
I'd say that your best course of action to save time in future is to
use something that you know is working and tested. If you want to use
the splendid XMega with USB then it isn't too much hassle to use two
AVRs. You get all your LUFA loveliness with your XMega muscle power. I
started my project on this board and got a big head start because it
came with a framework of code that I only needed to slot my code into.
I didn't even need a programmer.
http://www.mattairtech.com/index.php/development-boards/mt-x1.html
Peter
> --
> You received this message because you are subscribed to the Google Groups "LUFA Library Support List" group.
> To post to this group, send email to lufa-s...@googlegroups.com.
> To unsubscribe from this group, send email to lufa-support...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/lufa-support?hl=en.
>
use something that you know is working and tested. If you want to use
the splendid XMega with USB then it isn't too much hassle to use two
AVRs. You get all your LUFA loveliness with your XMega muscle power. I
started my project on this board and got a big head start because it
came with a framework of code that I only needed to slot my code into.
I didn't even need a programmer.
http://www.mattairtech.com/index.php/development-boards/mt-x1.html
Peter
> You received this message because you are subscribed to the Google Groups "LUFA Library Support List" group.
> To post to this group, send email to lufa-s...@googlegroups.com.
> To unsubscribe from this group, send email to lufa-support...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/lufa-support?hl=en.
>
Kolja
May 28, 2012, 4:16:14 PM5/28/12
to LUFA Library Support List
Thanks Dean. Actually I haven´t tried it yet. I am still using with my
work around, but I really appreciate your work and hopefully I will
not bother you again ;)
On 26 Mai, 17:13, Dean Camera <abcminiu...@gmail.com> wrote:
> Kolja,
>
> The latest LUFA trunk now contains a fix for this issue; I was
> performing an incorrect calculation on OUT direction endpoints when
> determining how many unread bytes are in the endpoint buffer. The fix
> specifically for this issue is in this commit:
>
> https://github.com/abcminiuser/lufa-lib/commit/b65af68d946603779a06ac...
work around, but I really appreciate your work and hopefully I will
not bother you again ;)
On 26 Mai, 17:13, Dean Camera <abcminiu...@gmail.com> wrote:
> Kolja,
>
> The latest LUFA trunk now contains a fix for this issue; I was
> performing an incorrect calculation on OUT direction endpoints when
> determining how many unread bytes are in the endpoint buffer. The fix
> specifically for this issue is in this commit:
>
ECROS Technology
May 29, 2012, 1:20:17 PM5/29/12
to LUFA Library Support List
Peter,
You wrote "... best course of action ... use something that you know
is working and tested". Well, of course. I rather assumed that LUFA
is working and tested and set about trying to find out the state of
ATxmega support with my first post here.
And "... isn't too much hassle to use two AVRs". On this project, I
am not in control of the hardware.
Graham.
You wrote "... best course of action ... use something that you know
is working and tested". Well, of course. I rather assumed that LUFA
is working and tested and set about trying to find out the state of
ATxmega support with my first post here.
And "... isn't too much hassle to use two AVRs". On this project, I
am not in control of the hardware.
Graham.
Kolja
May 30, 2012, 6:00:14 AM5/30/12
to LUFA Library Support List
Now I need to use the internal ADC and the SPI interface. I think the
ADC is not supported by LUFA but what about the SPI.
Has anyone tested that with a XMEGA device?
ADC is not supported by LUFA but what about the SPI.
Has anyone tested that with a XMEGA device?
Peter Kwan
May 30, 2012, 6:15:32 AM5/30/12
to lufa-s...@googlegroups.com
LUFA does have SPI drivers but I haven't used them. At a glance it
doesn't look like they can be used on the XMega.
http://www.fourwalledcubicle.com/files/LUFA/Doc/091122/html/a00225.html
Instead I used Atmel's XMega demo code as a good starting point
spi_polled_example.c
Peter
doesn't look like they can be used on the XMega.
http://www.fourwalledcubicle.com/files/LUFA/Doc/091122/html/a00225.html
Instead I used Atmel's XMega demo code as a good starting point
spi_polled_example.c
Peter
ECROS Technology
May 30, 2012, 8:41:10 AM5/30/12
to LUFA Library Support List
I have used the LUFA driver for ATxmega USARTs configured as master
SPI interfaces and it appears to work. It is called
"SerialSPI_XMEGA", although as SPI is a serial interface a better name
would be UsartSPI. So, if you need only master mode and you've not
yet wired up the hardware, you could use that. I would be surprised
if there is a problem with the LUFA driver for the ATxmega dedicated
SPI peripheral (SPI_XMEGA). I have not used it yet, but SPI is a very
simple peripheral and in polled mode there's not a lot that can go
wrong. If anything is wrong, we can easily fix it.
The ADC is also a simple peripheral. I suggest that you write a
driver from the data sheet. That way you will come to properly
understand the ADC.
Graham.
SPI interfaces and it appears to work. It is called
"SerialSPI_XMEGA", although as SPI is a serial interface a better name
would be UsartSPI. So, if you need only master mode and you've not
yet wired up the hardware, you could use that. I would be surprised
if there is a problem with the LUFA driver for the ATxmega dedicated
SPI peripheral (SPI_XMEGA). I have not used it yet, but SPI is a very
simple peripheral and in polled mode there's not a lot that can go
wrong. If anything is wrong, we can easily fix it.
The ADC is also a simple peripheral. I suggest that you write a
driver from the data sheet. That way you will come to properly
understand the ADC.
Graham.
Dean Camera
Jun 2, 2012, 10:22:38 AM6/2/12
to LUFA Library Support List
The SPI driver is not tested yet (no SPI hardware around to ensure it
works under all conditions), although I would be extremely surprised
if it fails - the XMEGA SPI peripheral is a testament to good design
and minimalism, so there isn't a whole lot that can go wrong. The
SerialSPI driver is tested and works correctly.
I haven't had a chance to write an ADC driver yet, but that will be
done once I have LUFA at a point when XMEGA support is actually useful
to the general public.
Cheers!
- Dean
works under all conditions), although I would be extremely surprised
if it fails - the XMEGA SPI peripheral is a testament to good design
and minimalism, so there isn't a whole lot that can go wrong. The
SerialSPI driver is tested and works correctly.
I haven't had a chance to write an ADC driver yet, but that will be
done once I have LUFA at a point when XMEGA support is actually useful
to the general public.
Cheers!
- Dean
ECROS Technology
Jun 6, 2012, 12:20:31 PM6/6/12
to LUFA Library Support List
Dean,
My personal opinion is that you should *not* write an ADC driver. You
wrote elsewhere that the point of the demos is just to show that the
underlying USB functionality works. There is no need for another
widget to hook up in the demos. Other people write ADC drivers.
Nobody else writes LUFA. Why not concentrate on the main event? On
the other hand, if you're looking at the ADC driver as a fun break,
forget everything I said.
Graham.
My personal opinion is that you should *not* write an ADC driver. You
wrote elsewhere that the point of the demos is just to show that the
underlying USB functionality works. There is no need for another
widget to hook up in the demos. Other people write ADC drivers.
Nobody else writes LUFA. Why not concentrate on the main event? On
the other hand, if you're looking at the ADC driver as a fun break,
forget everything I said.
Graham.
Kolja
Jun 6, 2012, 1:05:35 PM6/6/12
to LUFA Library Support List
I totally agree, it was really not that difficult to get the internal
ADC working. The same is for the SPI interface, but there was one
tricky thing which needs to be considered. For some reason all the
MOSI, SCK and SS pins need to be configured first if the master mode
is used (AVR XMEGA AU page. 285). In my case I had to set them as
outputs. So far I haven´t used it with the peripheral device but I
checked it with a logic analyzer and it seemed to work.
Today I tried to send a floating point variable to the terminal with
the fprintf function, but it appeared only as an questionmark. Do you
guys have an idea why?
ADC working. The same is for the SPI interface, but there was one
tricky thing which needs to be considered. For some reason all the
MOSI, SCK and SS pins need to be configured first if the master mode
is used (AVR XMEGA AU page. 285). In my case I had to set them as
outputs. So far I haven´t used it with the peripheral device but I
checked it with a logic analyzer and it seemed to work.
Today I tried to send a floating point variable to the terminal with
the fprintf function, but it appeared only as an questionmark. Do you
guys have an idea why?
Michael Hennebry
Jun 6, 2012, 1:13:03 PM6/6/12
to LUFA Library Support List
On Wed, 6 Jun 2012, Kolja wrote:
> I totally agree, it was really not that difficult to get the internal
> ADC working. The same is for the SPI interface, but there was one
> tricky thing which needs to be considered. For some reason all the
> MOSI, SCK and SS pins need to be configured first if the master mode
> is used (AVR XMEGA AU page. 285). In my case I had to set them as
> outputs. So far I haven�t used it with the peripheral device but I
> checked it with a logic analyzer and it seemed to work.
> Today I tried to send a floating point variable to the terminal with
> the fprintf function, but it appeared only as an questionmark. Do you
> guys have an idea why?
Yes.
> I totally agree, it was really not that difficult to get the internal
> ADC working. The same is for the SPI interface, but there was one
> tricky thing which needs to be considered. For some reason all the
> MOSI, SCK and SS pins need to be configured first if the master mode
> is used (AVR XMEGA AU page. 285). In my case I had to set them as
> outputs. So far I haven�t used it with the peripheral device but I
> checked it with a logic analyzer and it seemed to work.
> Today I tried to send a floating point variable to the terminal with
> the fprintf function, but it appeared only as an questionmark. Do you
> guys have an idea why?
The avr-gcc has three associated stdio libraries.
Only the big one does floating point.
Kolja
Jun 6, 2012, 4:44:40 PM6/6/12
to LUFA Library Support List
Ok thanks. I guess that´s the option including the library in the make
file.
# If this is left blank, then it will use the Standard printf version.
#PRINTF_LIB =
#PRINTF_LIB = $(PRINTF_LIB_MIN)
PRINTF_LIB = $(PRINTF_LIB_FLOAT)
On Jun 6, 7:13 pm, Michael Hennebry <henne...@web.cs.ndsu.nodak.edu>
wrote:
file.
# If this is left blank, then it will use the Standard printf version.
#PRINTF_LIB =
#PRINTF_LIB = $(PRINTF_LIB_MIN)
PRINTF_LIB = $(PRINTF_LIB_FLOAT)
On Jun 6, 7:13 pm, Michael Hennebry <henne...@web.cs.ndsu.nodak.edu>
wrote:
> On Wed, 6 Jun 2012, Kolja wrote:
> > I totally agree, it was really not that difficult to get the internal
> > ADC working. The same is for the SPI interface, but there was one
> > tricky thing which needs to be considered. For some reason all the
> > MOSI, SCK and SS pins need to be configured first if the master mode
> > is used (AVR XMEGA AU page. 285). In my case I had to set them as
> > outputs. So far I haven�t used it with the peripheral device but I
> > I totally agree, it was really not that difficult to get the internal
> > ADC working. The same is for the SPI interface, but there was one
> > tricky thing which needs to be considered. For some reason all the
> > MOSI, SCK and SS pins need to be configured first if the master mode
> > is used (AVR XMEGA AU page. 285). In my case I had to set them as
> > checked it with a logic analyzer and it seemed to work.
> > Today I tried to send a floating point variable to the terminal with
> > the fprintf function, but it appeared only as an questionmark. Do you
> > guys have an idea why?
>
> Yes.
> The avr-gcc has three associated stdio libraries.
> Only the big one does floating point.
>
> --
> Michael henne...@web.cs.ndsu.NoDak.edu
> > Today I tried to send a floating point variable to the terminal with
> > the fprintf function, but it appeared only as an questionmark. Do you
> > guys have an idea why?
>
> Yes.
> The avr-gcc has three associated stdio libraries.
> Only the big one does floating point.
>
> --
ECROS Technology
Jun 7, 2012, 8:52:47 AM6/7/12
to LUFA Library Support List
Kolja,
In case you're still following this thread ... my customer has given
up on the mass storage functionality, so now I am doing more-or-less
the same thing as you, using the VirtualSerialX demo as a starting
point to get a USB virtual serial port working on custom hardware.
If you were as startled as I was by the data memory use (about 2.5
Kbytes) and would like to see it reduced, take a look at the thread
"Adapting VirtualSerialX to a real application - reducing data memory
use ". If my understanding is correct, about 83% of that 2.5 Kbytes
is wasted and some fairly simple changes will reduce data memory use
to less than 700 bytes. At present I am waiting for Dean to confirm
this or help to correct my understanding.
Graham.
In case you're still following this thread ... my customer has given
up on the mass storage functionality, so now I am doing more-or-less
the same thing as you, using the VirtualSerialX demo as a starting
point to get a USB virtual serial port working on custom hardware.
If you were as startled as I was by the data memory use (about 2.5
Kbytes) and would like to see it reduced, take a look at the thread
"Adapting VirtualSerialX to a real application - reducing data memory
use ". If my understanding is correct, about 83% of that 2.5 Kbytes
is wasted and some fairly simple changes will reduce data memory use
to less than 700 bytes. At present I am waiting for Dean to confirm
this or help to correct my understanding.
Graham.
Dean Camera
Jun 7, 2012, 12:07:10 PM6/7/12
to lufa-s...@googlegroups.com
Yes, that's the one. By default avr-libc does not support floating point printf() or scanf() due to the large binary size, however you can override it with that setting to use the (even more) restricted or less restricted floating point versions of the functions.
- Dean
- Dean
Reply all
Reply to author
Forward
0 new messages