Searching \ for '[PIC] Cheapest uC with a UART?' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=pic
Search entire site for: 'Cheapest uC with a UART?'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] Cheapest uC with a UART?'
2008\01\01@151957 by Matthew Mucker

flavicon
face
I'm looking for a uC with 8 I/O (including Rx/Tx) and a hardware UART at a
rock bottom price.

The best PIC candidate I could find is the 16F688 which I can get for
$1.28ea in qty 100.

Is there a cheaper part out there? Perhaps a non-Microchip part?  (Of
course, the internal oscillator on the 16F688 does save cost on an external
crystal...)

2008\01\01@154750 by wouter van ooijen

face picon face
> I'm looking for a uC with 8 I/O (including Rx/Tx) and a
> hardware UART at a rock bottom price.

Maybe tell why you need a UART? If you can do without you have far more
options.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu



2008\01\01@155048 by Bob Blick

face picon face
Matthew Mucker wrote:
> Is there a cheaper part out there? Perhaps a non-Microchip part?  (Of
> course, the internal oscillator on the 16F688 does save cost on an external
> crystal...)

Bit-banging is always an alternative of your baud rate is ~4800 or less.

Are you happy with the internal oscillator when using the UART? Once I
almost went that way, but I was only sending one byte at a time, and I
only cared about 6 bits of it so I could use just the first 6. But I
chickened out and added a resonator. Most of my stuff has to work -20 to
+50 C so I tend to be skeptical of RC and internal oscillators.

If you are in charge of both ends maybe you can do something that syncs
to each bit. Then you wouldn't need a uart at all.

Cheerful regards,

Bob

2008\01\01@173132 by Matthew Mucker

flavicon
face
{Quote hidden}

I want to send lots of data at >500 kbaud.  So I don't want to try
bit-banging. I did seriously consider that and the hardware cost savings I'd
get, but at the speeds I need I elected to pay more for the hardware
solution and not have the software headaches.

The sender and receiver will be the same part in the same environment, so
even though uChip only specs the internal oscillator at one temperature, as
long as different parts respond similarly to changes in temperature I should
be okay. (I hope.)

2008\01\01@174705 by Tamas Rudnai

face picon face
Maybe you can use different encoding than NRZ or use a synchron
communication with half duplex mode? That could increase the comm speed a
lot using a cheaper PIC and bit-banging.

Tamas



On Jan 1, 2008 10:30 PM, Matthew Mucker <matthewspamKILLspammucker.net> wrote:

> > {Original Message removed}

2008\01\01@183539 by Bob Blick

face picon face
Hi Matthew,
It seems a false economy to risk bad transmission or added development
time when a $0.35 resonator will insure reliable communications. Maybe
if you were making 100000 quantities and could afford an extra week to
do environmental testing, or development time to do error correction(and
the slower data throughput you would suffer).

But it's your product and you have the better perspective.

I would advise checking through your operating temperature, I quite
often see parts (all sorts of parts) suffer all their error suddenly
when transitioning from one temperature to another, often in strange
ways, not repeatable from part to part, frequently at different
temperatures from each other.

Best wishes on this new year,

Bob


Matthew Mucker wrote:
>> {Original Message removed}

2008\01\01@183625 by Funny NYPD

picon face
Interesting. How stable and accurate if you run a 500K bps serial communication without a crystal or other type of stable oscillator?

Funny N.
New Bedford, MA
http://www.AuElectronics.selfip.com



----- Original Message ----
From: Matthew Mucker <.....matthewKILLspamspam.....mucker.net>
To: Microcontroller discussion list - Public. <EraseMEpiclistspam_OUTspamTakeThisOuTmit.edu>
Sent: Tuesday, January 1, 2008 5:30:43 PM
Subject: RE: [PIC] Cheapest uC with a UART?

> {Original Message removed}

2008\01\01@191316 by Mike Harrison

flavicon
face
On Tue, 01 Jan 2008 16:30:43 -0600, you wrote:

{Quote hidden}

Bear in mind that UARTS usually need a 16xbaudrate  clock, so internal oscs are  
less likely to be useful at the high end.

Cypress do some 8-pin psoc parts with HW UART - no idea how cost compares tough.
ATMEGA48 is very good value peripheral-wise.




2008\01\01@214320 by Funny NYPD

