Searching \ for '[PIC] PIC16F88 too small' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=16F
Search entire site for: 'PIC16F88 too small'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] PIC16F88 too small'
2006\08\27@190645 by Brent Brown

picon face
What do you do when you've run out of program space in a PIC16F88? I'm looking
through the Microchip website but can't find anything ideal yet. The perfect solution
would be a drop in pin compatible chip with all the same features but 8K words of
Flash instead of 4K.

Features I need are self writable Flash for bootloader, internal RC oscillator, some
EEPROM, PWM, USART, 28 pin QFN package, more than 4K words of program
space (probably 6-8K). PIC16F886 looks like a contender but it doesn't apprear to
be available yet (who knows when?), also not pin-compatible but could do a PCB
re-design (don't really want to). Is there another chip out there I just haven't seen
yet? eg. What is a PIC16F89 and why can't I find it on the Microhip site? Google
finds a few references to it but I have no hard facts.

For my prototypes I think I can just squeeze in enough of the program to get them  
running, but there will be some extra features required for production units. I need
to add LCD menu's for installer setup options etc, which eats up code space I don't
have. Program is written in Hi-Tech PICC, and I'm not blaming that for my code size
problems. I'm doing all the things I can think of to minimise space used.

--
Brent Brown, Electronic Design Solutions
16 English Street, St Andrews,
Hamilton 3200, New Zealand
Ph: +64 7 849 0069
Fax: +64 7 849 0071
Cell: 027 433 4069
eMail:  spam_OUTbrent.brownTakeThisOuTspamclear.net.nz


2006\08\27@194709 by Marcel Duchamp

picon face
Brent Brown wrote:
> What do you do when you've run out of program space in a PIC16F88? I'm looking
> through the Microchip website but can't find anything ideal yet. The perfect solution
> would be a drop in pin compatible chip with all the same features but 8K words of
> Flash instead of 4K.
>
> Features I need are self writable Flash for bootloader, internal RC oscillator, some
> EEPROM, PWM, USART, 28 pin QFN package, more than 4K words of program
> space (probably 6-8K). PIC16F886 looks like a contender but it doesn't apprear to
> be available yet (who knows when?), also not pin-compatible but could do a PCB
> re-design (don't really want to). Is there another chip out there I just haven't seen
> yet? eg. What is a PIC16F89 and why can't I find it on the Microhip site? Google
> finds a few references to it but I have no hard facts.
>
> For my prototypes I think I can just squeeze in enough of the program to get them  
> running, but there will be some extra features required for production units. I need
> to add LCD menu's for installer setup options etc, which eats up code space I don't
> have. Program is written in Hi-Tech PICC, and I'm not blaming that for my code size
> problems. I'm doing all the things I can think of to minimise space used.
>
If nothing else presents itself, I would examine the listing to check
for extra unneeded instructions.  For example, bank switching when it's
not needed, etc.  But that's a long shot in terms of getting much from
it.  Maybe factoring the program to eliminate redundant code...

2006\08\27@195150 by Maarten Hofman

face picon face
Rochester, 27 augustus 2006.

Dear Brent,

I'm not sure, but you might want to try compiling the code for the 18F1320.
As far as I can tell, C is more efficient on the 18F series compared to the
16F, and you might be able to fit more into the same amount of memory. I
glanced over the datasheets, and it seems the 18F1320 and the 16F88 are QFN
pin compatible and both have a PWM and USART and 256 bytes of EEPROM.

At least try it: the instruction set of the 18F series is broader, and it
also has 16 bit/word, instead of 14-bit, which can make a difference when
storing data in program memory.

Greetings,
Maarten Hofman.

2006\08\27@200036 by peter green

flavicon
face

> What do you do when you've run out of program space in a
> PIC16F88?
look for something bigger of course. Some comprimise may be needed though.

{Quote hidden}

you could try the 18F1320, no more instruction words but its 18 series which
should be able to do the same C code in less words (and since your coding in
C migration to the pic18 core shouldn't be too hard). The pinout differs in
what ports are where but not in the vital stuff like power ground and which
pins are in use. If you go for this chip though make sure you get as recent
a rev as possible.  There are a lot of horror stories about it particularlly
the early revs.

Failing that it doesn't look like you have much choice but to go for
something with more used pins. my parametric searching revealed the
following possibilities

PIC16F876A
PIC16F916
PIC18F2420
PIC18F2431
PIC18F2480
PIC18F2520
PIC18F2580

i'd advise going through all theese comparing pinouts etc to see if any of
them are close enough to get away without a board redesign.

2006\08\27@212903 by Charles Craft

picon face
If you can tweak the board how about adding an external serial memory chip?
The menus probably won't be accessed often so loading them over a serial link may not be bad?


{Quote hidden}

2006\08\27@214751 by Richard Prosser

picon face
Add another 16F88 - or something smaller just to look after (eg) the
LCD dispay etc.?

RP


On 28/08/06, Marcel Duchamp <.....marcel.duchampKILLspamspam@spam@sbcglobal.net> wrote:
{Quote hidden}

> -

2006\08\27@223045 by Jinx

face picon face
> What do you do when you've run out of program space in a
> PIC16F88?
> look for something bigger of course. Some compromise may
> be needed though.

www.microchip.com/ParamChartSearch/chart.aspx?branchID=1035&mid=10&la
ng=en&pageId=74

18-pin, 18F1320

28-QFN, 16F876A / 916, 18F24xx / 25xx / 26xx

2006\08\27@225352 by Bob Axtell

face picon face
Jinx wrote:
>> What do you do when you've run out of program space in a
>> PIC16F88?
>> look for something bigger of course. Some compromise may
>> be needed though.
>>    
>
> www.microchip.com/ParamChartSearch/chart.aspx?branchID=1035&mid=10&la
> ng=en&pageId=74
>
> 18-pin, 18F1320
>
> 28-QFN, 16F876A / 916, 18F24xx / 25xx / 26xx
>
>  
You COULD switch to assembler, of course...

--Bob

2006\08\28@014811 by Robert Ammerman

picon face
You can sometimes find a few routines or data structures that are taking up
an inordinate amount of space....

Some common candidates:

1. The floating point routines. Many (most?) apps that use floating point
will work very well with fixed point arithmetic and a little bit of care.

2. The 'printf' routine and its relatives. This is a real hog, especially
when combined with support for floats!  You can avoid these routines by
using simpler ones like itoa(), or even one written by yourself (it isn't
hard!).

3. Inefficient data structures for things like menus (in code space). Look
out for fixed length string buffers:

char menu_choices[4][21] = {
   "La la",
   "Do de do",
   "Moonshine",
   "Happy!"
};

This uses 68 bytes of memory to hold 4 20-character menu options.

char *menu_choices[4] = {
   "La la",
   "Do de do",
   "Moonshine",
   "Happy!"
};

This uses 8 bytes for 4 pointers, plus 32 bytes for text and nulls for a
total of 40 bytes.

Or, even better, since accessing menu choices is a "human speed" action...

char menu_choices[] = {
   "La la\0"
   "Do de do\0"
   "Moonshine\0"
   "Happy!\0"
};

Which uses only 33 bytes. Note that there are no commas, and each entry is
terminated with an explicit null. The last entry is terminated with a double
null. It is easy to write a function:

char *find_menu_entry( char *menu, int n )
{
   while (n--)
   {
       /* point to next menu item */
       menu = strchr(menu,0) + 1;

       /* next two lines are optional to protect from */
       /* invalid values of 'n' */
       if  (*menu == 0)
           return 0;                /* ran off the end */
   }
   return menu;
}

(where n is a number in the range 0..number of substrings - 1)

Bob Ammerman
RAm Systems

2006\08\28@050222 by Jinx

face picon face
> What is a PIC16F89

Dunno, but this looks to have been lifted from a d/s

http://micropic.free.fr/16F89.jpg

Same as an F88 with C0 and C1 in the middle

2006\08\28@050236 by Brent Brown

picon face
My comments below on various replies..
 
> You COULD switch to assembler, of course...

COULD but WONT!   :-)

> Add another 16F88 - or something smaller just to look after (eg) the
> LCD dispay etc.?

Already doing that as the LCD display and keypad is remote and it has it's own
PIC16F88, with comms over an RS232 like interface. I send instructions like "put
this string of characters on line 2".

> If you can tweak the board how about adding an external serial memory
> chip? The menus probably won't be accessed often so loading them over a
> serial link may not be bad?

Not keen on that (hardware wise), but could use on chip EEPROM to store some
strings I guess, but really that would only be a saving of a few hundred bytes max.

> you could try the 18F1320, no more instruction words but its 18 series
> which should be able to do the same C code in less words (and since your
> coding in C migration to the pic18 core shouldn't be too hard).

Interesting idea... so I did a quick test to try it.
Compiling for PIC16F88 --> 3669 words (89.6% of 4096 words).
Compiling for PIC18F1320 --> 3511 words (85.7% of 4096 words).
Used Hi-Tech PICC and PICC-18 Compilers. Commented out about a dowzen lines
that wouldn;t compile without some tweaking. Not a huge difference in code size
although it does at least tend to confirm that 18F programs can be more size
efficient as one might expect.

Other bit's and pieces... I'm not using floats, printf or any large data structures. My
menu structure is not great but not obese either. The one thing that pushed me over
the top was adding CRC checking for my 1 wire temperature sensors -  needed it
because I'm getting the occasional erroneous result. This adds about 300 program
words.

Having made some improvements and nips/tucks in other areas I think I will keep
plodding along and get as much code as possible squeeezed in to my prototype(s) -
gotta be working by the end of this week! After that I'll have to look at a bigger
micro, new PCB, seems like there are a few possibilities.

It's a shame I can't find anything about a PIC16F89. A couple of ICE vendors make
pods described as being for PIC16F87/88/89 so perhaps this is something
scheduled for the future, and just maybe the difference is it has larger Flash? Can't
help the feeling that I've read about it somewhere.

Thanks all for the tips.
--
Brent Brown, Electronic Design Solutions
16 English Street, St Andrews,
Hamilton 3200, New Zealand
Ph: +64 7 849 0069
Fax: +64 7 849 0071
Cell: 027 433 4069
eMail:  brent.brownspamKILLspamclear.net.nz


2006\08\28@064807 by Stef Mientki

flavicon
face
are you storing the menus as 2*7bit ?
Stef

Brent Brown wrote:

{Quote hidden}

2006\08\28@075011 by Rolf

face picon face
Have a look at:

file:///C:/Repository/NikonSB/StringFormat.html

Made my C program a chunk smaller by re-using strings in messages
(stored as tables in program memory....). I wrote it with C18 in mind,
but will probably be useful for HitechC as well.

(Especially if you say your menu system is obese).

Rolf

Brent Brown wrote:
{Quote hidden}

2006\08\28@083716 by olin piclist

face picon face
Brent Brown wrote:
> The one thing that pushed me over the top was adding CRC
> checking for my 1 wire temperature sensors -  needed it
> because I'm getting the occasional erroneous result.
> This adds about 300 program words.

Huh!?

CRC is a really simple algorithm that shouldn't take more than a few
instructions.  For each bit you shift it in one end.  If the bit that
shifted out the other end is 0 you're done.  If it is 1, you XOR the
accumulated checksum with a fixed value.  That's it.  There are some
variations about which end to shift into, whether you do the XOR on a 0 or
1, what the accumulator is initialized to, etc.  However, none of these
should change the basic algorithm or the number of instructions required.

I just checked some recent code I wrote that computed a 16 bit CRC on bits
in a buffer.  It takes 29 instructions, which includes the initialization,
checking for end condition, advancing to the next bit, etc.  The actual CRC
update calculation is only 8 instructions once the bit is in STATUS,C.


******************************************************************
Embed Inc, Littleton Massachusetts, (978) 742-9014.  #1 PIC
consultant in 2004 program year.  http://www.embedinc.com/products

2006\08\28@083750 by Rolf

face picon face
Of course, that should have been:
http://piclist.org/techref/microchip/language/c/stringformat.htm

Rolf

Rolf wrote:
{Quote hidden}

2006\08\28@083816 by Stef Mientki

flavicon
face


Rolf wrote:

>Have a look at:
>
>file:///C:/Repository/NikonSB/StringFormat.html
>  
>
nice, but how can I reach your C-disk ;-)
Stef

2006\08\28@094403 by Scott Dattalo

face
flavicon
face
On Mon, 2006-08-28 at 21:00 +1200, Brent Brown wrote:

>> You COULD switch to assembler, of course...
>
> COULD but WONT!   :-)

Hmm?

> The one thing that pushed me over the top was adding CRC checking
> for my 1 wire temperature sensors - needed it because I'm getting
> the occasional erroneous result. This adds about 300 program words.

300 words is very excessive for a CRC routine. My one-wire CRC
routines takes only 19 instructions and no table:

http://www.dattalo.com/technical/software/pic/crc_8.asm

Since you're religiously opposed to assembly, this C source will save
your soul:

http://www.dattalo.com/technical/software/pic/crc_8bit.c

A good C-compiler should turn the crc_bits() function into about 19
instructions.

Scott

2006\08\28@095228 by rlistas

picon face
Try this LCD controller:

http://www.myke.com/lcd.htm

Less code and pins, using just a cheap CI 74LS174.


[]s

RUbens


At 20:04 27/8/2006, you wrote:
{Quote hidden}

>-

2006\08\28@100544 by Maarten Hofman

face picon face
2006/8/28, Scott Dattalo <EraseMEscottspam_OUTspamTakeThisOuTdattalo.com>:
>
> On Mon, 2006-08-28 at 21:00 +1200, Brent Brown wrote:
>
> >> You COULD switch to assembler, of course...
> >
> > COULD but WONT!   :-)
>
> Hmm?


