Tom Lucas wrote:
> Any idea how much it costs to buy, say 1000, MAC addresses?

For your application, why bother? Use locally assigned addresses (see
http://www.certsoft.com/mac.htm). The easiest way I've found is to pick
a 16 or 24 bit most significant "prefix" that meets the locally
assigned address criteria (I use 16 bits) and then fill in the lower
bits from something like a DS2401 serial number chip. The laptop will
have a universally administrated address so there can't be a conflict
between the two.

"Gene S. Berkowitz" <first.last@comcast.net> wrote in message 
news:MPG.1e6078c745242c1c989734@newsgroups.comcast.net...
> In article <45mmu7F7cmbbU3@news.dfncis.de>, broeker@physik.rwth-
> aachen.de says...
>> Tom Lucas <tNOSPAMlucas@autonospamflamedotcom.nodot> wrote:
>>
>> > I've just spotted that IrDA will work up to 4MBps. The existing
>> > system already has 19.2Kbs IrDA which has worked well. Does anyone
>> > have experience of using such data rates and how reliable it is?
>>
>> IrDA is an optical link.  Meaning you can have problems if a mosquito
>> or the user's hand decides to fly right through your communication.
>> Or some other IrDA device in the room could suddenly want to
>> participate in that interesting discussion it's overhearing.  I'd tend
>> to be wary of such a feeble connection for risky operations.
>
> This is simply not the case.
>
> 1. IrDA is not a pinpoint of light.  It is a fairly tight cone, and
> unless that mosquito or your hand actually COVER COMPLETELY the
> transceiver window, it is highly resistant to blocking.

The user would be holding the dongle up to the system anyway and they have 
already used slow IrDA on this system already so I reckon that should be 
fine.

> 2. IrDA incorporates a link layer protocol that includes automatic
> retries.  If a packet is lost or damaged, it's re-sent, simple as that.
>
> 3. IrDA protocols can and do recognize multiple devices, and will only
> carry out transactions with a specified device when multiple contacts
> are present. Also, IrDA is typically designed for short distance (~1M),
> line of sight use.  This tends to prevent being "overheard", which isn't
> a problem anyway, and is certainly better than any comparable RF
> solution.

I once took my MS RF keyboard to vendor's site and managed to interfere with 
just about every other RF device there so I'm certainly wary of that.

>> As circumstantial evidence, consider that makers of mobile phones and
>> similar gear offering IR links to PCs often strongly recommend using
>> wire instead of IR for firmware updates.
>
> Then I'd have to say their implementation sucks.
>
> I helped develop a portable instrument that relies exclusively on IrDA
> for critical file transfers (logged data) and firmware updates.  Since
> its introduction, the primary support issue has been laptop
> manufacturers who ship their products with IrDA disabled in the BIOS by
> default, NOT failed file transfers.
>
> Our product supports up to 115Kbps links (auto-negotiated by the IrDA
> link management, by the way), but that limit was imposed by the
> available clock to the UART, not IrDA.
>
> I have used 4Mbps IrDA to transfer hundreds of files between a PC and a
> laptop that lacked an ethernet connection; it is extremely reliable.
>

I think my worry was that, although 4Mbps is available, in practical use it 
would negotiate itself down to a lower speed. 

In article <1140248069.765644.89040@z14g2000cwz.googlegroups.com>, 
x86asm@gmail.com says...
> 
> Gene S. Berkowitz wrote:
> > In article <45mmu7F7cmbbU3@news.dfncis.de>, broeker@physik.rwth-
> > aachen.de says...
> > > Tom Lucas <tNOSPAMlucas@autonospamflamedotcom.nodot> wrote:
> > >
> > > > I've just spotted that IrDA will work up to 4MBps. The existing
> > > > system already has 19.2Kbs IrDA which has worked well. Does anyone
> > > > have experience of using such data rates and how reliable it is?
> > >
> > > IrDA is an optical link.  Meaning you can have problems if a mosquito
> > > or the user's hand decides to fly right through your communication.
> > > Or some other IrDA device in the room could suddenly want to
> > > participate in that interesting discussion it's overhearing.  I'd tend
> > > to be wary of such a feeble connection for risky operations.
> >
> > This is simply not the case.
> >
> > 1. IrDA is not a pinpoint of light.  It is a fairly tight cone, and
> > unless that mosquito or your hand actually COVER COMPLETELY the
> > transceiver window, it is highly resistant to blocking.
> >
> > 2. IrDA incorporates a link layer protocol that includes automatic
> > retries.  If a packet is lost or damaged, it's re-sent, simple as that.
> >
> > 3. IrDA protocols can and do recognize multiple devices, and will only
> > carry out transactions with a specified device when multiple contacts
> > are present. Also, IrDA is typically designed for short distance (~1M),
> > line of sight use.  This tends to prevent being "overheard", which isn't
> > a problem anyway, and is certainly better than any comparable RF
> > solution.
> >
> > > As circumstantial evidence, consider that makers of mobile phones and
> > > similar gear offering IR links to PCs often strongly recommend using
> > > wire instead of IR for firmware updates.
> >
> > Then I'd have to say their implementation sucks.
> >
> > I helped develop a portable instrument that relies exclusively on IrDA
> > for critical file transfers (logged data) and firmware updates.  Since
> > its introduction, the primary support issue has been laptop
> > manufacturers who ship their products with IrDA disabled in the BIOS by
> > default, NOT failed file transfers.
> >
> > Our product supports up to 115Kbps links (auto-negotiated by the IrDA
> > link management, by the way), but that limit was imposed by the
> > available clock to the UART, not IrDA.
> >
> > I have used 4Mbps IrDA to transfer hundreds of files between a PC and a
> > laptop that lacked an ethernet connection; it is extremely reliable.
> >
> > --Gene
> 
> Hello Gene,
> 
> I was planning on playing around with IrDA on the PIC MCU's. I was
> wondering what is a good IrDA encoder chip (one that I can hook up
> directly to the USART at 115KBps).
> 
> Thanks

We used an Oxford 16550 clone UART, that has a built in IrDA driver.
We ran the IrDA protocol stack on our microcontroller.

--Gene

On 18 Feb, in article
     <1140292483.550314.275460@z14g2000cwz.googlegroups.com>
     zwsdotcom@gmail.com "larwe" wrote:

>Paul Carpenter wrote:
>
>> Maybe someone could get an OUI and sell blocks of 128 or 1024 as I believe
>> somebody does but I cannot be sure on that.
>
>This has caused bureaucratic trouble in the past. Not something I'd
>want to get into.

Makes you wish that there had been a collection of MAC address that were
non-routeable or usable on serial links like PPP that could have been
allocated to aid development for low budget start ups.

Like non-routeable IP addresses.

-- 
Paul Carpenter          | paul@pcserviceselectronics.co.uk
<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

Paul Carpenter wrote:

> Maybe someone could get an OUI and sell blocks of 128 or 1024 as I believe
> somebody does but I cannot be sure on that.

This has caused bureaucratic trouble in the past. Not something I'd
want to get into.

cs_posting@hotmail.com wrote:

> I'd probably not recommend having the customer remove a flash card and
> put it in a reader attached to their PC, unless that was something done

While I might not recommend it either, depending on the product and
application, I'd want to retain the flexibility to send that urgent
update by email NOW rather than fighting customs and paying a fortune
to get cards sent by rapid overseas delivery methods. Deliberately
designing a system that requires special equipment to generate the
cards is not a wise plan. Serial-lock the updates if necessary.

larwe wrote:
> cs_posting@hotmail.com wrote:
>
> > > Compact Flash/SD card - Simple to program and cheap but requires taking the
> > > back off the system to insert the card
> >
> > Put the card slot on the front panel then.  Customer shouldn't program
> > the card, you should and mail it to them.  Don't use a filesystem, or
> > at least don't use a standard one (use something very simple just
>
> One of the delights of having a unit that is field-upgradable is being
> able to deliver updates electronically _instantly_. Significant amenity
> is lost by doing things the way you describe.

It all depends on the industry and the product.  Sometimes you want to
send them a physical object by overnight delivery rather than mess with
their computer.  Sometimes you don't want them to be able to apply the
same update to multiple units (yes, there are other ways of doing
that), etc.

I'd probably not recommend having the customer remove a flash card and
put it in a reader attached to their PC, unless that was something done
in ordinary use of the unit.  Either I'd hvae them download to the unit
from the customer PC, or I'd send the customer an object to add to the
unit.  In some cases, I'd even considering sending out an 'updater box'
that performs the download (and perhaps conducts some tests) which must
then be sent back.

cs_posting@hotmail.com wrote:

> > Compact Flash/SD card - Simple to program and cheap but requires taking the
> > back off the system to insert the card
>
> Put the card slot on the front panel then.  Customer shouldn't program
> the card, you should and mail it to them.  Don't use a filesystem, or
> at least don't use a standard one (use something very simple just

One of the delights of having a unit that is field-upgradable is being
able to deliver updates electronically _instantly_. Significant amenity
is lost by doing things the way you describe.

Tom Lucas wrote:

> I'm designing a system based around a Sharp 79524 ARM7 part which will be
> required to be occasionally reprogrammed in the field with around 16MB of
> data from a PC.

> Serial - Too slow but nice and simple. Perhaps I've missed a revolution and
> PCs can now handle super high rates but I suspect that 115K is the limit for
> most.

Should take 20 minutes.  That's not too slow for an occasional upgrade
*if* the host application displays a believeable progress indicator,
such as counting minutes until done.  It is too long to sit at a simple
'please wait' screeen with no indication that it's not dead.

> USB - The Sharp has a client controller built in which helps but I've heard
> that getting it all working is a nightmare. Commercial stacks seem to be
> pretty expensive too. Good for plug and play.

That probably is the best option of it's done frequently.  Also with
serial you may need to supply some customers with a USB-to-serial
dongle anyway.  Another option is to build one like the CP2102 ($5 from
digikey) into your product - though that may not go all that much
faster than a serial port.  Or they may - hyperterminal just let me
open a belkin usb-to-serial dongle (different chip) at 921600 baud,
though if it actually works there is a mystery.

> Compact Flash/SD card - Simple to program and cheap but requires taking the
> back off the system to insert the card

Put the card slot on the front panel then.  Customer shouldn't program
the card, you should and mail it to them.  Don't use a filesystem, or
at least don't use a standard one (use something very simple just
capable of steering you around bad blocks).  Program the card in a
linux box and mail it, customer inserts it.  No worry with customer pc
configuration at all.