picon face
true. But on a 20Mhz crystal, you should have no issue running UART on 115.2K.

Funny N.
New Bedford, MA
http://www.AuElectronics.selfip.com



----- Original Message ----
From: Mike Harrison <KILLspammikeKILLspamspamwhitewing.co.uk>
To: Microcontroller discussion list - Public. <RemoveMEpiclistTakeThisOuTspammit.edu>
Sent: Tuesday, January 1, 2008 7:24:51 PM
Subject: Re: [PIC] Cheapest uC with a UART?

On Tue, 01 Jan 2008 16:30:43 -0600, you wrote:

>> {Original Message removed}

2008\01\01@224202 by Matthew Mucker

flavicon
face
Bob,

Thank you for your advice. It's certainly something for me to keep in mind.
My application is going to be outdoors at Christmas time, so I do have a
wide (say, -10C to 30C) temperature range in which the devices will operate.
On the other hand, figure 14-2 in the PIC16F688 datasheet specifies the
HFINTOSC as +/-5% over the device's entire temperature range, and +/-2% over
most of the temperature range in which my device is likely to be operating.

Of course, should I find that I'm not getting the required accuracy with the
internal clock, it's always possible to add an external clock.

However, my original question remains: is there a cheaper alternative that
anyone's aware of? :)  I don't think I'm willing to put in the NRE to do bit
banging at the data rates I'm hoping to achieve.


> {Original Message removed}

2008\01\01@232926 by Bob Blick

face picon face
Hi Matthew,

Can you use SPI to communicate between the chips? You can get faster
data rates and it's synchronous, and if you can find a part with an SPI
peripheral but no UART it's bound to be cheaper.

Cheers,

Bob

Matthew Mucker wrote:
{Quote hidden}

>> {Original Message removed}

2008\01\02@023933 by William \Chops\ Westfield

face picon face

On Jan 1, 2008, at 12:19 PM, Matthew Mucker wrote:

> I'm looking for a uC with 8 I/O (including Rx/Tx) and a hardware  
> UART at a
> rock bottom price.
>
> The best PIC candidate I could find is the 16F688 which I can get for
> $1.28ea in qty 100.

Freescale MC9S08QG4 at $1.10 (q100, digikey) ?  It looks like you  
need the 16pin package to use the uart functions (rats.)

2008\01\02@030321 by Forrest W Christian

flavicon
face
Matthew Mucker wrote:
> I don't think I'm willing to put in the NRE to do bit
> banging at the data rates I'm hoping to achieve.

You implied that a PIC was going to be both sending and receiving....

If that is the case, then async serial may not be the best option at
those rates...   500kb/s is very fast, and likely won't go that far
without bit errors.

Perhaps an idea of the distances and real bitrate requirements, and if
there is any real reason why 500kb/s is needed?

-forrest

2008\01\02@052102 by Mike Harrison

flavicon
face
On Tue, 01 Jan 2008 21:41:01 -0600, you wrote:

>Bob,
>
>Thank you for your advice. It's certainly something for me to keep in mind.
>My application is going to be outdoors at Christmas time, so I do have a
>wide (say, -10C to 30C) temperature range in which the devices will operate.
>On the other hand, figure 14-2 in the PIC16F688 datasheet specifies the
>HFINTOSC as +/-5% over the device's entire temperature range, and +/-2% over
>most of the temperature range in which my device is likely to be operating.

Remember you need to account for the error at both ends. 2% at each end is possibly getting marginal
- especially at high rates where you may have slew-rate issues adding to the error budget.
2% is fine where you know that the other end is accurate.

Another important issue that is not apparent from the datasheet is clock jitter - I've seen PIC
INTRC clocks with significant jitter - I suspect the % error quoted in the datasheet is a long-term
avarage figure, and the peak-to-peak jitter may be significantly higher, especially of there is
noise on the supply which could frequency-modulate the clock.  At higher rates, this will be more of
an issue as fewer clocks will be avaraged per bit


2008\01\02@083533 by Bob Axtell

face picon face
Matthew Mucker wrote:
{Quote hidden}

They won't, sorry. I've been very disappointed with the internal
oscillator.

--Bob A

2008\01\02@084821 by Bob Axtell

face picon face
Mike Harrison wrote:
{Quote hidden}

I did a DMX512 Theatrical Controller at 250Kb years ago with PIC16C73 at
20M, so 500Kb should be possible
with a 40M PIC. Not much loop time, though...