Basically I have the feeling the design stage for this project was cut
short. I enjoy making a design before I code anything, even if it is on
pieces of scrap paper. From this design I can then tell what kind of
PICmicro I will need, and what the approximate code sizes are for the
various features. I would not get a 16F88 if I didn't have I2C or SPI, and
if my design indicated it would benefit from coding in C, I would probably
look towards the 18F family immediately. This is how I ended up with the
16F628A for my NTSC system, which worked very well (better than any other
16F series would have worked, although the bug in the EEPROM write routines
was a bit unfortunate).

Generally, when I have a good design, I don't really care about coding the
entire project again. The coding phase for an 4-8 Kword PICmicro should be
very short (2-4 days), especially if the design covers what needs to be done
where, and how it can be tested quickly. Also, rewriting everything tends to
improve the quality of my code.

I would be worried about redesigning the PCB though, and I can see why this
would be a major concern of Brent. I was happy that he told us the
difference in code efficiency between the 16F and 18F series, I thought it
would've been better, but at least we now have one sample.

Greetings,
Maarten Hofman.

2006\08\28@101013 by Maarten Hofman

face picon face
>
> Try this LCD controller:
>
> http://www.myke.com/lcd.htm
>
> Less code and pins, using just a cheap CI 74LS174.


Please explain how serial access to an LCD reduces the code size compared to
full parallel access? I know it reduces the number of pins (though I would
go for a three pin interface with a normal shift register, and not Myke's
two pin interface... I never had much luck with that) but in my experience,
it increases the code size: instead of a simple "move data to port, toggle
enable" you now have to shift each bit separately and then toggle enable.

