how polling works with lufa

[ulao]

Can I get I description how the pulling works... With v-USB it was something like

while (not read) poll

Ok, USB is read send it...

now I have 8 ms to kill time....

loop

with Lufa I set my poll rate to 1 but I'm pretty sure the OS is going to force 2 but there is no while loop in the demo I based form. So I think the client just delivers the current packet to the host on irq

init: start an IRQ going off every xpollrate and delver what ever I have.

code: do what I want but occasionally update the HID_Task() and   USB_USBTask()

So the two are not necessarily ties together in any sequential means. If this is about right could one use a function to wait for ready?

[Dean Camera]

Hi Ulao,

Hrm, I think there's a translation barrier here, as I don't quite understand what you are asking.

LUFA works via polling for more circumstances, but unlike V-USB it polls the USB hardware in the AVR processor, rather than directly bit-banging the USB data lines like V-USB. As a result, you don't need to have a very regular and explicit timing on the *_Task() functions - just call them in your main loop as often as you like. As long as you call HID_Task() and USB_USBTask() at least every few milliseconds, it should "just work".

If your project has very tight timing requirements for other functions, like a software bit-bang UART, you should use the hardware timers and interrupts to manage it, and just keep the LUFA update functions called in your `main()` inside an infinite loop.

A good starter example project is the USBtoSerial converter, at https://github.com/abcminiuser/lufa/blob/master/Projects/USBtoSerial/USBtoSerial.c - this uses the main() function to poll the LUFA update functions (to manage the USB connection) along with USART interrupts from the hardware USART (to handle the serial communications). The USART is interrupt driven as the project needs to quickly save any received bytes into a buffer, so that they can be sent to the host PC over USB at a later point in time, once the PC asks for new data.

- Dean

--
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 view this discussion on the web visit https://groups.google.com/d/msgid/lufa-support/85b04840-92ad-4d67-a13c-9ffce657fc36n%40googlegroups.com.

[ulao]

yeah perhaps I do not really understand how hardware USB works then. That may be ok as long as I know the rules. I'm starting to understand anyways :) Here are my real world reasons for asking, maybe they can be answered without me having to understand the mechanism.

To communicate with device A, I need to created a wave form that has a PWM signal that will rising and falling every 300ns. If I'm 310ns off, the communication fails. So with v-USB I do wait for USB to do its thing, now I have 8ms to talk to my device and I know the USB interrupts will not get in the way. So what do I mean by interrupts? I mean two things I guess, 1 the keep alive that goes off every 1ms, and two, the data transfer for interrupt transfers. Knowning the USB is done and having 1ms to talk, I'm free and clear.

To deal with v-USB when receiving a control transfers I'm pretty much out of luck. It spends %97 of the time satisfying the host. I know this is not the case with LUFA but again, if I'm talking to a device with tight timing I need to disable interrupts on the AVR with V-USb. If I do not do that, the control transfer will step all over my communication. and if I do not reply NAC to the host within 300 us, it crashes. Well that is a catch 22.... if I disable interrupts, I can not catch the requests and reply with NAC...  Now since most software is ok with a crashing host, I let that happen. Though it does cause some issue in software development.

So in the former example, I really need to know if the USB caused any interruptions but so far I'm not seeing this and maybe I do not have to worry about it. If the USB is not going to "interrupt" the CPU, then I'm good.

The later example I'm hopping will never be a concern. Though, again, when I'm talking to my time sensitive device, and if the host interrupts the MCU, I will need to flag something so I can mark my data dirty.

Hope that gives a better idea of why I'm asking.

[ulao]

I think the best solution I found was to use

void EVENT_USB_Device_StartOfFrame     ( void )
{
    SOF = true;
}

then I can set the flag to false, and while till it's true.

and that way if the SOF occurred I can mark my data as dirty. Also, not as good for a few reason on my end but I can wait for SOF before I begin.