Of olin_piclist@embedinc.com wrote :

> 
> I don't know how your Wisp works and haven't looked at the firmware or
> software, but adding 10F support to my programmers wasn't just adding
> another 16F part.  Some important differences are:
> 
> 1  -  10F parts don't have a device ID.  My programmer 
> software previously relied on this to identify the PIC and
> select the correct programming algorithm.  Most of the
> work of supporting the 10Fs was on  the host software
> side to deal with no device ID.

Wouters software (and XWIsp2) supports explicit specification of
the device on the command line. That would take care of that, not ?
Not a big deal in that case, IMHO.

> 2  -  The current address in the chip is not 0 after a reset. 
>  Even worse, it depends on the program memory size, which
> depends on the part, which it won't tell you.

If the software knows the device (by an option on the command line)
it's always the highest program address, AFAIK. That's also
where the OSCCAL value have to be read and restored.

Anyway, I have an idea for a 10F (-202 probably) application.
I guess I'll just use some 16F (or 12F) chip as the proof-of-
concept and pre-development environment. I'd guess that,
giving it a bit of thought, you could write quite 10F-compatible
code on a 14-bit PIC that would be not *to* hard to move over
to the 10F later when I have the proper tools...

B.t.w, this application is not particaly sensitive to the OSCCAL
value. In fact, it would be better if the speed *does* varies a bit
from device to device in some random way... :-) :-)

Jan-Erik.
_______________________________________________
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist