I believe the following is a reasonable summery of where we are.
-Duane.
=================================
(a) There is little to no ram what so ever in the target.
=================================
Option 1
Duane feels there is always 4K or more.
Others point out 4K is not always there.
Solutions to that problem are: SDRAM can be configured
If SDRAM cannot be configured (it is to hard) CACHE
could be configured by openocd.
Again - going back to the "big chip verse little chip"
Little chips have the ram built in.
Big chips - have external (sdram) and I believe "cache"
Advantage:
With more RAM comes more flexibility
Disadvantage:
Configuring SDRAM for some is hard to figure out.
Configuring CACHE - is not something supported today.
The question becomes: What is 'reasonable'.
Option 2
Others do not, and want this to work in some smaller size.
How big? The expression seems to be "bytes" of code.
Advantage:
Fits in more places
Disadvantage:
Many 'purpose built' sequences.
=================================
(b) Opcode/Bytecode/Interpretor or Purpose Built
=================================
Option (3)
Purpose Built is what exists today - and others do not like this.
I (duane) define purpose built as: Code that is written for
exactly one purpose and no other purpose.
One would load code to do an erase-chip, another chunk of code to
do page program.
Etc ...
Perhaps - cleaning up and making the purpose built more generic
is a solution.
Functionally this means: A generic front end.
Advantage:
(cleaning up) Simplifies the front end
Disadvantage:
X * Y * Z = total number of solutions
X combinations for Y chips or Z targets.
Option (4)
Is the byte code interpretor approach.
In this scheme, the "blob" is downloaded once.
That blob "loops".
At each "loop" one or both get downloaded/updated
(A) new byte code sequences
(B) data in bunk.
The "blob" is resumed and it loops.
Advantage:
Opcode stream is cross platform
Complexity of writing "sequences"
Disadvantage:
Blob Size is larger.
TBD - how large "large is"
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
