Michael Schwingen wrote:
> First, I think the target code should stay as small as possible, because
> there may be targets where very little RAM is available for the code.
>
I disagree, I think we always have 4K of ram, here's why:
Generally:
There are two classes of devices.
1) Those with internal flash.
2) Those with external flash.
Assertion:
During "flash programing", openocd controls the world and the chip.
And - there is "ram to be had some where" that openocd can use.
Assertion:
The target here is *NOT* embedded "8051" or 'tiny pic' or 'tiny avr'
type micro controllers
Those have their own flash programing solutions - and debug tools.
We are not trying to solve those problems here with openocd.
Assertion:
OpenOCD targets are a 16/32bit chips with JTAG and a recent vintage.
(Yea, I know there are 6502 ports for GCC...)
Assertion:
The target uses GCC and/or GDB.
Assertion:
Anything matching the above - is either
(1) a micro controller with internal flash (and ram) or
(2) has external memory that can be configured some how.
(ie: maybe to config ram, one must write a sequence of 'mww' commands)
Assertion:
Anything with internal flash is a micro controller and will be
purpose built, and perhaps "just weird".
Assertion:
The issue here is *external* flash.
Flash that is common across multiple targets.
I believe the above assertions are true.
Does anybody disagree? If so - why?
If they are true - then - I believe we can easily claim "4K" is reasonable.
With 4K - the little "blob" of code can be quite powerful.
Even if we must limit it to 2K - there are some simplistic methods one
can accomplish.
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