> JTAG - Perhaps with customized probe? Fairly quick and not too tricky for a
> user to use (pig of an application to write though!) but does give them
> rather too much access to the inner workings of the system.

No way is JTAG faster than serial unless you have a specialized pod
driven by USB or something ($100+)  the classic cheap parallel port
cable is bit-bang serial, wheras an ordinary serial port has hardware
shift registers and hardware buffering.  Note you don't have to give
them jtag access to the processor, you could give them a jtag chain
containing only a serial flash chip where your code resides.

Gene S. Berkowitz wrote:
> In article <45mmu7F7cmbbU3@news.dfncis.de>, broeker@physik.rwth-
> aachen.de says...
> > Tom Lucas <tNOSPAMlucas@autonospamflamedotcom.nodot> wrote:
> >
> > > I've just spotted that IrDA will work up to 4MBps. The existing
> > > system already has 19.2Kbs IrDA which has worked well. Does anyone
> > > have experience of using such data rates and how reliable it is?
> >
> > IrDA is an optical link.  Meaning you can have problems if a mosquito
> > or the user's hand decides to fly right through your communication.
> > Or some other IrDA device in the room could suddenly want to
> > participate in that interesting discussion it's overhearing.  I'd tend
> > to be wary of such a feeble connection for risky operations.
>
> This is simply not the case.
>
> 1. IrDA is not a pinpoint of light.  It is a fairly tight cone, and
> unless that mosquito or your hand actually COVER COMPLETELY the
> transceiver window, it is highly resistant to blocking.
>
> 2. IrDA incorporates a link layer protocol that includes automatic
> retries.  If a packet is lost or damaged, it's re-sent, simple as that.
>
> 3. IrDA protocols can and do recognize multiple devices, and will only
> carry out transactions with a specified device when multiple contacts
> are present. Also, IrDA is typically designed for short distance (~1M),
> line of sight use.  This tends to prevent being "overheard", which isn't
> a problem anyway, and is certainly better than any comparable RF
> solution.
>
> > As circumstantial evidence, consider that makers of mobile phones and
> > similar gear offering IR links to PCs often strongly recommend using
> > wire instead of IR for firmware updates.
>
> Then I'd have to say their implementation sucks.
>
> I helped develop a portable instrument that relies exclusively on IrDA
> for critical file transfers (logged data) and firmware updates.  Since
> its introduction, the primary support issue has been laptop
> manufacturers who ship their products with IrDA disabled in the BIOS by
> default, NOT failed file transfers.
>
> Our product supports up to 115Kbps links (auto-negotiated by the IrDA
> link management, by the way), but that limit was imposed by the
> available clock to the UART, not IrDA.
>
> I have used 4Mbps IrDA to transfer hundreds of files between a PC and a
> laptop that lacked an ethernet connection; it is extremely reliable.
>
> --Gene

Hello Gene,

I was planning on playing around with IrDA on the PIC MCU's. I was
wondering what is a good IrDA encoder chip (one that I can hook up
directly to the USART at 115KBps).

Thanks