Your favorite protocol for transmitting big files

Yes it can be done, e.g. emulate a flash drive. I have done it.

I did my first (and so far only) USB on a NXP LPC2478, was not as bad as I thought. Found a "lpcusb" project, got it compiling and linking with my application (just the bootloader actually). Then I adapted the "Block device" example to emulate a USB flash disk. So when you plug my board into a PC, it looks like a (small) USB flash drive, no FTDI drivers, no drivers at all. Just copy the firmware/data files onto it. The PC handles all the complicated stuff during emulation, you just need to read/write a 512 byte whose block number is n.

But when you want to read/write the file subsequently with your own firmware, you will need to use someones FAT32 layer or else hack up a minimal one like I did.

Writing is a bit slow without external DRAM for a cache like I had, but it should work fine, my first version read/wrote blocks straight to flash.

Kind of a learning curve doing it but really nice to be able to just tell a customer to plug a USB cable into the board and have the files come straight up on his PC.

You can even have e.g. a help PDF on there :)

There are some low-end ARM USB microcontrollers that are crystal-less, must sync with the USB clock I guess. ST do some, others too I expect.

--

John Devereux
Reply to
John Devereux
Loading thread data ...

Looks like it was FAT12 actually, since emulated device size so small (few hundred K i.e. the internal micro flash). So that is why it was feasible to hack up quickly.

--

John Devereux
Reply to
John Devereux

I have three things I need to do:

- Let the user talk to the board, to choose programs and to set parameters (timings, throttle settings, etc.)

- Download small (~2k) program files to the board, to specify more complicated behaviors (the idea is that average users diddle settings, while advanced users may write programs).

- Download large (up to 2MB) data files from the board.

I can see how a block storage device meets the second and third items on the list, but not the first.

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

The first is just a parameter file on the stroage device. You write that file to the storage card before the flight with the PC.

IOW, something like:

[segment1] throttle=100% heading=180 time=20s [segment2] throttle=50% heading=90 time=30s ...
Reply to
Robert Wessel

You could use USB networking for all of the above. But, if this is a commercial product aimed at RC hobbyists, it might be much more attractive with wireless communication (wifi or blueototh), and a smartphone app for control and data collection. Who wants to lug a laptop around when they're flying their plane?

I also wonder about the accuracy of serial port timing if all you have is an RC oscillator on the board. Maybe you could consider an external dongle that the user would plug into your board to collect data. That would give you more flexibility for minimizing the stuff on the board. E.g. it could use clocked serial on the board side, and wireless or usb out the other end.

Reply to
Paul Rubin

No, not without an application on the PC (writing a config file say).

I think you can do a multi-device USB thing, where it appears as two types of device at the same time. Don't know anything about that though.

--

John Devereux
Reply to
John Devereux

X-Modem CRC. Been using it for 18 years, handshaking is implicit in the protocol, Everything in the world supports it.

Be sure to implement CRC. Checksum sucks.

Reply to
Jim Stewart

It's for control line flyers, which means that the market (not to mention the board) is just too damned small for any sort of built-in radio.

Most smart phones can be USB hosts these days. I don't know if they'll do USB networking when they're USB hosts, but if they can then that's an answer, assuming that I want to expend the effort (which is _not_ going to sell enough units to pay back) to put networking and a http server on the chip.

The ST chips have good enough precision over temperature that serial is OK. At least, they do if they're telling the truth.

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

For UART transfers, you can use two stop bits for added timing tolerance. The price is 10% decrease of byte transmission rate.

--

-Tauno Voipio
Reply to
Tauno Voipio

If you are using an FTDI USB chip, why are you limiting yourself to

115200 baud? As long as your microcontroller has DMA for its UART, you can run these at any speed you like - I have used 2 Mbaud on a couple of boards. You can be sure that any reasonable PC will accept the data at these speeds, and your data transfer will be error-free. It's good to have a final CRC over the whole data file, but the USB link has checksums on each packet so these will be transferred safely.
Reply to
David Brown

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.