Searching \ for '[PIC]: 16F84 serial buffering more than 62 byte' 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/ios.htm?key=serial
Search entire site for: '16F84 serial buffering more than 62 byte'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: 16F84 serial buffering more than 62 byte'
2000\11\02@073646 by Bob Ammerman

picon face
Phil,

Sorry, there are only 68 bytes of RAM on a 'F84.

The reference in the data sheet to 'more than 116 bytes' is to the
architectural arrangement of multiple banking which is shared by many of the
16C PICs. Without multiple banks there would only be 128 (ie: 2^7) bytes of
address space, minus 12 bytes of SFR's gives 116 bytes of RAM maximum
(architecturally).

For another 18 pin PIC with more room you might try:

the flash-based PIC16F627 (which is marked as 'future product' in the Q3
linecard, so good luck getting them).

or one of the following non-flash parts:

PIC16C554 (80 bytes of RAM)

PIC16C558 (128 bytes of RAM)

PIC16C620 (80 bytes of RAM)

PIC16C620A (96 bytes of RAM)

etc.

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)

{Original Message removed}

2000\11\02@101643 by Bob Ammerman

picon face
Another thought:

If your message is 7-bit ascii you can use the high order bit of each group
of 7 bytes to store an 8th character.

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)

{Original Message removed}

2000\11\02@222918 by Brett Testerman

flavicon
face
Is the data real random or is there regular patterns to it? How about a huffman
(not sure if that is spelled right) encoding scheme? Easy to implement and if
certain byte values occur more than others it would be real easy to pick up
those 10 missing bytes.

Of course, if  the data is real random, then it would become a case of it
working for some of the messages, but there could be no guarantee for all.

Brett


Bob Ammerman wrote:

> Another thought:
>
> If your message is 7-bit ascii you can use the high order bit of each group
> of 7 bytes to store an 8th character.
>
> Bob Ammerman
> RAm Systems
> (contract development of high performance, high function, low-level
> software)
>
> {Original Message removed}

2000\11\03@071238 by Bob Ammerman

picon face
----- Original Message -----
From: Brett Testerman <spam_OUTbtest1TakeThisOuTspamNEWSGUY.COM>
To: <.....PICLISTKILLspamspam@spam@MITVMA.MIT.EDU>
Sent: Thursday, November 02, 2000 10:32 PM
Subject: Re: [PIC]: 16F84 serial buffering more than 62 bytes


> Is the data real random or is there regular patterns to it? How about a
huffman
> (not sure if that is spelled right) encoding scheme? Easy to implement and
if
> certain byte values occur more than others it would be real easy to pick
up
> those 10 missing bytes.
>
> Of course, if  the data is real random, then it would become a case of it
> working for some of the messages, but there could be no guarantee for all.
>
> Brett
>
Unfortunately just about every compression scheme, except perhaps run-length
encoding, tends to require some pretty big data structures (at least in PIC
terms) to store the compressor/decompressor state.

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:","[SX]:","[AVR]:" =uP ONLY! "[EE]:","[OT]:" =Other "[BUY]:","[AD]:" =Ads




2000\11\03@102737 by jamesnewton

face picon face
www.piclist.com/../method/compress/embedded.htm

http://www.piclist.com/../method/compress.htm

Might help if you decide that there is some benefit to be derived from
compression.

---
James Newton (PICList Admin #3)
jamesnewtonspamKILLspampiclist.com 1-619-652-0593
PIC/PICList FAQ: http://www.piclist.com or .org

{Original Message removed}

2000\11\03@104222 by Brett Testerman

flavicon
face
If you knew the frequency of each byte value, a huffman table could be implemented
in rom. I don't think you could implement an adaptive method on a PIC. But I would
say a simple huffman, code and data, could be done in less than 1k of rom space.

Brett

Bob Ammerman wrote:

> {Original Message removed}

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