Upload Options

In comp.arch.embedded,
David R Brooks <davebXXX@iinet.net.au> wrote:
>Tom Lucas wrote:
>>>
>> 
>> Will I still have to pay for a MAC address or can I "borrow" one from 
>> somewhere else seeing as it's not going to be on a worldwide network (but 
>> what happens if it is?) 
>> 
>> 
>192.168.0.x are basically pre-allocated for local use: they won't go 
>through a remote router. Something in that range should work.

That is one of the available private _IP_ address ranges. Unfortunately,
there are no such ranges for MAC addresses. Those should be bought or, as
suggested, borrowed from, for example, an old ethernet card that will be
scrapped after the MAC has been read from it.

-- 
Stef    (remove caps, dashes and .invalid from e-mail address to reply by mail)

"Probably the best operating system in the world is the [operating system]
 made for the PDP-11 by Bell Laboratories." - Ted Nelson, October 1977

"Stef" <stef33d@yahooI-N-V-A-L-I-D.com.invalid> wrote in message 
news:6e872$43f5b808$54f63171$13814@publishnet.news-service.com...
> In comp.arch.embedded,
> David R Brooks <davebXXX@iinet.net.au> wrote:
>>Tom Lucas wrote:
>>>>
>>>
>>> Will I still have to pay for a MAC address or can I "borrow" one from
>>> somewhere else seeing as it's not going to be on a worldwide network 
>>> (but
>>> what happens if it is?)
>>>
>>>
>>192.168.0.x are basically pre-allocated for local use: they won't go
>>through a remote router. Something in that range should work.
>
> That is one of the available private _IP_ address ranges. Unfortunately,
> there are no such ranges for MAC addresses. Those should be bought or, as
> suggested, borrowed from, for example, an old ethernet card that will be
> scrapped after the MAC has been read from it.
>
Any idea how much it costs to buy, say 1000, MAC addresses? 

On Friday, in article
     <43f5d267$0$3600$ed2e19e4@ptn-nntp-reader04.plus.net>
     tNOSPAMlucas@autoNOSPAMflameDOTcom.NODOT "Tom Lucas" wrote:

>"Stef" <stef33d@yahooI-N-V-A-L-I-D.com.invalid> wrote in message 
>news:6e872$43f5b808$54f63171$13814@publishnet.news-service.com...
>> In comp.arch.embedded,
>> David R Brooks <davebXXX@iinet.net.au> wrote:
>>>Tom Lucas wrote:
>>>>>
>>>>
>>>> Will I still have to pay for a MAC address or can I "borrow" one from
>>>> somewhere else seeing as it's not going to be on a worldwide network 
>>>> (but
>>>> what happens if it is?)
>>>>
>>>>
>>>192.168.0.x are basically pre-allocated for local use: they won't go
>>>through a remote router. Something in that range should work.
>>
>> That is one of the available private _IP_ address ranges. Unfortunately,
>> there are no such ranges for MAC addresses. Those should be bought or, as
>> suggested, borrowed from, for example, an old ethernet card that will be
>> scrapped after the MAC has been read from it.
>>
>Any idea how much it costs to buy, say 1000, MAC addresses? 

Hmmm first you talk to IEEE to obtain either an OUI or IAB, where OUI
gives 3 octet company identifier and 3 octet you assign (24bit field).
Alternatively you can get an IAB which is a block of approx 4097 addresses.

        OUI is about $1,650
        IAB is about $550

Other charges related to being Public or Private listings.

        http://standards.ieee.org/regauth/index.html

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.

--
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

Tom Lucas wrote:
> "Tom Lucas" <tNOSPAMlucas@autoNOSPAMflameDOTcom.NODOT> wrote in message 
> news:43f49aea$0$6976$ed2619ec@ptn-nntp-reader02.plus.net...
> 
>>Hi all,
>>
>>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. I've been looking into various methods to achieve this an 
>>I was wondering whether the collective have any thoughts? I am not 
>>constrained on power consumption or space and it doesn't have to be 
>>lightning fast. However, it must be reliable and pretty simple for 
>>non-computer oriented users. Cost is not an over-riding factor but it 
>>would be nice to keep it low.
>>
>>My current options appear to be:
> 
> 
> <snip>
> 
> 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 speeds depend on the optics, and silicon/firmware support.

There is also a vFIR spec, at 16MHz, but silicon support is sparse at 
present - but that speed seems a natural match for USB.
-jg

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.

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.

-- 
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

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

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

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.

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.

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.