In Brent's case it doesn't really help either, as it would still result in a
redesign of his PCB, which is the thing he is trying to avoid.

I do appreciate seeing the old example from Myke Predko coming back, though
(I liked his book a lot).

Greetings,
Maarten Hofman.

2006\08\28@103330 by John Scott

flavicon
face




Maarten Hofman wrote:

>I do appreciate seeing the old example from Myke Predko coming back, though
>(I liked his book a lot).


Which book did you like? He has lots in print, and I would like to
choose a good starting point.

Regards

{Quote hidden}

2006\08\28@110243 by rlistas

picon face
Hi Maarten,

When I sent this email, I hadn´t received
the email saying it has another PIC 16F88
controlling the LCD and serial communications. :>)

This LCD controller implementation is nice when
you have just two pins for I/O.

"and not Myke's two pin interface... I never had much luck with that"
What kind of problems did you experience with this implementation?

Best regards,

Rubens


At 11:10 28/8/2006, you wrote:
{Quote hidden}

>

2006\08\28@110309 by Maarten Hofman

face picon face
>
> >I do appreciate seeing the old example from Myke Predko coming back,
> though
> >(I liked his book a lot).
>
>
> Which book did you like? He has lots in print, and I would like to
> choose a good starting point.


The book is called "Programming and Customizing PICmicro Microcontrollers".
I wouldn't use it as a starting point, though. It is similar to another
thought provoking book I read, "Effective C++: 55 Specific Ways to Improve
Your Programs and Designs". Both require you to have a reasonable amount of
background knowledge before you can use them. Here is a partial list of pros
and cons:

