Gutsy new 8 bit PIC announced

[Alan B. Pearce-2]

Still future product, but 8 pins, XLP nanowatt, with ECCP module, UART,
MSSP, 256 bytes EEPROM, 3 timers, comparator, ... 1.8V to 5V ...

http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en544839

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

[Tony Vandiver-2]

I started working on a bootstrap for the PIC18F44J10, and was surprised
to find that the size of a block erase is 1024 bytes.  The datasheet
says that the block erase is required for at least every third write
which makes me think I have to use it rather than writing a block of all
FFFF to a 64 byte flash write block to do a pseudo erase.  The problem I
have with that is that if I want to maintain memory on the part that is
never erased, the size of that memory must be at least 1K.  So, if I
want to have the boot block at the start of memory to encompass the
reset and interrupt vectors, that's 1K of codespace that I can't erase
at the start, and in addition, if I want to maintain the configuration
bytes at the end of program memory, that's another 1K of code that I
don't want to ever erase.  That leaves me with only 14K of usable code
space for the part.  I can live with that for my current application,
but it seems pretty wasteful.  Am I not thinking about this correctly?  
Will a 64 byte block write of all 1's effectively substitute for a cell
erase?  I've looked at the App note 851, and although it claims to apply
to all PIC18F devices, it was released in 2002, and refers to
configuration bytes in different memory spaces so I don't think it
covers this part.

Thanks,

Tony

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

[Bob Axtell]

Yes, but there is a good workaround...Just read in the program words you
want to keep and re-write them. Similar situation on the PICF24 and DsPIC.

--Bob

> I started working on a bootstrap for the PIC18F44J10, and was surprised
> to find that the size of a block erase is 1024 bytes.  The datasheet
> says that the block erase is required for at least every third write
> which makes me think I have to use it rather than writing a block of all
> FFFF to a 64 byte flash write block to do a pseudo erase.  The problem I
> have with that is that if I want to maintain memory on the part that is
> never erased, the size of that memory must be at least 1K.  So, if I
> want to have the boot block at the start of memory to encompass the
> reset and interrupt vectors, that's 1K of codespace that I can't erase
> at the start, and in addition, if I want to maintain the configuration
> bytes at the end of program memory, that's another 1K of code that I
> don't want to ever erase.  That leaves me with only 14K of usable code
> space for the part.  I can live with that for my current application,
> but it seems pretty wasteful.  Am I not thinking about this correctly?
> Will a 64 byte block write of all 1's effectively substitute for a cell
> erase?  I've looked at the App note 851, and although it claims to apply
> to all PIC18F devices, it was released in 2002, and refers to
> configuration bytes in different memory spaces so I don't think it
> covers this part.
>
> Thanks,
>
> Tony
>
> --
> http://www.piclist.com PIC/SX FAQ & list archive
> View/change your membership options at
> http://mailman.mit.edu/mailman/listinfo/piclist
>

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

[Isaac Marino Bavaresco]

Tony Vandiver escreveu:

> I started working on a bootstrap for the PIC18F44J10, and was surprised
> to find that the size of a block erase is 1024 bytes.  The datasheet
> says that the block erase is required for at least every third write
> which makes me think I have to use it rather than writing a block of all
> FFFF to a 64 byte flash write block to do a pseudo erase.  The problem I
> have with that is that if I want to maintain memory on the part that is
> never erased, the size of that memory must be at least 1K.  So, if I
> want to have the boot block at the start of memory to encompass the
> reset and interrupt vectors, that's 1K of codespace that I can't erase
> at the start, and in addition, if I want to maintain the configuration
> bytes at the end of program memory, that's another 1K of code that I
> don't want to ever erase.  That leaves me with only 14K of usable code
> space for the part.  I can live with that for my current application,
> but it seems pretty wasteful.  Am I not thinking about this correctly?  
> Will a 64 byte block write of all 1's effectively substitute for a cell
> erase?

Writing FLASH memory can only change bits from '1' to '0', it is for
this reason that the erase exists, to change '0' bits back to '1' again.

Unfortunately the erase granularity for your device is 1K bytes. If you
have enough RAM, first copy the page contents to RAM, modify it, erase
the page and write it again.

Regards,

Isaac

__________________________________________________
Faça ligações para outros computadores com o novo Yahoo! Messenger
http://br.beta.messenger.yahoo.com/ 
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Harold Hallikainen-2]

