Reply by Leon February 16, 20062006-02-16
CBodd wrote:
> Thanks again guys, great suggestions. Looks like many of you have already > faced & conquered this problem (literally, or at least mentally) from the > details in the posts above. > > One thing that might bring a smile or two... when I came in this morning, > there was a printout from the Philips' site with the LP2101/2/3 circled > (especially the '01) with the writing "What about this one?" I guess the > 2101 is about $1.50 or so, ARM based, and has 2 UARTs and 2 SPI buses... > > It's amazing what you can get these days for your $$$. I think we > probably pay close to $5 for the Samsung, maybe it's a bit less, but the > lead time for that part sucks (something like 16 weeks).
I've just got some LPC2103s to play with. Digikey had them in stock and I also got a couple of samples out of Philips. Leon
Reply by Stephen Pelc February 16, 20062006-02-16
On Wed, 15 Feb 2006 19:19:31 -0600, "CBodd" <v2epl3e02@sneakemail.com>
wrote:

>One thing that might bring a smile or two... when I came in this morning, >there was a printout from the Philips' site with the LP2101/2/3 circled >(especially the '01) with the writing "What about this one?" I guess the >2101 is about $1.50 or so, ARM based, and has 2 UARTs and 2 SPI buses...
If you need more than two additional UARTs, these chips are perfectly capable of running bit-banged serial ports - we recently shipped code that uses both on-chip UARTs at 115200 and has two bit-banged 9600 baud MDB ports (9 bit protocol). Not a line of assembler - a 60MHz single-chip ARM is a joy to use. One thing to note is that the Philips Flash memory controller is really good. As far as I can tell, if you really need fast interrupt response, the Philips devices have the edge over the Atmel parts. Stephen -- Stephen Pelc, stephenXXX@mpeforth.com MicroProcessor Engineering Ltd - More Real, Less Time 133 Hill Lane, Southampton SO15 5AF, England tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691 web: http://www.mpeforth.com - free VFX Forth downloads
Reply by CBodd February 15, 20062006-02-15
Thanks again guys, great suggestions.  Looks like many of you have already
faced & conquered this problem (literally, or at least mentally) from the
details in the posts above.