- Many bugs in both code and circuit diagrams, which require thinking.
+ Many bugs in both code and circuit diagrams, which require thinking.
- Rather old (18F only covered to a limited extent, too much 17F and no
16-bit PICmicros).
+ Very clever circuits, like the one resistor RS-232 level converter.
- Focuses on the 16F84A (please use the 16F628A or higher as replacement).
+ He writes down his line of thought as well as his mistakes, allowing you
to follow/avoid.

Try to get the newest revision of the book. Do not build the included "El
Cheapo" programmer, unless you enjoy restricting yourself to a rather small
sample of PICmicros. A JDM programmer from eBay will be cheaper (and will be
fine, if your serial port is compliant), and a PICkit 2 will make you much
happier.

Note that my preference for this book stems from the fact that I have no
problems with code, but occasional difficulties with the electrical
circuits. Myke's circuits are worth looking at, his code might not be.

Greetings,
Maarten Hofman.

2006\08\28@113109 by Maarten Hofman

face picon face
>
> "and not Myke's two pin interface... I never had much luck with that"
> What kind of problems did you experience with this implementation?


First of all wiring it compared to a simple shift register is much more
complicated. In the circuit diagram they put all the connections to the
74LS174 next to each other, but in reality you need to connect the lines all
over the place. Also, the diode and resistor increase the number of points
that need to be soldered and designed for on your board even larger.

My second problem with the system is that the "shift" register needs to be
cleared after each operating, which basically doubles the number of cycles
spent shifting. If you just wait for 160us afterwards anyway this doesn't
really matter, of course, but if you're updating the LCD every 160us from an
ISR the double length really impacts the speed of your code.

The third problem is that I never was able to get that E pulse happen quite
the way it is supposed to. Even Myke himself is a bit confused whether it is
high level active or falling edge active. By keeping the enable completely
separate I never ran into problems with this.

Finally, if you keep the enable separate, you can use the shift register
output data for multiple purposes. you just need another enable line, and
you can have the data go to multiple locations, thereby increasing the
number of pins you can output to drastically.

Greetings,
Maarten Hofman.

2006\08\28@121717 by Dennis Crawley

picon face
Scott Dattalo <scottspamspam_OUTdattalo.com> wrote:
> Since you're religiously opposed to assembly, this C source will save
> your soul:
>
> http://www.dattalo.com/technical/software/pic/crc_8bit.c
>
> A good C-compiler should turn the crc_bits() function into about 19
> instructions.
> Scott

I've tried four CRC8 routines in Keil C51 for a 8051 core:

1.- Atmel (i-button):
   machine cycles = 152
   prog. mem. =   0B
2.- Scott, Table routine:
   machine cycles = 20
   prog. mem. =   256B
3.- Scott, nibble routine:
   machine cycles = 65
   prog. mem. =   32B
4.- Scott, bits routine:
   machine cycles = 51
   prog. mem. =   0B
   (*)asm instrucctions= 30

For more speed, the use of table can make a difference, but the bit
routine... is the winner for little program memory spaces!

Thanks, Scott.

Dennis Crawley
Argentina
http://www.geocities.com/proyectosenpic
(spanish)


-----------------
(*)
   78: unsigned char crc_bits(int dato)
   79: {
   80:   int i = (dato ^ crc) & 0xff;
   81:
C:0x05C8    E50F     MOV      A,crc(0x0F)
C:0x05CA    6F       XRL      A,R7
C:0x05CB    FF       MOV      R7,A
   82:   crc = 0;
C:0x05CC    E4       CLR      A
C:0x05CD    F50F     MOV      crc(0x0F),A
   84:   if(i & 1)
C:0x05CF    EF       MOV      A,R7
C:0x05D0    30E003   JNB      0xE0.0,C:05D6
   85:     crc ^= 0x5e;
C:0x05D3    630F5E   XRL      crc(0x0F),#0x5E
   86:   if(i & 2)
C:0x05D6    EF       MOV      A,R7
C:0x05D7    30E103   JNB      0xE0.1,C:05DD
   87:     crc ^= 0xbc;
C:0x05DA    630FBC   XRL      crc(0x0F),#0xBC
   88:   if(i & 4)
C:0x05DD    EF       MOV      A,R7
C:0x05DE    30E203   JNB      0xE0.2,C:05E4
   89:     crc ^= 0x61;
C:0x05E1    630F61   XRL      crc(0x0F),#0x61
   90:   if(i & 8)
C:0x05E4    EF       MOV      A,R7
C:0x05E5    30E303   JNB      0xE0.3,C:05EB
   91:     crc ^= 0xc2;
C:0x05E8    630FC2   XRL      crc(0x0F),#0xC2
   92:   if(i & 0x10)
C:0x05EB    EF       MOV      A,R7
C:0x05EC    30E403   JNB      0xE0.4,C:05F2
   93:     crc ^= 0x9d;
C:0x05EF    630F9D   XRL      crc(0x0F),#0x9D
   94:   if(i & 0x20)
C:0x05F2    EF       MOV      A,R7
C:0x05F3    30E503   JNB      0xE0.5,C:05F9
   95:     crc ^= 0x23;
C:0x05F6    630F23   XRL      crc(0x0F),#0x23
   96:   if(i & 0x40)
C:0x05F9    EF       MOV      A,R7
C:0x05FA    30E603   JNB      0xE0.6,C:0600
   97:     crc ^= 0x46;
C:0x05FD    630F46   XRL      crc(0x0F),#0x46
   98:   if(i & 0x80)
C:0x0600    EF       MOV      A,R7
C:0x0601    30E703   JNB      0xE0.7,C:0607
   99:     crc ^= 0x8c;
  100:
C:0x0604    630F8C   XRL      crc(0x0F),#TH0(0x8C)
  101:   return crc;
C:0x0607    AF0F     MOV      R7,crc(0x0F)
}