--Bob

2008\01\02@092345 by Bob Axtell

face picon face
Matthew Mucker wrote:
> Bob,
>
> Thank you for your advice. It's certainly something for me to keep in mind.
> My application is going to be outdoors at Christmas time, so I do have a
> wide (say, -10C to 30C) temperature range in which the devices will operate.
> On the other hand, figure 14-2 in the PIC16F688 datasheet specifies the
> HFINTOSC as +/-5% over the device's entire temperature range, and +/-2% over
> most of the temperature range in which my device is likely to be operating.
>  
+/- 5% means a 10% RANGE. RS232 normally can't handle an error larger
than 7%.

This spec is horse manure, trust me. I have expended MANY hours on
trying this. It simply cannot be
guaranteed. It works great for ONE or TWO devices, but in production it
will become a humbling
experience, and your client will be very angry... at YOU.
> Of course, should I find that I'm not getting the required accuracy with the
> internal clock, it's always possible to add an external clock.
>
> However, my original question remains: is there a cheaper alternative that
> anyone's aware of? :)  I don't think I'm willing to put in the NRE to do bit
> banging at the data rates I'm hoping to achieve.
>
>  
You can't bit-bang at 500KB; gotta have a UART. If I recall, I only had
20 instructions between
bytes at 250Kb w/ 20M.

A ceramic resonator with built-in caps can be bought for $USD.25 all
over the place.
This will keep it to a 2-3% range or better always.

You will discover that that spec is an AVERAGE, and the RC oscillator
internally wobbles, i.e.
going slow then fast, so it will NOT be usable at 500Kb for sure.

You need to search the PICLIST archives, there is a LOT of text on this
subject.


--Bob

2008\01\02@100257 by Lamebert

flavicon
face
On Wed, 02 Jan 2008 06:34:53 -0700, you wrote:
 
>They won't, sorry. I've been very disappointed with the internal
>oscillator.

I happen to have a 16F785 lashed up on stripboard on the bench at the
moment. It is driving a boost regulator switching around 200mA so it isn't
a 'quiet' environment.

The clock is initially 0.32% low on a 2.5v supply. It changes by 0.06%
between 2.2v and 3.2v supply.

It changes by 2% between ambient (about 21C) and too hot to touch (about
100C).

The clock doesn't come out so I can't look at it but peak to peak jitter on
a 4kHz PWM output is 140ns.

I was quite impressed (but it is only a sample of one).

2008\01\02@103629 by Bob Axtell

face picon face
Lamebert wrote:
{Quote hidden}

I'm impressed, too. Isn't it amazing how the prototype always works
fine, but production doesn't?

--Bob

2008\01\02@105438 by Mike Harrison

flavicon
face
On Wed, 02 Jan 2008 15:02:21 +0000, you wrote:

>On Wed, 02 Jan 2008 06:34:53 -0700, you wrote:
>  
>>They won't, sorry. I've been very disappointed with the internal
>>oscillator.
>
>I happen to have a 16F785 lashed up on stripboard on the bench at the
>moment. It is driving a boost regulator switching around 200mA so it isn't
>a 'quiet' environment.
>
>The clock is initially 0.32% low on a 2.5v supply. It changes by 0.06%
>between 2.2v and 3.2v supply.
>
>It changes by 2% between ambient (about 21C) and too hot to touch (about
>100C).
>
>The clock doesn't come out so I can't look at it but peak to peak jitter on
>a 4kHz PWM output is 140ns.

The problem is that without looking at the actual clock, you don't know how that jitter is
distributed over those  2000 clock cycles.....

2008\01\02@111520 by David VanHorn

picon face
> Perhaps an idea of the distances and real bitrate requirements, and if
> there is any real reason why 500kb/s is needed?


FEW if any 232 drivers will run that fast, and they introduce their
own distortion to the mix.  I hope whatever is going on here, does not
involve any MAX232 variants.

SPI makes a lot more sense to me, with what limited info we've been given.

2008\01\02@112253 by John Chung

picon face
Thanks for the input Bob. I was always tempted with
using internal OSC for sync. communication like UART.
I would now just keep it the last option for
production
wise. I do wonder in what condition could I use it for
production at all......

Thanks,
John Chung


--- Bob Axtell <EraseMEengineerspamcotse.net> wrote:

