I'm using a Celeron 833Mhz system with a buffered serial chips so I guess its fast enough to
not have overruns. I didn't turn on any flow control only because I didn't need it.
Here are some things you can try:
1. For reading, the wpflash program controls how much data is read each "request". So,
you could modify the wpflash source to request a smaller amount of data...it sounds like that is what
you did when you say you can read 16 bytes without overflow.
2. For writing, most of the data is going to be PC -> Webpal with only short ACKs in the
reverse direction, so I don't believe you'd run into an overrun problem on the PC side.
In theory, the PC would send as fast as it could and only have to read a short amount of
data to be read which should fit in the chip fifos. I've haven't had issues with the webpal keeping up
since its just in tight polling loop....no OS overhead, no interrupts being disabled too long, etc.
3. You could modify both the wpflash and the prog.srec program to use a slower speed.
For 9600 baud, use the value 12 instead of 1 and change all the SerialOpen routines in prog.c
and then rebuild. In wpflash.c, you can use the Linux defines...use B9600 instead of B115200.
If you want to modify the real bootp program also, its main.c where the SerialOpen
routines are. If you want to use other speeds, get the data sheet for the SuperIO
chip for the webpal and it contains some divisors you could use. At 9600 baud, its
gonna take about 25 minutes time to program all 1M byte so make sure you have a snack handy!
4. If, by chance, you bought 2 units, you can play the trick where you load prog.srec
into the RAM, pull out your "flash with the webpal SW on it" flash (with power still on)
and insert the second flash SIMM (again with power on) and then program the second
flash. Then, if you get a program
failure, you can still go back to the original SIMM to load prog.srec again. Obviously,
exchanging flash SIMMs while the system is running isn't a good idea, but people
have done this, especially when we were trying to get this running the first time
ourselves!
4. Worse case, if it fails, you can always send the flash to me to be programmed the
first time.
Bill
