Your favorite protocol for transmitting small files

Text file, < 2k bytes, all printable characters, linefeeds, and returns. No blank lines.

I need to be able to offer the user the ability to download a configuration file to a device, without confusing the user and with reasonable reliability.

I'm thinking I'll just tack a line onto it that starts with some "impossible" characters, then a checksum to end. Then I'll provide that to the user as an ASCII file to download.

Thoughts?

--
Tim Wescott 
Control system and signal processing consulting 
 Click to see the full signature
Reply to
Tim Wescott
Loading thread data ...

If you are talking something like RS232

xmodem

Simple to implement, lots of example code. Proven. Use the version with filename packets and you can have multiple uploads

--
Chisolm 
Republic of Texas
Reply to
Joe Chisolm

(X|Y|Z)modem or Kermit are good old things.

--
                               http://la.buvette.org/photos/communards/
Reply to
Tonton Th

0) Over serial? Just blast it. May need a sentinel & checksum.

1) Pick a TCP port and otherwise "no protocol at all". Might need an inband sentinel to indicate "that's all". If that includes a CRC, then awesome.

2) scp or tftp depending which is more sensible to get & deploy for the target.
--
Les Cargill
Reply to
Les Cargill

Tim hasn't said how big the receiving buffer is so 2K might be too big to receive in one blast unless there's some flow control in place.

Ethernet might not be available on the device in which case you are looking at bringing up PPP (or SLIP, but does anyone still use that ? :-)) over the serial line before bringing up the higher level protocols at which point you might just as well use a serial connection protocol such as Kermit.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP 
Microsoft: Bringing you 1980s technology to a 21st century world
Reply to
Simon Clubley

I second that. Pretty much bullet proof and you can use almost any terminal program for debugging / manually doing stuff.

--
Mikko
Reply to
Mikko OH2HVJ

I would not have considered not having 2k to buffer with.

I haven't not-had 2k since the very early '80s.

If that's the case, then I agree with the rest of the thread.

Right.

I should have said "If you have Ethernet" - so many small processors do these days.

--
Les Cargill
Reply to
Les Cargill

A micro USB connector is eating up a distressing amount of my board space. Just an Ethernet connector, not to mention the PHY stuff, would be worse.

It's not a big board, or a big processor.

--
Tim Wescott 
Wescott Design Services 
 Click to see the full signature
Reply to
Tim Wescott

It occurs to me, maybe the microsdxc approach could let you eliminate that connector as well as the serial flash. You'd do firmware upgrades through the card.

Alternatively, do you know about this?

formatting link

Perhaps you could build your board around the module it uses, including running your application on its processor. It has built-in bluetooth so people could download data directly to their phone wirelessly.

Reply to
Paul Rubin

The microdxc connector, by itself, takes up about three times as much board area as the micro USB connector and the FTDI230X chip. It's definitely a no-go.

All the Bluetooth modules that I've seen are expensive and big. This board has about the same amount of surface area as two quarters and a dime.

--
Tim Wescott 
Control system and signal processing consulting 
 Click to see the full signature
Reply to
Tim Wescott

Tim Wescott wrote: [ ... ]

Nordic Bluetooth chips seem to be available now . I guess antennas and associated matching circuits will need some amount of space no matter what.

Mel.

Reply to
Mel Wilson

I don't know if the rfduino module is too big for your purposes--it is relatively small by most standards. I'm not sure what else is on your board so don't know if the ARM bluetooth processor could replace some of the stuff you currently have.

I've been wanting to take apart a bluetooth earpiece and see what kind of bluetooth hardware it uses. Those things are small and as mass market consumer products they have to be pretty cheap.

Reply to
Paul Rubin

This one is pretty small and not that expensive (define expensive :-) ):

formatting link

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

"It is easier to fight for principles than to live up to them." 
 Click to see the full signature
Reply to
Stef

I would still go with [X,Y,Z]modem. I would think when you are doing a upload or download you dont really need to be multi-tasking. A simple read/write control loop. Maybe some simple command prompt to ask if the user wants to upload the config or down load the data set.

You already have tools that will work on *nix and windows (and I suspect mac and maybe even android). There are numerious uC implementations on the web. Cut/Paste, fix the low level uart routines and be done with it. If you want to get fancy do it on the *nix/windows side. Shell scripts, python,perl, what ever.

Are you using the serial link for firmware upload? Does the uC have a built in loader? You should be able to work around this.

--
Chisolm 
Republic of Texas
Reply to
Joe Chisolm

AFAIK the issue with Bluetooth is that if you get a module, you get certification along with. If you use someone's chip, then you have to certify your board/antenna/etc. That costs $$, and the market for the gizmo is very low volume.

I'm basically doing it for me and a few friends, gratis, and then selling whatever I can afterwards.

--
Tim Wescott 
Wescott Design Services 
 Click to see the full signature
Reply to
Tim Wescott

For that matter, define small. For the board I'm working on, that's huge.

--
Tim Wescott 
Wescott Design Services 
 Click to see the full signature
Reply to
Tim Wescott

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.