> I suggest you get build 142 from the SVN archive, not the older
> version on Sourceforge which has a known bug (excessive interrupts
> and thus load on processor, but otherwise harmless).
I think I've got this buggy version... Whenever I plug in the
USB connector to the laptop, everything slows way down.

Is it correct that main_serial.c is the only file that has to
be changed to get rid of the interrupt flood bug ?????

I have LPCUSB running on IAR EWARM and have it combined with
RS232 functions for my bootloader software. I noticed that when
I set up a counter in a main while(1) loop and just output
the count value through the RS232 that as soon as I plug in that
cable it slows down about 10 times. I also notice that the
VCOM_getchar() always gives me numbers, which I hope I might
be able to figure out. I'm still gathering some good info from
the previous threads, but it looks like I have a little ways
to go yet.

thanks,
boB

--- In l..., "darkcobrax" wrote:

> LPCUSB is available for the the LPC214x, which has an excellent
> virtual COM example. Homepage is here:
>
> http://wiki.sikken.nl/index.php?title=Main_Page
>
> I suggest you get build 142 from the SVN archive, not the older
> version on Sourceforge which has a known bug (excessive interrupts
> and thus load on processor, but otherwise harmless).
>
> LPCUSB's VCOM example allows you to communicate over USB with the
> VCOM driver on the PC, via simple character put and get functions,
> and it also provides adjustable FIFO buffers. I don't think it's
> directly stdio compatible, but it should be trivial to modify or
> write a wrapper to achieve this, without any understanding of the USB
> stack and with minimal changes to existing code.
>
> My situation is similar to yours - I needed fast, simple serial
> communications over USB, and I didn't want to dig into the USB
> stack. One of the main reasons I selected the LPC2148 for my project
> is because I knew of the existence of LPCUSB. I also considered
> using a FTDI converter chip as a backup plan in case I couldn't get
> LPCUSB to work, but LPCUSB has worked out very nicely indeed.
> Start a New Thread

> I suggest you get build 142 from the SVN archive, not the older
> version on Sourceforge which has a known bug (excessive interrupts
> and thus load on processor, but otherwise harmless).
I think I've got this buggy version... Whenever I plug in the
USB connector to the laptop, everything slows way down.

Is it correct that main_serial.c is the only file that has to
be changed to get rid of the interrupt flood bug ?????

I have LPCUSB running on IAR EWARM and have it combined with
RS232 functions for my bootloader software. I noticed that when
I set up a counter in a main while(1) loop and just output
the count value through the RS232 that as soon as I plug in that
cable it slows down about 10 times. I also notice that the
VCOM_getchar() always gives me 0xFF if the USB cable is unplugged,
which I hope I might be able to figure out. I'm still gathering some
good info from the previous threads, but it looks like I have a little
ways to go yet.

thanks,
boB

--- In l..., "darkcobrax" wrote:
>
> --- In l..., "t_chinzei" wrote:
> >
> > Sorry for my intrusion.
> >
> > Surely, the VCOM example hides the complicated USB enumeration
> thingy,
> > but if you need fast communication, you should know the USB
> > characteristic under the VCOM implementation.
>
> It was a welcome intrusion. That's a great description, and I've
> saved it to my notes for future reference. It also matches and
> explains the results of my own stress testing.
>
> I used "fast" as a relative term, meaning "faster than UART".
> Implementing my project over UART is possible, but would require
> limiting some functions and/or using some tricky data packing. With
> USB I won't have to worry about such things, since I'll never come
> close to the max.
> Start a New Thread

Hello boB,

> Whenever I plug in the USB connector to the laptop,
> everything slows way down.

The "the interrupt flood bug" is caused by the NAK interrupt.
NAK interrupt is indeterminate. When the USB bus is idle, you'll see
20-30 IN-NAK within 1msec USB frame. But when the bus is populated,
very few IN-NAK occur. Maybe Bertrik weren't aware of this NAK
indeterminacy when he designed the stack. Usually, just SOF interrupt
is applied for this implementation, as I showed on this post.
http://tech.groups.yahoo.com/group/lpc2000/message/23334
> I also notice that the VCOM_getchar() always gives me 0xFF
> if the USB cable is unplugged,

It's obvious from this VCOM_getchar() and fifo_get() implementation.

main_serial.c
#define EOF (-1)

int VCOM_getchar(void)
{
U8 c;

return fifo_get(&rxfifo, &c) ? c : EOF;
}
serial_fifo.c
BOOL fifo_get(fifo_t *fifo, U8 *pc)
{
int next;

// check if FIFO has data
if (fifo->head == fifo->tail) {
return FALSE;
}

next = (fifo->tail + 1) % VCOM_FIFO_SIZE;

*pc = fifo->buf[fifo->tail];
fifo->tail = next;

return TRUE;
}
If you don't want to get EOF (0xFF), check the FIFO status before
reading out the data by VCOM_getchar(), using this kind of subroutine.

BOOL fifo_ready( fifo_t *fifo )
{
return !(fifo->head == fifo->tail);
}

Tsuneo

