Hi Dave,
Eek. Very expensive.
--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
CrossWorks for MSP430, ARM, AVR and (soon) MAXQ processors
> -----Original Message-----
> From: dave_baker_100 [mailto:dave_baker_100@dave...]
> Sent: 29 June 2005 21:55
> To: lpc2000@lpc2...
> Subject: [lpc2000] Re: LPC214x software availability
>
> Paul,
>
> They are one-off per-product fees. There are no runtime costs.
>
> Dave
>
> --- In lpc2000@lpc2..., "Paul Curtis" <plc@r...> wrote:
> > Hi Dave,
> >
> > > The USB stack I suggested Philips make available for the
> > > LPC2148 would obviously require the PC end (just like
> Silabs offer,
> > > as I mentioned).
> > > I must have been one of the customers to benefit from your
fixes
> :)
> >
> > I would welcome a nice USB stack for the micro, but I have this
> feeling
> > it won't happen. We used the Cygnal stuff when it came out before
> > SiLabs were in the equation. In fact, the USB micro isn't very
> > difficult to program anyway on the bare silicon--there isn't much
of
> a
> > "stack" to speak of, it's more like a small abstraction
layer.
> >
> > > Regarding Micrium, are you aware of the cost of their USB stack ?
> > > $3725 for the embedded end (includes embedded source &
compiled XP
> > > driver) & $5000 for the XP driver source ? Maybe they'll
strike a
> > > deal with Philips but I doubt it'll be cheap...
> >
> > We all know Micrium is expensive for sure. Is this a flat fee or is
> it
> > a per-product or per-design fee? What about runtime, is that free?
> >
> > --
> > Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
> CrossWorks
> > for MSP430, ARM, AVR and now MAXQ processors
> Yahoo! Groups Links
Re: LPC214x software availability
Started by ●June 29, 2005
Reply by ●June 30, 20052005-06-30
> Eek. Very expensive.
Indeed, it would seem the FTDI chip solution is still the best
solution for product runs of up to several hundred total units, or
where time-to-market is critical.
You can buy a lot of FTDI chips and the attendant board space for
the cost of one of those development systems. And the PC and
peripheral side drivers are (or can be) reduced to nothing more
complicated than the serial protocols we came to understand in
simpler times.
Even without the convenience of end points, the FTDI "direct" D2XX
drivers are capable of sustaining many hundreds of kilobytes/second.
The trick is, at the peripheral side let those FTDI internal buffers
fill up a bit before reading a block of data, and don't get bogged
down in interrupt-per-character data handling. Enable the USB
interrupt. When the first USB interrupt hits, disable the USB
interrupt and set up a timer interrupt to occur tens or hundreds of
microseconds later when the buffer is nearly full. When the timer
hits, soak up the buffer all at once, and re-enable the USB
interrupt. It helps speed things along if you arrange the pins so
the FTDI handshake pin states appear in the same data word as the
byte data.
At the PC end, attach the D2XX driver handshake to a thread that
maintains buffers filled and emptied by your Windows application
code. FTDI has good docs on the drivers and some PC example code.
On a gHz+ machine XP often services such threads at over 1mHz!
Or you can just use the serial port driver, which is not quite as
fast as the D2XX driver, but in every other way a piece of cake!
Bill T.
http://www.kupercontrols.com
Indeed, it would seem the FTDI chip solution is still the best
solution for product runs of up to several hundred total units, or
where time-to-market is critical.
You can buy a lot of FTDI chips and the attendant board space for
the cost of one of those development systems. And the PC and
peripheral side drivers are (or can be) reduced to nothing more
complicated than the serial protocols we came to understand in
simpler times.
Even without the convenience of end points, the FTDI "direct" D2XX
drivers are capable of sustaining many hundreds of kilobytes/second.
The trick is, at the peripheral side let those FTDI internal buffers
fill up a bit before reading a block of data, and don't get bogged
down in interrupt-per-character data handling. Enable the USB
interrupt. When the first USB interrupt hits, disable the USB
interrupt and set up a timer interrupt to occur tens or hundreds of
microseconds later when the buffer is nearly full. When the timer
hits, soak up the buffer all at once, and re-enable the USB
interrupt. It helps speed things along if you arrange the pins so
the FTDI handshake pin states appear in the same data word as the
byte data.
At the PC end, attach the D2XX driver handshake to a thread that
maintains buffers filled and emptied by your Windows application
code. FTDI has good docs on the drivers and some PC example code.
On a gHz+ machine XP often services such threads at over 1mHz!
Or you can just use the serial port driver, which is not quite as
fast as the D2XX driver, but in every other way a piece of cake!
Bill T.
http://www.kupercontrols.com
Reply by ●June 30, 20052005-06-30
Hi tonalbuilder2002
FTDI solutions is good, but I have a problem with
FTDI232 chip.
I have DLP-USB232M dlnda solution (sample board) and I
don't result problem with the chiPs (RTS, DTR is
negative, this is no the problem) and problem is I
don't can trasnsfer byte to board. but I received byte
correctly.
FTDI RS232 solution is not easy. I work with GNU and
Linux slackwaere, system finded FTDI chip correctly.
For more informations about my board and my FTDI
solutions look http://geocities.com/kralikbo
btw: yesterday party is over, best, is'nt it ?
bttw: I don't read message completly ;-)
--- tonalbuilder2002 <twentiethwave@twen...>
wrote:
> > Eek. Very expensive.
>
> Indeed, it would seem the FTDI chip solution is
> still the best
> solution for product runs of up to several hundred
> total units, or
> where time-to-market is critical.
>
> You can buy a lot of FTDI chips and the attendant
> board space for
> the cost of one of those development systems. And
> the PC and
> peripheral side drivers are (or can be) reduced to
> nothing more
> complicated than the serial protocols we came to
> understand in
> simpler times.
>
> Even without the convenience of end points, the FTDI
> "direct" D2XX
> drivers are capable of sustaining many hundreds of
> kilobytes/second.
> The trick is, at the peripheral side let those FTDI
> internal buffers
> fill up a bit before reading a block of data, and
> don't get bogged
> down in interrupt-per-character data handling.
> Enable the USB
> interrupt. When the first USB interrupt hits,
> disable the USB
> interrupt and set up a timer interrupt to occur tens
> or hundreds of
> microseconds later when the buffer is nearly full.
> When the timer
> hits, soak up the buffer all at once, and re-enable
> the USB
> interrupt. It helps speed things along if you
> arrange the pins so
> the FTDI handshake pin states appear in the same
> data word as the
> byte data.
>
> At the PC end, attach the D2XX driver handshake to a
> thread that
> maintains buffers filled and emptied by your Windows
> application
> code. FTDI has good docs on the drivers and some PC
> example code.
> On a gHz+ machine XP often services such threads at
> over 1mHz!
>
> Or you can just use the serial port driver, which is
> not quite as
> fast as the D2XX driver, but in every other way a
> piece of cake!
>
> Bill T.
> http://www.kupercontrols.com >
>
Regards / S pozdravom Boris Kralik
http://www.geocities.com/kralikbo/
-------------
___________________________________________________________
How much free photo storage do you get? Store your holiday
snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com
FTDI solutions is good, but I have a problem with
FTDI232 chip.
I have DLP-USB232M dlnda solution (sample board) and I
don't result problem with the chiPs (RTS, DTR is
negative, this is no the problem) and problem is I
don't can trasnsfer byte to board. but I received byte
correctly.
FTDI RS232 solution is not easy. I work with GNU and
Linux slackwaere, system finded FTDI chip correctly.
For more informations about my board and my FTDI
solutions look http://geocities.com/kralikbo
btw: yesterday party is over, best, is'nt it ?
bttw: I don't read message completly ;-)
--- tonalbuilder2002 <twentiethwave@twen...>
wrote:
> > Eek. Very expensive.
>
> Indeed, it would seem the FTDI chip solution is
> still the best
> solution for product runs of up to several hundred
> total units, or
> where time-to-market is critical.
>
> You can buy a lot of FTDI chips and the attendant
> board space for
> the cost of one of those development systems. And
> the PC and
> peripheral side drivers are (or can be) reduced to
> nothing more
> complicated than the serial protocols we came to
> understand in
> simpler times.
>
> Even without the convenience of end points, the FTDI
> "direct" D2XX
> drivers are capable of sustaining many hundreds of
> kilobytes/second.
> The trick is, at the peripheral side let those FTDI
> internal buffers
> fill up a bit before reading a block of data, and
> don't get bogged
> down in interrupt-per-character data handling.
> Enable the USB
> interrupt. When the first USB interrupt hits,
> disable the USB
> interrupt and set up a timer interrupt to occur tens
> or hundreds of
> microseconds later when the buffer is nearly full.
> When the timer
> hits, soak up the buffer all at once, and re-enable
> the USB
> interrupt. It helps speed things along if you
> arrange the pins so
> the FTDI handshake pin states appear in the same
> data word as the
> byte data.
>
> At the PC end, attach the D2XX driver handshake to a
> thread that
> maintains buffers filled and emptied by your Windows
> application
> code. FTDI has good docs on the drivers and some PC
> example code.
> On a gHz+ machine XP often services such threads at
> over 1mHz!
>
> Or you can just use the serial port driver, which is
> not quite as
> fast as the D2XX driver, but in every other way a
> piece of cake!
>
> Bill T.
> http://www.kupercontrols.com >
>
Regards / S pozdravom Boris Kralik
http://www.geocities.com/kralikbo/
-------------
___________________________________________________________
How much free photo storage do you get? Store your holiday
snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com
