This sounds very familiar. I recently had a DS89C450 and 4 XC95108's. Mine were connected to port pins via AND gates that required a hardware latch to be set with a physical key switch, thus eliminating the possibility that a runaway CPU could mangle the CPLD configuration, which would have had bad consequences in my application.


Yes they do. Not only is it confusing, but it's exceedingly inefficient, as others have already stated. What you need is a better XSVF player for small embedded systems. I like XSVF Executor. It's efficient and very cleanly written. While not originally written for 8051, I had no difficulty porting this to Keil C51. I can zip this up and post it.


Hmm. Your CPLD must be a rather small one. I seem to remember my files being quite large. That said, I also had 5 devices to program, so ROM storage was never really an option.


Well, for my application, getting XSVF Executor going was only part of the problem; I also needed to get the XSVF data stream into the microcontroller in the first place. Using code storage was not an option because there was so much, and using an external EEPROM or flash device would not have helped either, as populating those devices with the XSVF data would have been effectively the same problem in the first place. I finally decided to just stream the data in over the serial port. This actually works out quite readily, because XSVF Executor only needs access to the incoming XSVF stream once, and accesses it in a sequential manner, while not imposing any particular timing constraints. Thus, I just maintained a small buffer in RAM on my '450 with XSVF data. When it got emptied, I'd refill it from the serial stream. Quite straightforward.

For the actual serial data transfer protocol itself, I used a protocol similar to the '450 ISP ROM loader. I encoded my XSVF files as HEX-386 files (yes, they're large, but are ASCII and human-friendly), and then wrote an embedded HEX-386 parser. I tightened some of the constraints in my parser beyond those specified in the HEX-386 specification to gain more robust error detection.

The last bit of difficulty on the embedded side was the serial transfer itself. Because XSVF processing is relatively slow, flow control is necessary. I did not have resources available for hardware flow control. However, since I had all ASCII data, software flow control was an option, and I implemented a software UART with software flow control based on a Keil application note. Unfortunately, on all the machines I tested my system on, the PCs were not honoring the XOFF bytes sent by the microcontrollers in a timely fashion, thus requiring me to use a large receive buffer to prevent buffer overflow.

Finally, the last piece of the puzzle was a PC application (based largely on DS89C4x0ldr-lite) that dumped the HEX-386 encoded XSVF file over the PC serial port in the format the embedded HEX-386 parser was expecting. I also wrote a small script in Perl to invoke iMPACT to generate XSVF file from the 5 JEDEC files.

--Sasha Jevtic