--- In l..., "bobtransformer" wrote:
> > I suggest you get build 142 from the SVN archive, not the older
> > version on Sourceforge which has a known bug (excessive interrupts
> > and thus load on processor, but otherwise harmless).
> I think I've got this buggy version... Whenever I plug in the
> USB connector to the laptop, everything slows way down.
>
> Is it correct that main_serial.c is the only file that has to
> be changed to get rid of the interrupt flood bug ?????
>
> I have LPCUSB running on IAR EWARM and have it combined with
> RS232 functions for my bootloader software. I noticed that when
> I set up a counter in a main while(1) loop and just output
> the count value through the RS232 that as soon as I plug in that
> cable it slows down about 10 times. I also notice that the
> VCOM_getchar() always gives me 0xFF if the USB cable is unplugged,
> which I hope I might be able to figure out. I'm still gathering some
> good info from the previous threads, but it looks like I have a little
> ways to go yet.
>
> thanks,
> boB
>
> --- In l..., "darkcobrax" wrote:
> >
> > --- In l..., "t_chinzei" wrote:
> > >
> > > Sorry for my intrusion.
> > >
> > > Surely, the VCOM example hides the complicated USB enumeration
> > thingy,
> > > but if you need fast communication, you should know the USB
> > > characteristic under the VCOM implementation.
> >
> > It was a welcome intrusion. That's a great description, and I've
> > saved it to my notes for future reference. It also matches and
> > explains the results of my own stress testing.
> >
> > I used "fast" as a relative term, meaning "faster than UART".
> > Implementing my project over UART is possible, but would require
> > limiting some functions and/or using some tricky data packing. With
> > USB I won't have to worry about such things, since I'll never come
> > close to the max.
> Start a New Thread

Thanks Tsuneo...

I will need to transfer binary data through this scheme so I'm not
sure exactly what to do about the EOF (-1) character...
If it is the only byte transferred, or the 63rd byte then
that's OK.

I also do not need high speed. Something like 19.2K or 38 K baud
is fine.

I have more looking through the code to do.

Thank you for all of your previous and current help on this.

boB
--- In l..., "t_chinzei" wrote:
>
> Hello boB,
>
> > Whenever I plug in the USB connector to the laptop,
> > everything slows way down.
>
> The "the interrupt flood bug" is caused by the NAK interrupt.
> NAK interrupt is indeterminate. When the USB bus is idle, you'll see
> 20-30 IN-NAK within 1msec USB frame. But when the bus is populated,
> very few IN-NAK occur. Maybe Bertrik weren't aware of this NAK
> indeterminacy when he designed the stack. Usually, just SOF interrupt
> is applied for this implementation, as I showed on this post.
> http://tech.groups.yahoo.com/group/lpc2000/message/23334
> > I also notice that the VCOM_getchar() always gives me 0xFF
> > if the USB cable is unplugged,
>
> It's obvious from this VCOM_getchar() and fifo_get() implementation.
>
> main_serial.c
> #define EOF (-1)
>
> int VCOM_getchar(void)
> {
> U8 c;
>
> return fifo_get(&rxfifo, &c) ? c : EOF;
> }
> serial_fifo.c
> BOOL fifo_get(fifo_t *fifo, U8 *pc)
> {
> int next;
>
> // check if FIFO has data
> if (fifo->head == fifo->tail) {
> return FALSE;
> }
>
> next = (fifo->tail + 1) % VCOM_FIFO_SIZE;
>
> *pc = fifo->buf[fifo->tail];
> fifo->tail = next;
>
> return TRUE;
> }
> If you don't want to get EOF (0xFF), check the FIFO status before
> reading out the data by VCOM_getchar(), using this kind of subroutine.
>
> BOOL fifo_ready( fifo_t *fifo )
> {
> return !(fifo->head == fifo->tail);
> }
>
> Tsuneo
>
> --- In l..., "bobtransformer" wrote:
> >
> >
> > > I suggest you get build 142 from the SVN archive, not the older
> > > version on Sourceforge which has a known bug (excessive interrupts
> > > and thus load on processor, but otherwise harmless).
> >
> >
> > I think I've got this buggy version... Whenever I plug in the
> > USB connector to the laptop, everything slows way down.
> >
> > Is it correct that main_serial.c is the only file that has to
> > be changed to get rid of the interrupt flood bug ?????
> >
> > I have LPCUSB running on IAR EWARM and have it combined with
> > RS232 functions for my bootloader software. I noticed that when
> > I set up a counter in a main while(1) loop and just output
> > the count value through the RS232 that as soon as I plug in that
> > cable it slows down about 10 times. I also notice that the
> > VCOM_getchar() always gives me 0xFF if the USB cable is unplugged,
> > which I hope I might be able to figure out. I'm still gathering some
> > good info from the previous threads, but it looks like I have a little
> > ways to go yet.
> >
> > thanks,
> > boB
> >
> >
> >
> >
> >
> > --- In l..., "darkcobrax" wrote:
> > >
> > > --- In l..., "t_chinzei" wrote:
> > > >
> > > > Sorry for my intrusion.
> > > >
> > > > Surely, the VCOM example hides the complicated USB enumeration
> > > thingy,
> > > > but if you need fast communication, you should know the USB
> > > > characteristic under the VCOM implementation.
> > >
> > > It was a welcome intrusion. That's a great description, and I've
> > > saved it to my notes for future reference. It also matches and
> > > explains the results of my own stress testing.
> > >
> > > I used "fast" as a relative term, meaning "faster than UART".
> > > Implementing my project over UART is possible, but would require
> > > limiting some functions and/or using some tricky data packing.
With
> > > USB I won't have to worry about such things, since I'll never come
> > > close to the max.
> > >
> Start a New Thread