2006\08\28@195531 by Brent Brown

picon face
On 28 Aug 2006 at 21:02, Jinx wrote:

> > What is a PIC16F89
>
> Dunno, but this looks to have been lifted from a d/s
>
> http://micropic.free.fr/16F89.jpg
>
> Same as an F88 with C0 and C1 in the middle

Yes, interesting. Google finds parts suppliers that list a PIC16F89, although I'm
wondering if they're just typo's.
--
Brent Brown, Electronic Design Solutions
16 English Street, St Andrews,
Hamilton 3200, New Zealand
Ph: +64 7 849 0069
Fax: +64 7 849 0071
Cell: 027 433 4069
eMail:  @spam@brent.brownKILLspamspamclear.net.nz


2006\08\28@214605 by Jinx

face picon face
> Yes, interesting. Google finds parts suppliers that list a PIC16F89,
> although I'm  wondering if they're just typo's.

Showing pin-outs is a major typo !! Could be someone's idea of
a joke of course. Or escaped info on a planned product that never
got off the drawing board

I'm enquiring at Microchip. 16F89 doesn't appear in any of
the drop-downs, so the answer will probably be what we think
it's going to be

2006\08\28@215349 by Brent Brown

picon face
I was using a table driven CRC routine, which takes 256 words of code space just
for the table plus about 26 words of code. Many thanks to Steve Baldwin who sent
me a nice little CRC function, no table, uses a total of 34 words program space
including call to function and testing the result. Obviously slower than the lookup
table method but that's fine for me and saves a useful amount of code psace.

String packing (2 characters per word) is something Hi-Tech PICC is supposed to
do for midrange PIC's that can read their own program memory "if it is efficient to
do so". So far it seems to not be doing this, don't know why yet so I will look at that
a bit closer. At this stage const strings uses 290 words, or about 7.1% of total Flash.

--
Brent Brown, Electronic Design Solutions
16 English Street, St Andrews,
Hamilton 3200, New Zealand
Ph: +64 7 849 0069
Fax: +64 7 849 0071
Cell: 027 433 4069
eMail:  KILLspambrent.brownKILLspamspamclear.net.nz


2006\08\28@215627 by Brent Brown

picon face
On 29 Aug 2006 at 13:46, Jinx wrote:

> > Yes, interesting. Google finds parts suppliers that list a PIC16F89,
> > although I'm  wondering if they're just typo's.
>
> Showing pin-outs is a major typo !! Could be someone's idea of
> a joke of course. Or escaped info on a planned product that never got
> off the drawing board
>
> I'm enquiring at Microchip. 16F89 doesn't appear in any of
> the drop-downs, so the answer will probably be what we think
> it's going to be

In that case don't forget to tell them what we want it to be. 8K words of Flash
please! Oh, and it would also be nice if we could run it at more than 4MHz at low
voltage.

--
Brent Brown, Electronic Design Solutions
16 English Street, St Andrews,
Hamilton 3200, New Zealand
Ph: +64 7 849 0069
Fax: +64 7 849 0071
Cell: 027 433 4069
eMail:  RemoveMEbrent.brownTakeThisOuTspamclear.net.nz


2006\08\28@215924 by Xiaofan Chen

face picon face
On 8/28/06, Jinx <spamBeGonejoecolquittspamBeGonespamclear.net.nz> wrote:
> > Yes, interesting. Google finds parts suppliers that list a PIC16F89,
> > although I'm  wondering if they're just typo's.
>
> Showing pin-outs is a major typo !! Could be someone's idea of
> a joke of course. Or escaped info on a planned product that never
> got off the drawing board
>
> I'm enquiring at Microchip. 16F89 doesn't appear in any of
> the drop-downs, so the answer will probably be what we think
> it's going to be
>

Remember the 8-pin 18F010 and 18F020? I even had the
printed datasheet but it never hits the market...
www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=2018&mcparam=en013478

2006\08\28@225437 by Jinx

face picon face
> Remember the 8-pin 18F010 and 18F020?

The confident use of the present tense would make one
assume they were a done deal. Pity they never did go
ahead with a high speed 8-pin. Maybe not cost-effective
or justified compared with something like a 1220 or 675

2006\08\28@233316 by Robert Ammerman

picon face
What is the total length of all your menu text?

I ask this question because it indicates the feasibility / desirability of
using some Really Sneaky Tricks (TM) to crunch down the space required. You
run a program on a PC to take your library of strings and compress it (many
different algorithms can be used). This program then outputs a sequence of
DB statements that just look like gibberish. A decompressor written for the
PIC then extracts the data you want. Obviously you need to take into account
the size of the decompression routine to determine if this is a win or not.

Remember, that you have incredibly powerful resources on the PC to crunch
and optimize the data. You just have to do so into a form that can be
cheaply decoded on the PIC.

An example of a compression scheme that has the characteristic that
compression is expensive but decompression is almost free is LZSS.

Another example is one I used to be able to pack about 15 pounds of text
onto a 5 pound floppy disk:

-  The basic idea was to crunch the text into a sequence of one and two byte
codes that an interpreter could use to recreate the text. -

The one-byte codes always had the MSBit set, the two-byte codes had it
clear.

Some of the one-byte codes represented short stringns that had a very high
occurance rate in the input data. They were string (not byte) indexes into a
pseudo-array of strings that was stored as one long string with nulls
between the pseudo array elements.
Other one-byte codes were used to indicate runs of a single character, or
the start of a counted string of characters that couldn't be effectively
compressed.