I don't like to ever rewrite anything in the boot area, whether that's the
vector table or boot code. In my bootload applications, the vector table
points to a jump table in the application area. The reset vector, of
course, points to the bootloader (in the boot area) where a check is made
to decide if the user wants to bootload. If not, it jumps to the first
location in the jump table in the application area. From there it goes on
to the application. All interrupt vectors, whether I use them or not,
point to gotos at the start of the application area (in fixed locations).
Unused ones point to some error detection code or just return. That way,
if I later decide to use an interrupt that was not used at first, I can
still bootload in the new code.

On configuration bits, I think you can write protect those addresses
individually (write protect all config bits), so you don't need to avoid
erasing a 1k block.

I've used this approach on 18LF6722 and 24HJ256GP610. Next is a PIC32!

Harold





--
FCC Rules Updated Daily at http://www.hallikainen.com - Advertising
opportunities available!
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Bob Axtell]

Alan B. Pearce wrote:
> Still future product, but 8 pins, XLP nanowatt, with ECCP module, UART,
> MSSP, 256 bytes EEPROM, 3 timers, comparator, ... 1.8V to 5V ...
>
> http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en544839
>
>  
I'm impressed.

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

[Bob Axtell]

Harold Hallikainen wrote:

> I don't like to ever rewrite anything in the boot area, whether that's the
> vector table or boot code. In my bootload applications, the vector table
> points to a jump table in the application area. The reset vector, of
> course, points to the bootloader (in the boot area) where a check is made
> to decide if the user wants to bootload. If not, it jumps to the first
> location in the jump table in the application area. From there it goes on
> to the application. All interrupt vectors, whether I use them or not,
> point to gotos at the start of the application area (in fixed locations).
> Unused ones point to some error detection code or just return. That way,
> if I later decide to use an interrupt that was not used at first, I can
> still bootload in the new code.
>
> On configuration bits, I think you can write protect those addresses
> individually (write protect all config bits), so you don't need to avoid
> erasing a 1k block.
>
> I've used this approach on 18LF6722 and 24HJ256GP610. Next is a PIC32!
>
> Harold
>
>
>  

I've written several bootloaders. One scheme that works is to maintain
two copies of critical updater code.
Switch to the second while the first is being overwritten. Use CRC16 to
make sure the data is  good before
you switch back.

--Bob


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

[Brooke Clarke]

Hi:

The data sheet shows
"Peripheral Features:
Up to 11 I/O Pins and 1 input-only Pin:"

How do they do that in an 8 pin package?

Have Fun,

Brooke Clarke
http://www.prc68.com

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

[Peter Feucht-2]

They do it in a 14 pin package...

Peter


----- Original Message -----
From: "Brooke Clarke" <brooke@...>
To: <piclist@...>
Sent: Saturday, November 07, 2009 7:24 PM
Subject: Re: [PIC] Gutsy new 8 bit PIC announced

> Hi:
>
> The data sheet shows
> "Peripheral Features:
> Up to 11 I/O Pins and 1 input-only Pin:"
>
> How do they do that in an 8 pin package?
>
> Have Fun,
>
> Brooke Clarke
> http://www.prc68.com
>
> --
> http://www.piclist.com PIC/SX FAQ & list archive
> View/change your membership options at
> http://mailman.mit.edu/mailman/listinfo/piclist

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

[Wouter van Ooijen]

Brooke Clarke wrote:
> Hi:
>
> The data sheet shows
> "Peripheral Features:
> Up to 11 I/O Pins and 1 input-only Pin:"
>
> How do they do that in an 8 pin package?

the datasheet is not just for the 8-pin chip

--

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: www.voti.nl/hvu

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

[Barry Gershenfeld-2]

>
> Still future product, but 8 pins, XLP nanowatt, with ECCP module, UART,
> MSSP, 256 bytes EEPROM, 3 timers, comparator, ... 1.8V to 5V ...
>

...10 bit A/D, ICD, self write, 32MHz intosc, ...

Many's the time I've looked into "What's the smallest PIC that has a UART?"
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[M. Adam Davis-2]

Touch sensing... autobaud uart... lots of flash.

Yes, this is a very, very nice chip.  Probably will cost more than $1
in quantity though...

-Adam

On Fri, Nov 6, 2009 at 4:44 AM, Alan B. Pearce <Alan.B.Pearce@...> wrote:

> Still future product, but 8 pins, XLP nanowatt, with ECCP module, UART,
> MSSP, 256 bytes EEPROM, 3 timers, comparator, ... 1.8V to 5V ...
>
> http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en544839
>
> --
> http://www.piclist.com PIC/SX FAQ & list archive
> View/change your membership options at
> http://mailman.mit.edu/mailman/listinfo/piclist
>

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