Re: Need low-cost
- From: paul$@pcserviceselectronics.co.uk (Paul Carpenter)
- Date: Tue, 14 Feb 2006 10:30:17 +0000 (GMT)
On Monday, in article <4NydnUPsMpJ9rWzeRVn-iQ@xxxxxxxxxxxx>
v2epl3e02@xxxxxxxxxxxxxx "CBodd" wrote:
......
What I am looking for is a simple UART / serial / RS-232 interface (I know
those terms aren't interchangeable), with minimum cost being the goal.
The product sales will be in the 50k unit range annually, and the selling
price won't be very high at all a few 10s of dollars, if not cheaper. The
difference between a $1.50 chip and a $0.50 solution becomes pretty
significant.
So what power rails, level conversion and connectors will have a big
impact as well, probably a bigger impact.
Basically I need to add 2 more serial interfaces and the microcontroller
only has 1 on-chip (i.e. need to go from 1 serial interface to 3). The 2
new serial interfaces (added to a legacy product) will run 19200 baud,
N-8-1.
Which microprocessor are you currently using?
What sort of power is currently available? e.g. 3V or 5V or both?
I don't fancy hardware flow control, BREAK detection, etc... just RX, TX
and GND on the serial side. On the side interfacing to the
microcontroller, almost anything is fine (8-bit parallel, SPI, I2C,
whatever......) -- preferably with an interrupt line running to the micro
saying "I have a byte".
My alternative would be either put a second cheap micro on, or use a
different micro with at least 3 UARTs on already.
The problem is without knowing what your legacy micro is doing, could
make hardware interfacing awkward as in the old Intel/Motorola parallel
timing issues for parallel, what max SPI speed is achievable.
Do you only have 5V available as power (and how much spare)?
No FIFO/buffering is needed, the micro can respond quickly to an
interrupt, but there isn't enough remaining CPU horsepower to implement 2
software UARTs. Issues like framing errors, parity errors, etc... can
just discard the data and not bother the micro.
What micro family are you using already?
Ultimately, I'd like a piece of silicon that says "Got another byte for
you, come get it". On the transmit side, I just want to "write" a byte to
the solution, whatever the interface, and know that the byte is going to be
shifted out at 19200. Higher level protocols will handle dropped bytes in
either direction.
From a silicon standpoint, I don't care if it's one chip with the 2 UARTs,or 2 pieces of duplicate technology (actually 2 single-UART pieces would be
ideal in the sense that another design might only need 1 additional "UART)
If cost is the issue then you need one piece of SMALL silicon to do TWO
UARTs as two pieces of silicon will increase the cost of PCB area on such
a tight budget. As well as how you interface to the legacy product as this
mean some PCB area will be needed for connections to that.
Where are the connectors for the UART I/O going to be and what size will
effect PCB area as well.
So, is the best solution a tiny micro with someone's firmware? A PLD?
Something else?
Extra micro or PLD may well be outside your price budget, and does the
budget include any necessary level converters and connectors?
I'm looking for something ready to go, i.e. I could implement this on any
number of micros, as could most people here, but I need cheap and
ready-to-go.
My first port of call in this situation is the smallest cost increment
is most likely to be using another micro in the same family with more UARTS
built-in.
This also has the less hassle on interfacing at the hardware and software
levels.
Recently looked at a design and the best fit was a mico with 5 UARTs in.
If adding a micro I would consider adding a small H8 or H8S with lots
of internal UARTs in (2 or 3 is common across the families).
Alternatively some of the Rabbit or Z80 or other processors.
I have no idea on the 50K breaks on any of these.
My biggest worries on adding to legacy products are usually
a) how much power is available at what levels
That can be supplied by the legacy system guaranteed
Just hope that no extra filtering on power is required.
b) how do the mechanics work
(placement, volume constraints, other restrictions)
c) hardware and software interfacing
I have seen some nightmares where something simple got screwed up, due to
funny shape boards to fit in areas, or labour intensive to wire in, or the
actual margin of extra power available was marginal at best.
Any solution offered has the problem of insufficient power will scupper it.
All sorts of solutions have different power requirements that may or may
not work in your situation or the application (e.g. drains battery too quick).
I hope I've provided enough information, I've tried to anticipate
questions out of respect for those kind enough to help out.
All the best & thanks again.
--
Paul Carpenter | paul@xxxxxxxxxxxxxxxxxxxxxxxxxxx
<http://www.pcserviceselectronics.co.uk/> PC Services
<http://www.gnuh8.org.uk/> GNU H8 & mailing list info
<http://www.badweb.org.uk/> For those web sites you hate
.
- Prev by Date: Re: Bit-level protocol or text-based protocol? (PC to embedded)
- Next by Date: Re: 3A adaptor for driving LCD
- Previous by thread: Re: Need low-cost serial interface
- Next by thread: Re: Need low-cost
- Index(es):
Relevant Pages
|