{Quote hidden}

> --

2008\01\02@112312 by Matt Pobursky

flavicon
face
On Wed, 02 Jan 2008 15:02:21 +0000, Lamebert wrote:
{Quote hidden}

So you're the guy that got the "golden chip" Microchip based all their
specs on? ;-)

Seriously though, I'd bet a lot of money that if you tried a few 1000 chips
over several different production batches the results would not be so nice.

Matt Pobursky
Maximum Performance Systems

2008\01\02@112927 by Matt Pobursky

flavicon
face
On Wed, 02 Jan 2008 08:35:33 -0700, Bob Axtell wrote:
> I'm impressed, too. Isn't it amazing how the prototype always works fine,
> but production doesn't?

In my first job out of school I worked with a great engineer who had lots
of "real world" experience. One time, after sweating for long hours getting
a prototype running I proudly showed it to him and he told me "You can get
anything running once on the bench"... ;-)

It puzzled me a bit at first (being a newbie engineer) -- I thought the
design was "done"! But I soon learned there was a big difference between
getting it working once in a prototype and having something that's really
ready for the big bad nasty real world.

That is, in my opinion, the biggest difference between engineering/product
development and a hobby.

Matt Pobursky
Maximum Performance Systems


2008\01\02@113004 by Bob Axtell

face picon face
David VanHorn wrote:
>> Perhaps an idea of the distances and real bitrate requirements, and if
>> there is any real reason why 500kb/s is needed?
>>    
>
>
> FEW if any 232 drivers will run that fast, and they introduce their
> own distortion to the mix.  I hope whatever is going on here, does not
> involve any MAX232 variants.
>
>  
Yes, 115kb is the fastest those chips can handle.

The DMX512 Theatrical Lighting standard uses RS422 drivers and receivers
at 250Kb.
> SPI makes a lot more sense to me, with what limited info we've been given.
>  

Agreed.

--Bob

2008\01\02@114211 by David VanHorn

picon face
> > I was quite impressed (but it is only a sample of one).
>
> So you're the guy that got the "golden chip" Microchip based all their
> specs on? ;-)
>
> Seriously though, I'd bet a lot of money that if you tried a few 1000 chips
> over several different production batches the results would not be so nice.
>
> Matt Pobursky
> Maximum Performance Systems


VBG..   Sample of one.

Yeah, BTDT..  PHD EE did a design that involved driving a few chips
from a uP's clock oscillator output, except the spec sheet didn't give
any hint that it was designed to drive an external load... Public
highschool educated me raises the question, and is told to mind his
business, besides all 10 prototypes work just fine.  Guess who gets
the call on christmas eve, to hop a flight to Taiwan, because the
production line is shut down due to more than half the systems failing
to start up...

BTDT, it sucked.

2008\01\02@115452 by Bob Axtell

face picon face
David VanHorn wrote:
{Quote hidden}

Happens all the time, folks.

--Bob

2008\01\02@115801 by Matthew Mucker

flavicon
face
I'm planning RS485. Distance would be measured in tens of meters.

-----Original Message-----
From: RemoveMEpiclist-bouncesEraseMEspamEraseMEmit.edu [RemoveMEpiclist-bouncesspam_OUTspamKILLspammit.edu] On Behalf Of
David VanHorn
Sent: Wednesday, January 02, 2008 10:15 AM
To: Microcontroller discussion list - Public.
Subject: Re: [PIC] Cheapest uC with a UART?

> Perhaps an idea of the distances and real bitrate requirements, and if
> there is any real reason why 500kb/s is needed?


FEW if any 232 drivers will run that fast, and they introduce their
own distortion to the mix.  I hope whatever is going on here, does not
involve any MAX232 variants.

SPI makes a lot more sense to me, with what limited info we've been given.

2008\01\02@120459 by Bob Axtell

face picon face
Matthew Mucker wrote:
> I'm planning RS485. Distance would be measured in tens of meters.
>
>  
makes sense.

--Bob

2008\01\02@131103 by Dwayne Reid

flavicon
face
How far does the data have to travel?  Does it **REALLY** have to be 500K bps?

You mentioned Christmas - is this for outdoor lighting?

FWIW - we do outdoor lighting controllers (little 4 ch & 8 ch units)
that often are synchronized to each other.  Each 4 channel block uses
a 12F675 that can listen to a fiber optic receiver & AC zero-crossing
and drives 4 triacs.  All of these units are using the PIC's internal
RC oscillator.