One thing that might bring a smile or two... when I came in this morning,
there was a printout from the Philips' site with the LP2101/2/3 circled
(especially the '01) with the writing "What about this one?"   I guess the
2101 is about $1.50 or so, ARM based, and has 2 UARTs and 2 SPI buses...

It's amazing what you can get these days for your $$$.  I think we
probably pay close to $5 for the Samsung, maybe it's a bit less, but the
lead time for that part sucks (something like 16 weeks).

In my spare time I've been looking at the ARM7 chips from Atmel & Philips
ito replace the S3C3410.  Naturally they all have more speed, lower power,
more peripherals, lower cost.... I guess after doing this for about 15
years I shouldn't be surprised anymore, but I never cease to be amazed.

Oh before I forget -- someone here asked about the time frame -- nominally
it's 2 months for something that's ready to be manufactured, but I'm not
sure how solid that is.

Anyway, thanks again to all posters.  Now I'll begin reading datasheets
from all the suggestions....

Reply by Ulf Samuelsson February 15, 20062006-02-15
>> >> If you add an ATmega162 to the SPI bus you can let it bridge to the >> two UARTs. >> The GSM 07.10 protocol will let you multiplex two UART channels on >> the SPI bus. > > Do you perhaps have a link where I can get details on the GSM 07.20 > protocol. >
Can be downloaded for free after registering. http://www.etsi.org/services_products/freestandard/home.htm
> Since I used an ATMega162 for this exact application, I agree that it > is a good solution. The ATMega162 has absolutely no problem in > handling 2x full duplex channels at 115200 baud, and using the SPI > channel to multiplex the data. > > Regards > Anton Erasmus
-- Best Regards, Ulf Samuelsson ulf@a-t-m-e-l.com This message is intended to be my own personal view and it may or may not be shared by my employer Atmel Nordic AB
Reply by Anton Erasmus February 15, 20062006-02-15
On Wed, 15 Feb 2006 00:51:20 +0100, "Ulf Samuelsson"
<ulf@a-t-m-e-l.com> wrote:

>CBodd wrote: > >> This is a currently-shipping product, based on a Samsung ARM7 chip >> (the nomenclature of the silicon has changed 3x since we've been >> using it in '99 -- something like S3C341x or whatever.... my databook >> is in the lab right now...) >> >> The ARM is running at 20 MHz and is at 80-85% CPU utilization (using >> uC/OS-II, the CPU pct loading is an optional feature that can be >> enabled, i.e. I'm pulling the figure out of my you-know-what) >> > >If you add an ATmega162 to the SPI bus you can let it bridge to the two >UARTs. >The GSM 07.10 protocol will let you multiplex two UART channels on the SPI >bus.
Do you perhaps have a link where I can get details on the GSM 07.20 protocol. Since I used an ATMega162 for this exact application, I agree that it is a good solution. The ATMega162 has absolutely no problem in handling 2x full duplex channels at 115200 baud, and using the SPI channel to multiplex the data. Regards Anton Erasmus
Reply by Leon February 15, 20062006-02-15
When I designed a high-speed comms hub some years ago I used a number
of AT90S2313 MCUs interfaced via SPI to a mid-range PIC. The 2313s had
hardware UARTS and I used bit-banged SPI to communicate with the PIC.
The system works very well.

Leon

Reply by Jim Granville February 15, 20062006-02-15
Donald wrote:
> CBodd wrote: > >> First of all, thanks to *everyone* who replied... lots of very on-point >> and specific suggestions & thoughtful questions. Outstanding & much >> appreciated. >> >> In an attempt to detail my specific problem, I think I neglected to >> give a >> "big picture" view of the project, so hopefully I can fill in some >> details. >> Hopefully I addressed everyone's questions (if not -- I'm sorry, I >> didn't >> neglect anyone or any question intentionally). >> >> This is a currently-shipping product, based on a Samsung ARM7 chip (the >> nomenclature of the silicon has changed 3x since we've been using it in >> '99 -- something like S3C341x or whatever.... my databook is in the lab >> right now...) >> >> The ARM is running at 20 MHz and is at 80-85% CPU utilization (using >> uC/OS-II, the CPU pct loading is an optional feature that can be enabled, >> i.e. I'm pulling the figure out of my you-know-what) >> >> Anyway -- this part will be familiar to many of you -- cost, and secondly >> time to market are paramount here. There are many newer processors out >> there that have several integrated UARTs, etc... but the hit we'd take >> right now on re-doing this legacy board, drivers, etc... for a new >> processor (not to mention the manufacturing steps) would most likely be >> too much. >> >> We have the real estate & power budget to "glue on" the serial >> interfaces, >> but to swap out the processor in the short term has been ruled out (I'm >> often saying to the higher ups, "Do you want to pay know or pay later..." >> but we've all been there in the trenches & know how that goes) >> >> One of our primary customers has added functionality to the device we >> interface to, and requires us to supply two more RS232 ports on our >> product (DB9 connector on our side, RS232 levels coming into the board >> are >> +/- 5V, we just use transistors between the DB9 and the processor instead >> of a true level shifter IC to get 0 and 3.3V at the Samsung). >> >> We need full-duplex for this product. >> >> It's been a while since I did programmable logic, but if necessary that >> route is an option. I was thinking a small uC might be the best route, >> and several of the posts here don't dissuade me. >> >> We have a few unused GPIOs, a SPI bus that is not very heavily used, same >> for the I2C bus, a couple of unused interrupt lines as well. >> >> We have 1.8, 3.3, and 5V supplies, and no problems/issues with current or >> power levels.
Given the 20MHz and 3.3V, that looks ideal for AT89LP2051. Full Buffered SPI, and 1 UART in HW so SW only has to do 1 or 2. This is a 1 cycle core, rated at 20MHz at 3.3V. Comes in TSSOP, ask Atmel for a price on 50K - should be under the nominal $1. This might also fit in their smaller sized LP213/214/216... -jg
Reply by Donald February 15, 20062006-02-15
CBodd wrote:
> First of all, thanks to *everyone* who replied... lots of very on-point > and specific suggestions & thoughtful questions. Outstanding & much > appreciated. > > In an attempt to detail my specific problem, I think I neglected to give a > "big picture" view of the project, so hopefully I can fill in some details. > Hopefully I addressed everyone's questions (if not -- I'm sorry, I didn't > neglect anyone or any question intentionally). > > This is a currently-shipping product, based on a Samsung ARM7 chip (the > nomenclature of the silicon has changed 3x since we've been using it in > '99 -- something like S3C341x or whatever.... my databook is in the lab > right now...) > > The ARM is running at 20 MHz and is at 80-85% CPU utilization (using > uC/OS-II, the CPU pct loading is an optional feature that can be enabled, > i.e. I'm pulling the figure out of my you-know-what) > > Anyway -- this part will be familiar to many of you -- cost, and secondly > time to market are paramount here. There are many newer processors out > there that have several integrated UARTs, etc... but the hit we'd take > right now on re-doing this legacy board, drivers, etc... for a new > processor (not to mention the manufacturing steps) would most likely be > too much. > > We have the real estate & power budget to "glue on" the serial interfaces, > but to swap out the processor in the short term has been ruled out (I'm > often saying to the higher ups, "Do you want to pay know or pay later..." > but we've all been there in the trenches & know how that goes) > > One of our primary customers has added functionality to the device we > interface to, and requires us to supply two more RS232 ports on our > product (DB9 connector on our side, RS232 levels coming into the board are > +/- 5V, we just use transistors between the DB9 and the processor instead > of a true level shifter IC to get 0 and 3.3V at the Samsung). > > We need full-duplex for this product. > > It's been a while since I did programmable logic, but if necessary that > route is an option. I was thinking a small uC might be the best route, > and several of the posts here don't dissuade me. > > We have a few unused GPIOs, a SPI bus that is not very heavily used, same > for the I2C bus, a couple of unused interrupt lines as well. > > We have 1.8, 3.3, and 5V supplies, and no problems/issues with current or > power levels. > > When my boss (one foot in mgmt, one foot in tech) looked for UARTs, he was > shocked at the price per chip, and of course was upset that there wasn't a > "simple" or "basic" UART (we don't need DTR, CTS, RTS, buffers/FIFOs, > etc...) > > The cost margins on this are pretty tight already, and as you can imagine > at large volumes, a $2 difference is pretty significant (we're a small > company, and unfortunately the engineers' time [mine included] is often > considered secondary to the BOM & manufacturing cost.) > > I don't have hard #s but I suspect that a $3.50-$4 vs $1 solution > (assuming that's even possible) has a pretty signficant impact on the > product's profitability. > > The mythical $1 price that I keep alluding to is primarily BOM cost for > the silicon -- we don't need level shifters & we get the DB9s at something > like 2 cents each and my time (NRE) is unfortunately not factored in. > > Hopefully that gives more insight into the product & my situation. > > Thanks again very much -- I'll keep checking back for more responses. And > hopefully others will be able to benefit from this as well. > > P.S. Original title of my post was "Need low-cost serial interface or > "UART" " but it was truncated when posting.... thanks for reading into the > post in spite of the non-specific title! > >
Very interesting. I was kind of wondering if 50K pcs was a real number. Using a single chip cpu with an SPI port, one hardware uart and one high speed timer (for two software uarts) is very feasable. If an engineer ( mine or yours ) can do this for $5K(nre), that would be $0.10 per chip. So a $1.50 chip would add a dime to each. The other side, (your side) would also need to be done. ( another $5k is another dime per chip @ 50K) So. What is the time frame ? Two weeks, two months ?? donald PS: I am _not_ bidding on this. I have enough to do.
Reply by Ulf Samuelsson February 14, 20062006-02-14
CBodd wrote:

> This is a currently-shipping product, based on a Samsung ARM7 chip > (the nomenclature of the silicon has changed 3x since we've been > using it in '99 -- something like S3C341x or whatever.... my databook > is in the lab right now...) > > The ARM is running at 20 MHz and is at 80-85% CPU utilization (using > uC/OS-II, the CPU pct loading is an optional feature that can be > enabled, i.e. I'm pulling the figure out of my you-know-what) >
If you add an ATmega162 to the SPI bus you can let it bridge to the two UARTs. The GSM 07.10 protocol will let you multiplex two UART channels on the SPI bus. -- Best Regards, Ulf Samuelsson
Reply by CBodd February 14, 20062006-02-14
First of all, thanks to *everyone* who replied... lots of very on-point
and specific suggestions & thoughtful questions.  Outstanding & much
appreciated.

In an attempt to detail my specific problem, I think I neglected to give a
"big picture" view of the project, so hopefully I can fill in some details.
 Hopefully I addressed everyone's questions (if not -- I'm sorry, I didn't
neglect anyone or any question intentionally).

This is a currently-shipping product, based on a Samsung ARM7 chip (the
nomenclature of the silicon has changed 3x since we've been using it in
'99 -- something like S3C341x or whatever.... my databook is in the lab
right now...)

The ARM is running at 20 MHz and is at 80-85% CPU utilization (using
uC/OS-II, the CPU pct loading is an optional feature that can be enabled,
i.e. I'm pulling the figure out of my you-know-what)

Anyway -- this part will be familiar to many of you -- cost, and secondly
time to market are paramount here.  There are many newer processors out
there that have several integrated UARTs, etc... but the hit we'd take
right now on re-doing this legacy board, drivers, etc... for a new
processor (not to mention the manufacturing steps) would most likely be
too much.

We have the real estate & power budget to "glue on" the serial interfaces,
but to swap out the processor in the short term has been ruled out (I'm
often saying to the higher ups, "Do you want to pay know or pay later..."
but we've all been there in the trenches & know how that goes)

One of our primary customers has added functionality to the device we
interface to, and requires us to supply two more RS232 ports on our
product (DB9 connector on our side, RS232 levels coming into the board are
+/- 5V, we just use transistors between the DB9 and the processor instead
of a true level shifter IC to get 0 and 3.3V at the Samsung).

We need full-duplex for this product.

It's been a while since I did programmable logic, but if necessary that
route is an option.  I was thinking a small uC might be the best route,
and several of the posts here don't dissuade me.

We have a few unused GPIOs, a SPI bus that is not very heavily used, same
for the I2C bus, a couple of unused interrupt lines as well.

We have 1.8, 3.3, and 5V supplies, and no problems/issues with current or
power levels.

When my boss (one foot in mgmt, one foot in tech) looked for UARTs, he was
shocked at the price per chip, and of course was upset that there wasn't a
"simple" or "basic" UART (we don't need DTR, CTS, RTS, buffers/FIFOs,
etc...)

The cost margins on this are pretty tight already, and as you can imagine
at large volumes, a $2 difference is pretty significant (we're a small
company, and unfortunately the engineers' time [mine included] is often
considered secondary to the BOM & manufacturing cost.)

I don't have hard #s but I suspect that a $3.50-$4 vs $1 solution
(assuming that's even possible) has a pretty signficant impact on the
product's profitability.

The mythical $1 price that I keep alluding to is primarily BOM cost for
the silicon -- we don't need level shifters & we get the DB9s at something
like 2 cents each and my time (NRE) is unfortunately not factored in.

Hopefully that gives more insight into the product & my situation.

Thanks again very much -- I'll keep checking back for more responses.  And
hopefully others will be able to benefit from this as well.

P.S.  Original title of my post was "Need low-cost serial interface or
"UART" " but it was truncated when posting.... thanks for reading into the
post in spite of the non-specific title!