boB
It should not be a problem. A received 0xFF byte is different from
an EOF (0xFFFF). VCOM_getchar() returns an int.

Regards
-Bill Knight
R O SoftWare
bobtransformer wrote:
> Thanks Tsuneo...
>
> I will need to transfer binary data through this scheme so I'm not
> sure exactly what to do about the EOF (-1) character...
> If it is the only byte transferred, or the 63rd byte then
> that's OK.
>
> I also do not need high speed. Something like 19.2K or 38 K baud
> is fine.
>
> I have more looking through the code to do.
>
> Thank you for all of your previous and current help on this.
>
> boB
> --- In l..., "t_chinzei" wrote:
>> Hello boB,
>>
>>> Whenever I plug in the USB connector to the laptop,
>>> everything slows way down.
>> The "the interrupt flood bug" is caused by the NAK interrupt.
>> NAK interrupt is indeterminate. When the USB bus is idle, you'll see
>> 20-30 IN-NAK within 1msec USB frame. But when the bus is populated,
>> very few IN-NAK occur. Maybe Bertrik weren't aware of this NAK
>> indeterminacy when he designed the stack. Usually, just SOF interrupt
>> is applied for this implementation, as I showed on this post.
>> http://tech.groups.yahoo.com/group/lpc2000/message/23334
>>> I also notice that the VCOM_getchar() always gives me 0xFF
>>> if the USB cable is unplugged,
>> It's obvious from this VCOM_getchar() and fifo_get() implementation.
>>
>> main_serial.c
>> #define EOF (-1)
>>
>> int VCOM_getchar(void)
>> {
>> U8 c;
>>
>> return fifo_get(&rxfifo, &c) ? c : EOF;
>> }
>> serial_fifo.c
>> BOOL fifo_get(fifo_t *fifo, U8 *pc)
>> {
>> int next;
>>
>> // check if FIFO has data
>> if (fifo->head == fifo->tail) {
>> return FALSE;
>> }
>>
>> next = (fifo->tail + 1) % VCOM_FIFO_SIZE;
>>
>> *pc = fifo->buf[fifo->tail];
>> fifo->tail = next;
>>
>> return TRUE;
>> }
>> If you don't want to get EOF (0xFF), check the FIFO status before
>> reading out the data by VCOM_getchar(), using this kind of subroutine.
>>
>> BOOL fifo_ready( fifo_t *fifo )
>> {
>> return !(fifo->head == fifo->tail);
>> }
>>
>> Tsuneo
>>
>> --- In l..., "bobtransformer" wrote:
>>>
>>>> I suggest you get build 142 from the SVN archive, not the older
>>>> version on Sourceforge which has a known bug (excessive interrupts
>>>> and thus load on processor, but otherwise harmless).
>>>
>>> I think I've got this buggy version... Whenever I plug in the
>>> USB connector to the laptop, everything slows way down.
>>>
>>> Is it correct that main_serial.c is the only file that has to
>>> be changed to get rid of the interrupt flood bug ?????
>>>
>>> I have LPCUSB running on IAR EWARM and have it combined with
>>> RS232 functions for my bootloader software. I noticed that when
>>> I set up a counter in a main while(1) loop and just output
>>> the count value through the RS232 that as soon as I plug in that
>>> cable it slows down about 10 times. I also notice that the
>>> VCOM_getchar() always gives me 0xFF if the USB cable is unplugged,
>>> which I hope I might be able to figure out. I'm still gathering some
>>> good info from the previous threads, but it looks like I have a little
>>> ways to go yet.
>>>
>>> thanks,
>>> boB
>>>
>>>
>>> --- In l..., "darkcobrax" wrote:
>>>> --- In l..., "t_chinzei" wrote:
>>>>> Sorry for my intrusion.
>>>>>
>>>>> Surely, the VCOM example hides the complicated USB enumeration
>>>> thingy,
>>>>> but if you need fast communication, you should know the USB
>>>>> characteristic under the VCOM implementation.
>>>> It was a welcome intrusion. That's a great description, and I've
>>>> saved it to my notes for future reference. It also matches and
>>>> explains the results of my own stress testing.
>>>>
>>>> I used "fast" as a relative term, meaning "faster than UART".
>>>> Implementing my project over UART is possible, but would require
>>>> limiting some functions and/or using some tricky data packing.
> With
>>>> USB I won't have to worry about such things, since I'll never come
>>>> close to the max.
>>>> Start a New Thread