Some questions about LPCUSB with LPC2378

-> As Tamir says, that would not necessarily be any different in a big company!

I had worked for a big global firm, where I met some real professionals, and co-worked with them. That was the only good thing. Oh, the pay was good too.

Before that, or after that, I haven't had any opportunity to co-work with real professionals.

-> As Tamir says, that would not necessarily be any different in a big company!

I had worked for a big global firm, where I met some real professionals, and co-worked with them. That was the only good thing. Oh, the pay was good too.

Before that, or after that, I haven't had any opportunity to co-work with real professionals.

To me, the biggest difference between small and large companies lays in the scope of your work (this may not always be true, of course). When you end up in a big company, you are not likely to be allowed to write something from scratch, really from scratch - using existing components will be required even if they suck (perfectly logical of course - time is money). One of the products firmware framework (plus some application) I am now working on was written almost entirely by me to my liking - from total scratch (except RL-ARM components of course). So, you need to know almost everything. However, when I worked for one of these large companies I begged to do more and get to know more, but my team leader would not allow me, because I had my responsibilities. that sucked, and was the main reason I left.

Hi Tsuneo,

With your exposition and help, I think/guess I have gotten enough information for my stage-1.

I will re-read all the stuff I read before, trying to get a better understanding of the LPCUSB's CDC example.

Then, in my stage-2, I will try to slightly re-write the main_serial.c etc.

Many thanks.

I am just being told that the USB based I/O board should be capable to handle the data transmission every millisecond. The X86 Linux Application polls the USB based I/O board every millisecond, then the USB I/O board must respond right away.

I don't think this is a rational requirement. I think/guess that, the USB host controller chip on the X86 platform polls the USB device every millisecond, but such a polling is unintentional. I just checked and confirmed that, for Ubuntu 9.10 Desktop Linux, the CONFIG_HZ is 250 (tick = 4ms).

I don't know how to write a Linux testing application to poll the USB based I/O board every millisecond. And I don't know how to explain this to them.

> I am just being told that the USB based I/O board should be capable to handle the data transmission every millisecond.

This assumption is almost ture, but not 100%.
You may see around 2 ms interval occasionally. Then, you need buffering so as not to drop the data.
Also, the transfer size becomes greater, this assumption breaks. A packet-full size (64 bytes) is a good amount.

To run 1 ms interval using a generic device driver like libusb, you have to put multiple asynchronous calls in advance, without waiting completion of any call.
When a call finishes, put another call, to keep the request queue populate.

Tsuneo

==> \LPCUSB\target\examples\main_serial.c

/**
        Local function to handle incoming bulk data

        @param [in] bEP
        @param [in] bEPStatus
 */
static void BulkOut(U8 bEP, U8 bEPStatus)
{
        int i, iLen;

        if (fifo_free(&rxfifo) < MAX_PACKET_SIZE) {
                // may not fit into fifo
                return;    // Here!!!
        }

        // get data from USB into intermediate buffer
        iLen = USBHwEPRead(bEP, abBulkBuf, sizeof(abBulkBuf));
        for (i = 0; i < iLen; i++) {
                // put into FIFO
                if (!fifo_put(&rxfifo, abBulkBuf[i])) {
                        // overflow... :(
                        ASSERT(FALSE);
                        break;
                }
        }
}

If there is no space in the rxfifo (rxdata), the ISR function BulkOut() returns.

In such a case, the EP_SLOW bit in USBDevIntClr Register had been set (cleared) by the major ISR function USBHwISR() already. But the bEP is still full with data, so the host application will not be able to write any data into this bEP (OUT-NAK), so the ISR function BulkOut() will not be triggered once again.

The data in the bEP will never be processed. It is a dead-end.

Test Only.