One annoying misfeature of the UART on every PIC I've worked with is that a data overrun error will shut down the receiver until code disables and re-enables it. It is thus imperative to have code that will periodically check the overrun-error flag and, if it is set, disable and re-enable the UART receive function. Otherwise if the receive buffer overruns, you won't just lose a received byte--you'll lose all data forevermore.
I'm not really sure why Microchip designed their UARTs this way. My guess would be that in early PICs a receive overrun would cause the receive state machine to lose frame sync, and that disabling the receiver was considered preferable to receiving randomly-framed data (I might agree with them on that point, though I would consider dropping whole bytes while maintaining sync to be better still); later PICs maintained the behavior for compatibility, despite substantial redesigns of the UART subsystem.
In any case, the PIC's UART implementation is what it is. Check to ensure that the UART receiver is enabled and the receive-overflow isn't tripped. If not, disable the UART receive function and re-enable it. Note, btw, that on some PICs the master disable for the UART function will not disable the receiver; you need to clear and re-set the receiver enable.
Most small microcontrollers will be capable of doing what you need. You could even ditch the Arduino "wrapper" and use a USB capable micro in it's place.
Microchip, Atmel, TI, ST, etc all have 8, 16, 32-bit uCs of varying RAM/FLASH/EEPROM sizes to pick from. All the modern uCs come with at least UART, SPI, I2C peripherals that can be used for your communications.
There is not a lot in them really, I'd just pick one and see how you like it.
I (currently) use ST's 32-bit ARMs and Microchip 8, 16 ,32-bit PICs.
I'd probably use a few PIC12F or 16Fs for the slave uCs and a PIC18F or PIC24F for the master.
You mention needing ~10kbits of memory (not quite clear what type or which uC needs it from your description to me though)
It's easy to determine what is suitable though, just check the RAM/ROM/EEPROM specs of each uC you look at.
For example the PIC16F1938 has:
Parameter Name Value
Program Memory Type Flash
Program Memory (KB) 28
CPU Speed (MIPS) 8
RAM Bytes 1,024
Data EEPROM (bytes) 256
So 28KB of program memory is more than enough to store non-volatile data if your program is small enough (on the newer PICs you can also read/write to program memory at run time) 10kbits will not quite fit into the RAM though, at 1024 * 8 = 8192 bits.
The 16F1527 has 1536 bytes of RAM though, so you could use this if necessary.
For the master (alternatives to Arduino) there is something like the 18F25J50 or similar, which has a USB 2.0 peripheral. Microchip provide a USB stack an plenty of example firmware to get you started with USB.
If you need something more powerful for the master, have a look at the PIC24 series with up to 256K of Flash and 96K of RAM. Or even the PIC32 which is 32-bit and up to 80MIPS.
The PICKit3 is a low price programmer that will program all the above mentioned PICs, and MPLAB (or MPLABX) is a free IDE for firmware development.
Communication can be done with I2C, which deals with the master/slave configuration and addressing easily. All you have to worry about is sending the data. 7 meters should be no problem with a reasonably quiet environment and the right setup (low value pullups - say 2.2k, low capacitance cable)
Best Answer
Tying multiple PICs together to program them at the same time is not a good idea.
Programming is not totally a one-way process. Programmers may try to read from the PIC for several reasons:
The net result is that the programmer probably does several back and forth attempts at communication when first starting the programming operation.
Even when the exact target PIC is specified externally, like with a command line argument, my programmers at least still attempt to verify that particular PIC model is connected.
However, that doesn't mean you can't program multiple PICs a the same time, only that a little more of the programming process needs to be replicated per PIC. Basically, you need to replicate at least the low level hardware interface per PIC.
The simplest way to do that is to use multiple programmers. Programmers are a one-time cost. If you are doing such high volume that programming multiple PICs in parallel is important, then the cost of multiple programmers should be minor.
For example, if you are using one of the newer PICs that can be programmed completely from a 3.3 V interface only, then you can use my LProg PIC programmer. At $18 each for five (Apr 2017), a bunch of these and a USB hub are cheaper than most gang programmers. That gives you a setup that works in-circuit, which gang programmers generally don't.