If you transfer ASCII files from PCs to the microcontrollers via something like GPRS, keep in mind that you're probably going to need some kind of flow control unless you're writing all the data to RAM.

I recently had a project that included the ability to update the firmware using in-application programming (IAP) via the GPRS modem. Problem was, I didn't have sufficient RAM to store the new program so I had to use external serial flash memory to store the incoming program; once the new program was loaded in its entirety in the external flash memory, a small loader program then copied the contents from external flash memory to the on-chip program flash memory. Problem was, the flash memory couldn't keep up with the incoming datastream.

So I had to implement some flow control so that the server wouldn't send data faster than the device and its flash memory could handle. Once I implemented this flow control, the throughput dropped like a rock due to the inherent latency of GPRS plus the Internet itself. Even though the communication rate was technically 9600 baud, the effective rate was probably more like 300.

I'm sure I could have improved this with some form of double-buffering (writing to the little amount of free on-chip XRAM we had available, and then writing several packets of data from XRAM to external flash) but the feature was and is used so infrequently that both the client and I agreed it wasn't worth the additional development time.

Anyway, this shouldn't be an issue if you're writing to XRAM. But keep it in mind if you'll be flashing the incoming data. Of course, this applies whether you're using wireless communication or not... it's just that the latency of most packet-based wireless networks amplifies the problem.

Regards,
Craig Steiner