The two-byte codes represented a word and possibly characters following it.
In my particular data, words were nearly always followed by either:

(1) a space
(2) a comma
(3) a comma and a space
(4) the end of a "record"

I represented the four cases above using two bits out of the 16 bits in the
two-byte code. After deducting the top bit that is always clear in the
two-byte codes this leaves 13 bits or 8192 values to indicate a particular
word. These 8192 values Then served as an index into two tables. The first
table defined the offset into a large string (the dictionary) where the word
begain, the second (which was defined as nibbles instead of bytes) deifned
the length of the word. One neat aspect was that the compression program on
the PC could look for ways to nest words in the dictionary. This reduced the
raw size of the dictionary by about 20%. For example: if one of the words
was "internationalize" and others were "interrn', "nation", "national" and
"nationalize" then the latter four could all be embedded n the first one!

"So, this sentence might be coded using the above system as something like
this."

1 byte code indicating that four uncomprssed btyes are to follow:
The uncompressed 4 bytes "So, "
2 byte code for dictionary word  "this "
2 byte code for dictionary word "sentence "
2 byte code for dictionary word "might "
1 byte code for common string "be "
2 byte code for dictionary word "coded "
2 byte code for dictoinary work "using"
1 byte code for common string
1 byte code for common string "as "
2 byte code for dictionary word "something "
2 byte code for dictionary word "liike "
2 byte code for dictionary word "this"
1 byte  code for common string "."

Thus, this string compresses down from 79 characters to 18 bytes (not
counting resources shared by many strings like dictionary and the pointers
to it and the table of "very common strings"

Bob Ammerman
RAm  Systems

2006\08\28@233816 by Robert Ammerman

picon face
Adding the two extra pins might make sense if the die had to be enough
larger to contain 8K of flash that it pushed the package size large.

Bob Amnerman
RAm Systems

----- Original Message -----
From: "Jinx" <TakeThisOuTjoecolquittEraseMEspamspam_OUTclear.net.nz>
To: "Microcontroller discussion list - Public." <RemoveMEpiclistspamTakeThisOuTmit.edu>
Sent: Monday, August 28, 2006 5:02 AM
Subject: Re: [PIC] PIC16F88 too small


>> What is a PIC16F89
>
> Dunno, but this looks to have been lifted from a d/s
>
> http://micropic.free.fr/16F89.jpg
>
> Same as an F88 with C0 and C1 in the middle
>
> --

2006\08\28@233816 by Robert Ammerman

picon face
> Already doing that as the LCD display and keypad is remote and it has it's
> own
> PIC16F88, with comms over an RS232 like interface. I send instructions
> like "put
> this string of characters on line 2".

Why not change the interface to "Display strinig 1 on line 2" and store all
your strings in the other PIC.

{Quote hidden}

> --

2006\08\29@000043 by Jinx

face picon face
Problem Description:
Does the 16F89 exist ?

Problem Resolution:

Hi,

PIC16F89 doesn't exist at present

'nuff said

2006\08\29@000240 by William Chops Westfield

face picon face

On Aug 28, 2006, at 7:54 PM, Jinx wrote:

> Pity they never did go ahead with a high speed 8-pin.

PIC12F635 and PIC12F683 seem to be real, and have the nanowatt
oscillator that goes 8MHz...

BillW

2006\08\29@001952 by Brent Brown

picon face
On 28 Aug 2006 at 23:35, Robert Ammerman wrote:
> > Already doing that as the LCD display and keypad is remote and it
> > has it's own PIC16F88, with comms over an RS232 like interface. I
> > send instructions like "put this string of characters on line 2".
>
> Why not change the interface to "Display strinig 1 on line 2" and
> store all your strings in the other PIC.

I guess that's a possibility. So far I've kept the keypad/display unit as much like a
"dumb terminal" as possible, so it's less likely to need firmware updates when things
change. Source code is also easier to read, eg.  LCD_Line2("Hello") compared to
LCD_(STRING1, LINE2).

--
Brent Brown, Electronic Design Solutions
16 English Street, St Andrews,
Hamilton 3200, New Zealand
Ph: +64 7 849 0069
Fax: +64 7 849 0071
Cell: 027 433 4069
eMail:  EraseMEbrent.brownspamclear.net.nz


2006\08\29@002125 by Brent Brown

picon face
On 28 Aug 2006 at 23:29, Robert Ammerman wrote:
> What is the total length of all your menu text?
>
> I ask this question because it indicates the feasibility /
> desirability of using some Really Sneaky Tricks (TM) to crunch down
> the space required....

About 270 characters at present, some in LCD display text, other's in serial
command strings and debug output. Mostly short strings 3-5 chars long, LCD is only  
2 x 8. That also seems to be why Hi-Tech PICC doesn't pack 2 into a word - strings
need to be about 30 chars or more long before it deems it efficient to do so (added
code overhead I guess). I like your ideas for compression. Will do my best though
to just do Sneaky Tricks for now and avoid the Really Sneaky Tricks because time
is against me.

--
Brent Brown, Electronic Design Solutions
16 English Street, St Andrews,
Hamilton 3200, New Zealand
Ph: +64 7 849 0069
Fax: +64 7 849 0071
Cell: 027 433 4069
eMail:  RemoveMEbrent.brownEraseMEspamEraseMEclear.net.nz


2006\08\29@035954 by Vasile Surducan

face picon face
On 8/28/06, Stef Mientki <RemoveMES.Mientkispam_OUTspamKILLspamru.nl> wrote:
>
>
> Rolf wrote:
>
> >Have a look at:
> >
> >file:///C:/Repository/NikonSB/StringFormat.html
> >
> >
> nice, but how can I reach your C-disk ;-)
> Stef