Because each 4 channel block has some intelligence, we send
higher-level commands via asynchronous comms - just a few bytes at a
fairly low data rate.

Operates reliably from -40 through +50.

But: we cheat.

Many of these units (not all) have code that phase-locks TMR0 to the
incoming AC zero-crossing.  We need the AC zero-crossing signal
anyway - so we also use it to keep the serial comms sample rate accurate.

None of this would matter except that we can tolerate a low
communications data rate.  Would not work if we needed fast communications.

Perhaps something to consider.

dwayne


At 03:30 PM 1/1/2008, Matthew Mucker wrote:

{Quote hidden}

--
Dwayne Reid   <RemoveMEdwaynerTakeThisOuTspamspamplanet.eon.net>
Trinity Electronics Systems Ltd    Edmonton, AB, CANADA
(780) 489-3199 voice          (780) 487-6397 fax
http://www.trinity-electronics.com
Custom Electronics Design and Manufacturing

2008\01\02@133113 by Matthew Mucker

flavicon
face
>>They won't, sorry. I've been very disappointed with the internal
>>oscillator.
>
>I happen to have a 16F785 lashed up on stripboard on the bench at the
>moment. It is driving a boost regulator switching around 200mA so it isn't
>a 'quiet' environment.
>
>The clock is initially 0.32% low on a 2.5v supply. It changes by 0.06%
>between 2.2v and 3.2v supply.
>
>It changes by 2% between ambient (about 21C) and too hot to touch (about
>100C).
>
>The clock doesn't come out so I can't look at it but peak to peak jitter on
>a 4kHz PWM output is 140ns.

>The problem is that without looking at the actual clock, you don't know how
that jitter is
>distributed over those  2000 clock cycles.....


Actually, the clock does come out, so you can look at it, if I'm reading the
datasheet correctly. Setting the clock configuration bits to INTOSC outputs
Fosc/4 on the RA4 pin on the 16F785. (Section 3.1 of the datasheet.)

2008\01\02@134639 by Matthew Mucker

flavicon
face
Yep, it's a Christmas lights controller.  And yes, the zero-crossing
detection will be sent to the box as well.  I'm planning on a 4 channel
board but want to be able to daisy chain lots of boards (the current goal is
128 boards for 512 channels on the bus).

512 channels * 100 channel commands/sec * 10 bits/channel command = 512kbps

Now, granted... 100 commands/sec is ludicrous (and pointless at 60Hz line
voltage), but I figure it's easier to relax the requirements later in the
project than find I didn't design in enough headroom from the start.

Besides... I've now got an electronics project, I've got time before I need
to have it done, I'm a happy camper. :)

{Original Message removed}

2008\01\02@140833 by wouter van ooijen

face picon face
> I'm planning RS485. Distance would be measured in tens of meters.

So you are in control of both sides? Use a simple not too
timing-sensitive protocol, I once did so with 1/3 high,  2/3 low for a
one, 2/3-1/3 for a low. If you measure high and low and compare this is
very resistant to slow clock variations, and not difficult to code. The
customer used it on a grid of 100's of slaved PICs. The protocol
included uploading new firmware, and addressing based on position within
a chain. Used on HC chips as buffers.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu



2008\01\02@142111 by Dario Greggio

face picon face
wouter van ooijen wrote:

>[...]and addressing based on position within
> a chain. Used on HC chips as buffers.

Hey Wouter, how do you do this?


--
Ciao, Dario

2008\01\02@143528 by wouter van ooijen

face picon face
> 512 channels * 100 channel commands/sec * 10 bits/channel
> command = 512kbps

How would you squeeze a channel command in 10 bits? Unless you plan a
DMX type of protocol, where each cannel is one byte in a single big
message.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu



2008\01\02@150930 by Matthew Mucker

flavicon
face
That's exactly the plan.  I'm choosing brute force over elegance.

-----Original Message-----
From: EraseMEpiclist-bouncesspamspamspamBeGonemit.edu [RemoveMEpiclist-bouncesKILLspamspammit.edu] On Behalf Of
wouter van ooijen
Sent: Wednesday, January 02, 2008 1:35 PM
To: 'Microcontroller discussion list - Public.'
Subject: RE: [PIC] Cheapest uC with a UART?

