John McCarthy wrote: > I was thinking along the same lines. This way we write an opcode stream > definition for each flash type which works for all targets (with > external flash). And for each target implementation we provide an > opcode interpreter and a fast buffer transfer mechanism. The target > implementation gets called with the buffer and the opcode stream. It > has to get these transferred to the target and run the target opcode > interpreter. > > Some added complexities are multi-chip banks (for example 2x16 or 4x8 > chips for 32 bits) and of course error handling, but that should not be > too difficult. We'd need to make the opcodes rich enough to handle word > program, UnlockBypass programming as well as Buffered programming modes > (are there any other programming types?) but again that seems straight > forward. The only looping is status checking which has a small number > of variations (I think) and of course error detection/reporting would be > a part of this. > > Given that the buffer transfer and opcode interpreter is managed by the > target implementation, it might even be able to handle strange flash > access mechanisms (e.g SPI or internal flash) transparent to the > algorithm (assuming they are the compatible of course). But that's for > later enhancements... > > Does that fit in your thinking? >
That is exactly my thinking. _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