DHL ?

Vasile

2006\08\29@091035 by Timothy Weber

face picon face
Brent Brown wrote:
> On 28 Aug 2006 at 23:29, Robert Ammerman wrote:
>> What is the total length of all your menu text?
>>
>> I ask this question because it indicates the feasibility /
>> desirability of using some Really Sneaky Tricks (TM) to crunch down
>> the space required....
>
> About 270 characters at present, some in LCD display text, other's in serial
> command strings and debug output. Mostly short strings 3-5 chars long, LCD is only  
> 2 x 8. That also seems to be why Hi-Tech PICC doesn't pack 2 into a word - strings
> need to be about 30 chars or more long before it deems it efficient to do so (added
> code overhead I guess). I like your ideas for compression. Will do my best though
> to just do Sneaky Tricks for now and avoid the Really Sneaky Tricks because time
> is against me.

One Trick I've used that's only Slightly Sneaky is to use the high bit
to indicate the last char of a string, instead of a terminating null.
If you have 270 characters of ~4 char strings, that's a savings of 54
bytes.  Not a lot, but maybe helpful.

Not useful if you have other than ASCII characters in your strings, of
course.
--
Timothy J. Weber
http://timothyweber.org

2006\08\29@122528 by Bob Axtell

face picon face
I used a form of RLE to save space on a PIC12C672.

It turns out that I had to store IR control codes into a variable-length
table. On a hunch, I
grabbed an 40Khz IR Receiver and stored the bits into 1's or 0's,
captured every 100uS,
then stored into a RAMTRON 32Kx8. I noticed that I could reduce every
code down to
about 10 bytes average, by indicating  in a single byte  a '1'(+ count
remaining in that state)
or a '0' (+ count remaining in that state). I then squeezed it into an
8-bit simple RETLW table
for each IR code. I was able to store a large set of IR
codes that way.

--Bob


Robert Ammerman wrote:
{Quote hidden}

Good work, Bob.

{Quote hidden}

2006\08\29@123825 by Tamas Rudnai

face picon face
Also you could use other encoding than ASCII and you can convert them back
on the fly. So for example if you have English text with 28 letters you can
store it in 5 bits. Let's say b'00000' and b'11111' have special meaning (0
is for terminating, full 1 is for escaping. If you have other char than the
standard English ABC but not too often then you can apply the escape and a
full 8 bit value for that.

Calculus: let's say you have 4 char length in average, so 270*4 = 1080.
That's the size if you are using the upper bit as termination as suggested.
If you still using 0 as termination then you have 1350 bytes to store. It is
1350*5 bit in my suggestion, which is ~844 bytes.

You can go further by not storing each chars, but storing the first char
then the 'distance' between the chars. So that 'apple' is encoded in ASCII
as 0x61 0x70 0x70 0x6c 0x65, so you write down 0x61, then 0x0f 0x00 -0x04
-0x07. If you say that you store 3 bits and the sign bit then you can store
many things in 4 bits only and you can use 0 as an escape as not too many
double chars are there. Depending on the text you could store your stuff
around 7k.

If you combine it with a standard compression suggested then you could go
pretty much down.

Tamas


On 29/08/06, Timothy Weber <RemoveMEtwTakeThisOuTspamspamtimothyweber.org> wrote:
{Quote hidden}

> -

2006\08\29@124050 by Tamas Rudnai

face picon face
Sorry, I mean 7 hundred, not K :-)

On 29/08/06, Tamas Rudnai <EraseMEtamas.rudnaispamspamspamBeGonegmail.com> wrote:
{Quote hidden}

2006\08\29@125248 by David VanHorn

picon face
On 8/27/06, Brent Brown <brent.brownSTOPspamspamspam_OUTclear.net.nz> wrote:
>
> What do you do when you've run out of program space in a PIC16F88? I'm
> looking
> through the Microchip website but can't find anything ideal yet. The
> perfect solution
> would be a drop in pin compatible chip with all the same features but 8K
> words of
> Flash instead of 4K.


Write better code?  Switch to assembler?  :)

2006\08\29@184609 by Robert Ammerman

picon face
> change. Source code is also easier to read, eg.  LCD_Line2("Hello")
> compared to
> LCD_(STRING1, LINE2).
>
> --
> Brent Brown, Electronic Design Solutions