> 512 channels * 100 channel commands/sec * 10 bits/channel
> command = 512kbps

How would you squeeze a channel command in 10 bits? Unless you plan a
DMX type of protocol, where each cannel is one byte in a single big
message.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu



2008\01\02@152253 by wouter van ooijen

face picon face
> >[...]and addressing based on position within
> > a chain. Used on HC chips as buffers.
>
> Hey Wouter, how do you do this?

The application was a greenhouse with PICs at roughly 1 meter grid
points, so no long distances between nodes. Just a schmit-trigger HC
buffer was enough. Each node receives the signal, buffered it, and feeds
it to the next.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu



2008\01\02@153958 by Dario Greggio

face picon face
wouter van ooijen wrote:

>>>[...]and addressing based on position within
>>>a chain. Used on HC chips as buffers.
>>
>>Hey Wouter, how do you do this?
>
> The application was a greenhouse with PICs at roughly 1 meter grid
> points, so no long distances between nodes. Just a schmit-trigger HC
> buffer was enough. Each node receives the signal, buffered it, and feeds
> it to the next.

I see, thank you: but how does this lead to addressing? The first node
that received is address "1", the next is "2" ... and every node does
forward packets which don't match to its own address?

--
Ciao, Dario

2008\01\02@160715 by wouter van ooijen

face picon face
> > The application was a greenhouse with PICs at roughly 1 meter grid
> > points, so no long distances between nodes. Just a
> schmit-trigger HC
> > buffer was enough. Each node receives the signal, buffered it, and
> > feeds it to the next.
>
> I see, thank you: but how does this lead to addressing? The
> first node
> that received is address "1", the next is "2" ... and every node does
> forward packets which don't match to its own address?

incoming signal - buffer -=- resistor - buffer -=- outgoing signal

the PIC connects to the = places. it can receive the signal, or block it
or not, or even send something of its own choice to the next PIC (I did
not use that). after power up there was an 'address resolution phase'
where every PIC got its address, first one first, after it received its
address it unblocked comm to the next and kept its assigned address.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu



2008\01\02@164841 by Dario Greggio

face picon face
wouter van ooijen wrote:

> incoming signal - buffer -=- resistor - buffer -=- outgoing signal
>
> the PIC connects to the = places. it can receive the signal, or block it
> [...]

Thank you Wouter, I get it now.
Sometimes I wonder if one similar method could be used when all of the
modules are connected in parallel - i.e. no enter/exit...
Based on line delays, attenuation... or whatever.

--
Ciao, Dario

2008\01\02@172515 by Tamas Rudnai

face picon face
It's very similar to the token passing mechanism in the token ring networks,
isn't it? (Except there is no ring, only a straight line (or 'incoming' and
'outcoming' ends up in the very same server/master?)

Tamas



On Jan 2, 2008 9:05 PM, wouter van ooijen <wouterSTOPspamspamspam_OUTvoti.nl> wrote:

{Quote hidden}

> -

2008\01\02@174632 by alan smith

picon face
yeah....convince the client that its normal to spin a board at least once....they just don't understand its realllllly hard to get 100% clean the first time on a big design.

Bob Axtell <spamBeGoneengineerSTOPspamspamEraseMEcotse.net> wrote:  David VanHorn wrote:
{Quote hidden}

Happens all the time, folks.

--Bob

2008\01\02@181116 by alan smith

picon face
TDM with slots dedicated to particular ports

Matthew Mucker <KILLspammatthewspamBeGonespammucker.net> wrote:  That's exactly the plan. I'm choosing brute force over elegance.

{Original Message removed}

2008\01\02@225435 by Forrest Christian

flavicon
face
Matthew Mucker wrote:
> Yep, it's a Christmas lights controller.  And yes, the zero-crossing
> detection will be sent to the box as well.  I'm planning on a 4 channel
> board but want to be able to daisy chain lots of boards (the current goal is
> 128 boards for 512 channels on the bus).
>  
Is there a reason why you aren't simply trying to emulate DMX512?

http://www.dmx512-online.com

-forrest

2008\01\02@225903 by Forrest Christian

flavicon
face
Oh, and sample pic code can be found by googling "DMX512 pic"

