| Author |
Message |
|
|
 Posted: Mar 22, 2012 - 08:54 AM |
|
Joined: Dec 26, 2006
Posts: 1407
Location: Sydney, Australia
|
|
Ermm..I know some of you will tell me to post in AVR32, but this is a fairly generic question, may also apply to xmegas..
Plus I am not happy at the rate people reply on AVR32 forums.
OK I have finally been able to configure the UC3A1256 USB Host mode using DMA! BUT! There are problems....
I am trying to talk to a 3G usb modem...which makes available more than 1 pipe...I have 4 pipes to deal with, besides the control pipe. Micro is running in full speed. So all pipes shown by the 3G device is 64bytes in length.
I have a loop where I check if the last pipe was frozen (finished sending data), if yes then I move to next pipe and try to start send data or receive data if there is data to be sent or received. This starting of send or receive is done using DMA calls.
I am noticing very poor performance (non deterministic) if I just do the above in a loop. However if I just have checking of frozen status of previous pipe and all (as above) inside my 1ms timer interrupt, then the usb device performs pretty well...
Is it possible that if I put in a loop then its possible the device is occasionally going to "suspend" mode? Whereas if put the checks inside an interrupt then it a pipe is guaranteed to be sending or receiving data almost in every 1ms?
I am a bit puzzled...
Aside from all this say you have 4 pipes 2 of which are OUT and the other 2 are IN pipes. How do you switch from 1 pipe to another pipe constantly? A loop obviously fails me...(as above). Interrupt runs every 1ms...which is ok...but I would ideally like to keep talking to the USB device ALL the time...on each pipe sequentially...as in 1st pipe, 2nd pipe, 3rd pipe 4th pipe then 1st pipe agian...etc.
Any thoughts? |
|
|
| |
|
|
|
|
|
|
Posted: Mar 22, 2012 - 02:48 PM |
|
Joined: Jun 22, 2004
Posts: 3849
Location: South West Utah, USA
|
|
|
luvocean1 wrote:
...may also apply to xmegas..
Sorry, not perfectly on topic, but I did not know there were any any Xmega USB chips that supported OTG host mode. If I missed it in the Xmega data sheets I would be very happy to find that out. |
|
|
| |
|
|
|
|
|
|
Posted: Mar 23, 2012 - 03:17 AM |
|
Joined: Dec 26, 2006
Posts: 1407
Location: Sydney, Australia
|
|
lol ok u win 
Anyone with some clearifications to the usb pipe bus sharing? |
|
|
| |
|
|
|
|
|
|
Posted: Mar 26, 2012 - 11:10 PM |
|
Joined: May 26, 2004
Posts: 2538
Location: Las Vegas, Nevada
|
|
Need some details of your configuration. Generally a modem would have a bidirectional control pipe and one out, one in, bulk pipes. I take it the other two are for a second interface of some kind.
Generally speaking, bulk interfaces will use any spare time on the bus if there's data to send. You don't have to wait for the next millisecond to load the buffers - if you hurry, you can get 18 64-byte packets out in one frame. Bus sharing is handled by the USB engine hardware, so if there are four pipes each trying to send data, each will get their turn in the same frame. You can fill them all at once, they won't conflict. If any time is left over in the frame and there's an IN pipe unfrozen, the remainder of the frame will be filled with IN requests and NAKs. For this reason it's a good idea to freeze the IN pipes unless you're specifically waiting for something. |
|
|
| |
|
|
|
|
|
|
Posted: Mar 27, 2012 - 04:01 AM |
|
Joined: Dec 26, 2006
Posts: 1407
Location: Sydney, Australia
|
|
thanks for that peret... previously you had said i is 17 packet of 64 bytes in one ms...now you said 18. Is it 17 or 18?
Ok so I am trying to talk to a 3G modem... using UC3A1256 as the Host controller. The USB modem discloses more than 2 interfaces but I only configure my micro for 2interfaces in otherwise the AT interface (2pipes: IN-1, OUT-2), and the diagnostic interface (3 pipes of IN-2 and OUT-4).
My plan is to do perform:
4INs of pipe 1,
4OUTs of pipe 2,
1IN of pipe 3,
1OUT of pipe 4.
every 1ms (all of 64btyes). So no need to utilize the full 17 64 packets.
i am not sure Atmel UC3 can do automatic bus sharing as I manually have to freeze and unfree each pipes.
At the moment, At each SOF interrupt I send off the pipe 1 IN, as soon as that is finished or gets NAKed, I then raise another SOF interrupt (manually), which gets the next pipe in the list and starts OUT on that namely pipe 2...similarly once that is finished I then raise another SOF interrupt and process the next pipe 3...and so on..until I reach pipe 4, in which case I stop. Then again at next 1ms the real SOF interrupt (not manual) gets raised and the above process gets repeated... Do you see any problem with it? I wish didnt have to raise those interrupts manually....it wastes processing power. If usb could handle all that, it would have been nicer.
I am now in the process of making my Control pipe interrupt driven as well (the other pipe are DMA driven). Once I have achieved that then I want to add control pipe(0) before the above 4 pipe processing list in each 1ms.
So all up I will have 1 + 4 + 4 + 1 + 1 = 11 of 64packets beign transfered every 1ms instead of the full 17 you claim. |
|
|
| |
|
|
|
|
|
|
Posted: Mar 27, 2012 - 04:34 AM |
|
Joined: May 26, 2004
Posts: 2538
Location: Las Vegas, Nevada
|
|
|
luvocean1 wrote:
thanks for that peret... previously you had said i is 17 packet of 64 bytes in one ms...now you said 18. Is it 17 or 18?
I probably used a different guess for the overhead. That's all it is, a guess. Maybe you can get 18, maybe 17. Look up the low level packet formats and do your own math if it matters. Unless you carefully optimize your code, rather than using the strange method you describe below, you'll probably only get one or two.
Quote:
Ok so I am trying to talk to a 3G modem... using UC3A1256 as the Host controller. The USB modem discloses more than 2 interfaces but I only configure my micro for 2interfaces in otherwise the AT interface (2pipes: IN-1, OUT-2), and the diagnostic interface (3 pipes of IN-2 and OUT-4).
My plan is to do perform:
4INs of pipe 1,
4OUTs of pipe 2,
1IN of pipe 3,
1OUT of pipe 4.
every 1ms (all of 64btyes).
Why? What makes you think you need - or will be able - to use the AT interface and the diagnostic interface at the same time? WTF would you be doing that needs a diagnostic call every millisec anyway?
Let's say you have a few kilobytes of bulk to send, and you may receive something also. Unfreeze the IN pipe and tell it to interrupt you when it has a packet in it. Then start stuffing your data in the OUT buffer, 64 bytes at a time, whenever the flag says it's empty. Whenever you get an IN interrupt, empty the IN buffer and unfreeze it again. THAT IS ALL. No need to fuss around with the pipes, just treat them as a UART with 64 byte send and receive buffers. As for the diagnostic channel, that's not a real-time data channel. You can inspect it every now and again to see if it has anything to say. You won't miss anything by leaving the pipe frozen, as it will just catch up when you unfreeze it. Or you can leave it open but not on interrupt, and just poll it occasionally to see if a packet showed up. As long as there's an unread packet in the buffer, your host will NAK any attempt to send another, so it won't get overwritten. |
|
|
| |
|
|
|
|
|
|
Posted: Mar 27, 2012 - 09:15 AM |
|
Joined: Dec 26, 2006
Posts: 1407
Location: Sydney, Australia
|
|
hhm...perhaps I didnt explain it well enough... I dont just always keep the pipes unfrozen...
there are two layers...well two parts accessing the buffer for each pipe...application layer and the SOF interrupt layer.
The application layer when required sends to the out pipes and marks it ready for transfer, similarly when it has read the in pipes it marks it ready to accept. SOF interrupt on the other hand check every 1ms "what is the status of pipe 1 now, is it ready to acccept data, if yes then I am going to unfreeze and do IN requests". Once it has performed 4 IN requests (I chose that number) or has recieved NAK straight after the 1st of the 4 IN requests then I freeze that pipe and raise manually another SOF interrupt. This interrupt as before will check "Ah whats my next pipe (2) doing, is it ready to send some data out, if yes then here I start DMA now on pipe 2". As soon as that DMA is finished I raise another SOF interrupt manually, and that interrupt routine again checks whats my next pipe doing, is it ready to receive or transmit (if applicational layer marked it so). Only then do these pipes actually transact data using DMA.
The problem with the above is that, pipe 1 will not send another data packet (if it was made ready by application layer) until the next 1ms frame and so on with other pipes.
The AT interface is meant to be alive fairly consistently, the diagnostic interface well the application layer writes the OUT pipe (3) every 4 seconds, hence expects an IN on pipe (4) soon after that.
So the Diagnostic out pipe is only OUTed every 4seconds, but IN every 1ms for 1 of 64byte frame only.
AT interface pipe 2 is only OUTed if application has made the buffer ready and only 4 of 64bytes at a time per frame. The pipe 1 for receive is INed for 4 of such 64bytes. If no data then device will NAK straight after the 1st attempt of IN (so the last 3 IN will is stopped from sending). The rest of the time inside the 1ms frame nothing is done.
I have noticed that if I do not have anything happening within every 3ms then the modem behaves poorly, evident by the ftp data transfer on wireshark. I get dropped packets or delayed packets. So I would prefer to keep the USB line busy even if it is by doing IN request on pipe 1 (AT interface) every 1ms and getting NAKed cause there is no incoming data anyway. |
|
|
| |
|
|
|
|
|
|
Posted: Mar 27, 2012 - 09:49 AM |
|
Joined: Dec 26, 2006
Posts: 1407
Location: Sydney, Australia
|
|
From what you have posted ... I am thinking of a newer n perhaps better strategy than what I have done above... for each pipe I should have a priority/weighting facility.
eg:
AT interface pipe 1 (IN): say 4 weights (4x64=256 bytes packet)
AT interface pipe 2 (OUT): say 4 weights (4x64=256 bytes packet)
Diag interface pipe 3 (IN): say 1 weights (1x64=64 bytes packet)
AT interface pipe 4 (OUT): say 1 weights (1x64=64 bytes packet)
I will give say a total weighting of 16 of 64 btyes to be sent acrosss the whole duration of 1 frame (1 SOF). In theory I have been seeing varied figures from 1293 to 1500 bytes capacity during 1ms frame in various online texts...
So to stay safe lets say I have a limit of 16 thus giving a maximum transfer of 1024 possible bytes (not all from same pipe) during a 1ms frame.
So in each SOF interrupt raised I will have a weight counter from 0 to 15. In this interrupt handler the procedure will be:
-What is the next pipe and what is its weighting, if its weight + my current weight counter is <= 16, send or recv pipe.
-Update my weight counter by adding to it this pipes weight.
-If my New current weight counter is == 16, stop transacting any further data from any pipe until new 1ms frame.
On a new 1ms SOF interrupt repeat the above process.
What do you think? |
|
|
| |
|
|
|
|
|
|
Posted: Mar 27, 2012 - 05:01 PM |
|
Joined: May 26, 2004
Posts: 2538
Location: Las Vegas, Nevada
|
|
| I don't know what to think. I never used the SOF interrupt in my projects, except to clock a timeout counter - no ACK or NAK for 1000 SOFs after I sent a request, the device is probably gone to sleep and needs reset and re-enumeration. Once communication is established and working I never give any thought to it. If the OUT endpoint is idle and there's stuff to send, I send it. If there's something in the IN endpoint, I read it. I leave the physical layer hardware to take care of all the timing and housekeeping. The only time I freeze the IN endpoints is when I have a large bulk to send (>4kB) and I don't expect a response until it's sent, because it frees up a little extra bus time by not sending the IN requests. |
|
|
| |
|
|
|
|
|
|
Posted: Mar 29, 2012 - 01:20 PM |
|
Joined: Dec 26, 2006
Posts: 1407
Location: Sydney, Australia
|
|
It seems you are right!
It is possible to unfreeze the pipes as u see fit and just wait till they finished sending or receiving. I check that by checking if the pipe is frozen. Only then do I write to buffer or read from buffer.
It seems to be working reliably now... I am processing the pipes from a from a function call from main...so it gets called pretty often. No more complicated calls from the SOF interrupts!
I have noticed something of worry though... I am not able to SET ADDRESS.
If I try to send a setup req of SET ADDRESS and then configure my control pipe with the new address, it will no longer receive or send anything in that pipe...I dont get a IN interrupt after the setup request is sent...Pending investigation!
For now I have been talking to the device with the default address of 0 without trying to set an address. |
|
|
| |
|
|
|
|
|
|
Posted: Mar 31, 2012 - 12:26 PM |
|
Joined: Dec 26, 2006
Posts: 1407
Location: Sydney, Australia
|
|
Ok... here is an issue... for the IN pipes depending on the buffer size...for example if my buffer size is 64*4...then I set the INRQ value to be 4-1 to get 4 IN request sent on that pipe..
The thing is if the modem hasnt got anything to send me, then it NAKs...unfortunately it seems a NAK is not considered a "transfer" hence the INRQ register is not decremented automatically upon each IN reqeust. This means if the modem has nothing to send, the UC3A will contually keep sending IN requests and never freeze the pipe by itself.
The way to deal with this is to raise a NAK interrupt whenever I get NAKed. This way, I can freeze the pipe manually and not worry about the INRQ register.
Whats your thought on this? |
|
|
| |
|
|
|
|
|
|
Posted: Mar 31, 2012 - 08:11 PM |
|
Joined: May 26, 2004
Posts: 2538
Location: Las Vegas, Nevada
|
|
My thoughts are, if god had intended us to worry about NAK packets, he would never have given us a low level USB engine to take care of them automatically for us.
A NAK is not a transfer, as you say, and is of no importance to you. Let the hardware deal with the bus and don't worry about it. If you were to borrow a USB analyzer and look at the traffic on the bus with a commercial USB device, you would see it doesn't take more than a few seconds to log a million NAKs, yet everything seems to go on working just fine. |
|
|
| |
|
|
|
|
|
|
Posted: Mar 31, 2012 - 11:28 PM |
|
Joined: Dec 26, 2006
Posts: 1407
Location: Sydney, Australia
|
|
But then the IN pipe will never get frozen by itself if I dont freeze it myself at the NAK interrupt! And if it never freezes itself, no other pipes send or receive data because the first IN pipe is still sending IN requests and holding the bus thus.
It would be good if it auto froze at the reception of a NAK...
How do you deal with that? |
|
|
| |
|
|
|
|
|
|
Posted: Apr 01, 2012 - 04:29 AM |
|
Joined: May 26, 2004
Posts: 2538
Location: Las Vegas, Nevada
|
|
| You don't understand how it works and obviously I'm not a good instructor. Get yourself a book and read it up. |
|
|
| |
|
|
|
|
|
|
Posted: Apr 01, 2012 - 07:42 AM |
|
Joined: Dec 26, 2006
Posts: 1407
Location: Sydney, Australia
|
|
| I am just telling you how the UC3 is behaving... I get the idea, its very simple. But I cant get it to auto freeze if the modem NAKs the inpipe. I have to raise the NAK interrupt and manually freeze it for it to release the bus so other pipes can go ahead. |
|
|
| |
|
|
|
|
|
|
Posted: Apr 01, 2012 - 07:50 AM |
|
Joined: May 26, 2004
Posts: 2538
Location: Las Vegas, Nevada
|
|
It doesn't tie up the bus, luvocean1. It just fills in the spare time that nothing else is using. You don't need to freeze it.
Why don't you download Dean's LUFA and have a look at the code. Ue doesn't use interrupts at all, except to detect when something gets plugged or unplugged. |
|
|
| |
|
|
|
|
|
|
Posted: Apr 01, 2012 - 11:20 PM |
|
Joined: Dec 26, 2006
Posts: 1407
Location: Sydney, Australia
|
|
yes I had a look...he doesnt use DMA. Instead of using interrupts he checks for interrupt flags in loop. Which is fine.
well I dont know what else to do... I have spent all days yesterday trying to get my thing to go. Its interesting though when I keep IN pipe unfrozen and dont freeze it at the NAK interrupt and then unfreeze the out pipe to send data, soon the DMA end of buffer transmission for out pipe fires telling me out pipe finished sending. But when I enable number of busy bank at during this interrupt, the number of busy bank interrupt never gets raised. In other words Out pipe never really sent data to empty the banks.
Funny thing is it all works fine I freeze the in pipe at the NAK interrupt. I just wish I didnt have to raise the NAK interrupt all the time, thus saving processor power. |
|
|
| |
|
|
|
|
|
|
Posted: Apr 08, 2012 - 05:33 AM |
|
Joined: Dec 26, 2006
Posts: 1407
Location: Sydney, Australia
|
|
I just wanted to drop by and update my progress here.... I have given up the "not interrupt on NAK" method. It doesnt work. With UC3A you explicitly have to freeze the IN pipe by the looks of it.
So for IN pipe I activate NAK interrupt, and when the NAK interrupt is raised, I freeze the IN pipe and thus release the bus. This allowes the previously unfrozen OUT pipe (which was ready to stream through) to start sending data. Thus OUT pipe is transmitted.
Following that when OUT pipe is finished (checked by number of busy banks) I freeze the OUT pipe and start off the whole process of IN pipe again. If NAKed I freeze it again. etc...
The code now works reliably....well so far it seems to. |
|
|
| |
|
|
|
|
|
|
Posted: Apr 08, 2012 - 08:51 AM |
|
Joined: May 26, 2004
Posts: 2538
Location: Las Vegas, Nevada
|
|
| The hardware must work differently on the UC3A, then. I assumed it was the same as the AT90USB1287, which is what I use. |
|
|
| |
|
|
|
|
|
|
Posted: Apr 08, 2012 - 09:43 AM |
|
Joined: Dec 26, 2006
Posts: 1407
Location: Sydney, Australia
|
|
well I have sent code samples to Atmel, lets see what they say...will keep you guys posted  |
|
|
| |
|
|
|
|
|
FAQ
Search
Register
Log in to check your private messages
Log in
Maximize
RSS