With a simple PC-based tool you could generate the code for the slave system
and at the same time generate a header file for the master that would give
you meaningful symbols (#defines) for the strings.

Bob Ammerman

2006\08\29@185732 by Scott Dattalo

face
flavicon
face
Dennis Crawley wrote:

> I've tried four CRC8 routines in Keil C51 for a 8051 core:

Hi Dennis,

Thanks for trying this out. The 30 instruction Keil rendition of the
crc_bits() routine would probably be closer to 20 instructions if the
8051 had a "bit test and skip" type instruction like the PIC.

Regards,
Scott

2006\08\30@004040 by William Chops Westfield

face picon face

On Aug 28, 2006, at 9:02 PM, William Chops Westfield wrote:

> PIC12F635 and PIC12F683 seem to be real, and have the nanowatt
> oscillator that goes 8MHz...
>
Hmm.  And the f683 (with lead) is on sale at microchip direct,
for cheaper than the 675 sells for normally (despite having more
flash and eeprom as well as the nanowatt clock, timer2, and pwm.)
I think I'll buy some!

BillW

2006\08\30@005449 by William Chops Westfield

face picon face

On Aug 29, 2006, at 9:38 AM, Tamas Rudnai wrote:

> for example if you have English text with 28 letters you can
> store it in 5 bits.

And of course there is a standard 5-bit code that handles most
numerics and punctuation as well ("Baudot"), as well as semi-standard
mechanisms for 6 "symbol" characters in 32bits ("Radix50"); stuff
from the days when mainframes had a whole megabyte of core and
space mattered.  It's a common enough problem that developing a
full custom solution is probably something that should only be
done when you're REALLY desparate.

(now, decoding radix50 and writing to an ascii LCD on a processor
without divide might be a good topic for a coding challenge...)

BillW

2006\08\30@015552 by Brent Brown

picon face
Looks like the PIC16F886 might be available now. I just got a quote from Arrow
showing a lead time of 11 weeks. They are not listed on MicrochipDirect yet.

Points of interest are that they have 8K words of Flash (yeah!), and can run at
8MHz at 2V. Not sure if they lack anything compared to a PIC16F88. It doesn't say
"Enhanced Flash" but apparently can read/write it's own Flash.

--
Brent Brown, Electronic Design Solutions
16 English Street, St Andrews,
Hamilton 3200, New Zealand
Ph: +64 7 849 0069
Fax: +64 7 849 0071
Cell: 027 433 4069
eMail:  spamBeGonebrent.brownSTOPspamspamEraseMEclear.net.nz


2006\08\30@024510 by Wouter van Ooijen

face picon face
> Looks like the PIC16F886 might be available now.

but http://ww1.microchip.com/downloads/en/DeviceDoc/41287A.pdf decsribes
it as an 28-pin device, so I don't see how it would help somone running
out of F88 code space (or at least, not better than a 16F876A).

Wouter van Ooijen

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


2006\08\30@030009 by Brent Brown

picon face
> > Looks like the PIC16F886 might be available now.
>
> but ww1.microchip.com/downloads/en/DeviceDoc/41287A.pdf
> decsribes it as an 28-pin device, so I don't see how it would help
> somone running out of F88 code space (or at least, not better than a
> 16F876A).

True, I forgot to mention that. It helps me in this case because I'm already using the
PIC16F88 in a 28 pin QFN package, so a PIC16F886 won't take up any more board
space. The PIC16F876A is nice but doesn't have the internal oscillator.

--
Brent Brown, Electronic Design Solutions
16 English Street, St Andrews,
Hamilton 3200, New Zealand
Ph: +64 7 849 0069
Fax: +64 7 849 0071
Cell: 027 433 4069
eMail:  KILLspambrent.brownspamBeGonespamclear.net.nz


2006\08\30@035131 by Alan B. Pearce

face picon face
>The one thing that pushed me over the top was adding CRC
>checking for my 1 wire temperature sensors -  needed it
>because I'm getting the occasional erroneous result.
>This adds about 300 program words.

How often does this code run? Could you set a compiler switch to optimise
for size (but it may run a bit slower) for this section?

2006\08\30@043911 by Alan B. Pearce

face picon face
>So for example if you have English text with
>28 letters you can store it in 5 bits.

Oh, you mean like Baudot ... In Brents case he could then have the Baudot to
ASCII translation done in the second chip that controls the LCD ...

2006\08\30@051635 by Brent Brown

picon face
> >The one thing that pushed me over the top was adding CRC
> >checking for my 1 wire temperature sensors -  needed it
> >because I'm getting the occasional erroneous result.
> >This adds about 300 program words.
>
> How often does this code run? Could you set a compiler switch to
> optimise for size (but it may run a bit slower) for this section?

Executes every 750ms (DS18B22 temp sensor in 12 bit mode). But I've got that
section sorted now thanks. I took out the table driven CRC routine (256 words were
used by the table) and used a full CRC calculator routine... more machine cycles
but much less code space (approx 34 words now).

--
Brent Brown, Electronic Design Solutions
16 English Street, St Andrews,
Hamilton 3200, New Zealand
Ph: +64 7 849 0069
Fax: +64 7 849 0071
Cell: 027 433 4069
eMail:  EraseMEbrent.brownspamEraseMEclear.net.nz


2006\08\30@121837 by Tamas Rudnai

face picon face
Well, Bill and Alan,

Yes, Baudot if you have to be compatible :-) but as Baudot code was
organized to have less stress on the TTY writer that is no any sense for the
human (like ASCII uses a human based ABC ordered encoding). But still I
think with 2 * 32 table it can be done without too much effort. If you would
like to avoid those tables (to save space) you have to use  ABC orders with
the same principals so that few simple instruction could convert it to
ASCII.

Tamas


On 30/08/06, Alan B. Pearce <@spam@A.B.Pearce@spam@spamspam_OUTrl.ac.uk> wrote:
>
> >So for example if you have English text with
> >28 letters you can store it in 5 bits.
>
> Oh, you mean like Baudot ... In Brents case he could then have the Baudot
> to
> ASCII translation done in the second chip that controls the LCD ...
>
> -

2006\08\31@040515 by John Chung

picon face
I believe one would reduce the size using serial
through I2C. I am not sure though.

John

--- Maarten Hofman <spamBeGonecashimorspamKILLspamgmail.com> wrote:

{Quote hidden}

> --

2006\08\31@202023 by Howard Winter

face
flavicon
picon face
Bill,

On Tue, 29 Aug 2006 21:54:41 -0700, William "Chops" Westfield wrote:

{Quote hidden}

Errr - when I got my first job on a mainframe (1974) Baudot was already ancient (it was used on teleprinters long before computers) - and that
mainframe had 96k of memory!  After a couple of years it was upgraded to 320k - megabytes were only a dream on commercial computers  :-)

Cheers,


Howard Winter
St.Albans, England


More... (looser matching)
- Last day of these posts
- In 2006 , 2007 only
- Today
- New search...