Forrest Christian wrote:
> Matthew Mucker wrote:
>> Yep, it's a Christmas lights controller.  And yes, the zero-crossing
>> detection will be sent to the box as well.  I'm planning on a 4 channel
>> board but want to be able to daisy chain lots of boards (the current
>> goal is
>> 128 boards for 512 channels on the bus).  
> Is there a reason why you aren't simply trying to emulate DMX512?
>
> http://www.dmx512-online.com
>
> -forrest
>

2008\01\03@002647 by Mohit Mahajan (Lists)

picon face
And Microchip has a good AN on DMX512 - AN1076, together with source code.

--
Mohit.

Forrest Christian wrote:
{Quote hidden}

2008\01\03@010318 by Matthew Mucker

flavicon
face
Yes. I'm attempting to emulate another protocol used by the do-it-yourself
Christmas lights community.

But using DMX512 is also a possibility.

> {Original Message removed}

2008\01\03@014418 by wouter van ooijen

face picon face
> It's very similar to the token passing mechanism in the token
> ring networks, isn't it?

I am not familiar with the lowest level of TR, but IIRC it works
differently.

Also I used this scheme only for address resolution, after that it is
more like a head-end topology.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu



2008\01\03@023755 by KPL

picon face
>
> incoming signal - buffer -=- resistor - buffer -=- outgoing signal
>
> the PIC connects to the = places. it can receive the signal, or block it
> or not, or even send something of its own choice to the next PIC (I did
> not use that). after power up there was an 'address resolution phase'
> where every PIC got its address, first one first, after it received its
> address it unblocked comm to the next and kept its assigned address.
>

Not completely clear to me - what happens if one of the controllers in
the middle of the chain dies/hangs/etc?
Actually I'm thinking about the same application - greenhouse
controller network, just not for commercial application.

--
KPL

2008\01\03@032819 by wouter van ooijen

face picon face
> Not completely clear to me - what happens if one of the
> controllers in the middle of the chain dies/hangs/etc?
> Actually I'm thinking about the same application - greenhouse
> controller network, just not for commercial application.

The nodes were (probably still are) connected in a chain. Each chain has
a 'head end' controller. This head end controller simply switches the
power off and back on to get all node controllers in their reset state.
We used 16F819's, which were at that time the cheapest PICs with
self-write capability (update firmware) and a protected part in the
flash (for the bootloader). The head-end controllers were also connected
in a chain, this chain was connected to the PC.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu



2008\01\03@094709 by Bob Axtell

face picon face
KPL wrote:
>> incoming signal - buffer -=- resistor - buffer -=- outgoing signal
>>
>> the PIC connects to the = places. it can receive the signal, or block it
>> or not, or even send something of its own choice to the next PIC (I did
>> not use that). after power up there was an 'address resolution phase'
>> where every PIC got its address, first one first, after it received its
>> address it unblocked comm to the next and kept its assigned address.
>>
>>    
>
> Not completely clear to me - what happens if one of the controllers in
> the middle of the chain dies/hangs/etc?
> Actually I'm thinking about the same application - greenhouse
> controller network, just not for commercial application.
>
>  
I found that Microchip's 9-bit addressing scheme is a great way to
handle addressing without too much overhead.
You send the first byte in 9-bit mode as the DESTINATION ADDRESS of the
intended recipient. All the
units on the bus pick up the address byte. If the address matches, the
rest of the traffic is then extracted at 8-bit
mode, which is unreadable in 9-bit mode. Only the intended recipient
grabs the bus for a reply. That drops 90+%
of the work needed for serial communication.

I used it for casino CAT3 duplex networks (a single pair at RS422). At
that time, only 64 stations could be bussed, but
newer devices will handle up to 256.  Usually, one address  (either
h'00' or h'FF') is reserved as a "broadcast"
address, which is listened to by ALL stations (but never responded to);
but I used 00 as broadcast and FF as a
special address that meant "for any unit not assigned an address yet";
to simplify adding and addressing a new unit
just placed on the bus (you must think carefully about how procedures
will be done). We also had a tiny beeper
on each unit that allowed us to easily identify each address when
installing the network.

On standard CAT3 (telephone pairs) we could communicate anywhere within
a casino at 19.2kb with 1% or less repeated
packets. The purpose was player card tracking, a very early version.

--Bob


--Bob A

More... (looser matching)
- Last day of these posts
- In 2008 , 2009 only
- Today
- New search...