Searching \ for '[PIC]: Hitech PICCLITE state machine optimization' 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=pic
Search entire site for: 'Hitech PICCLITE state machine optimization'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: Hitech PICCLITE state machine optimization'
2004\01\29@211947 by Herbert Graf

picon face
Hello all, been trying to implement a state machine using PICCLITE and am
encountering BIG code. I was wondering if anyone might have some ideas as to
how I could implement a state machine more efficiently.

For example this is an excerpt of my state machine:

               if ((ISR_state == 7)
                       || (ISR_state == 8)
                       || (ISR_state == 9)
                       || (ISR_state == 10)
                       || (ISR_state == 11)
                       || (ISR_state == 12)
                       || (ISR_state == 13))
               {
                       if (ISR_charBuf == 0x0d)
                               ISR_state = 0;
                       else if (ISR_charBuf == ',')
                               ISR_state++;
               }

Any ideas as to how I might do the same sort of thing without using so much
code?

I had a look at the assembly on another section of the state machine where
it's even worse:

if ((ISR_state == 1 && ISR_charBuf == 'P')

  380  0036  0822                      movf    _ISR_state,w
  381  0037  3A02                      xorlw   2
  382  0038  1D03                      btfss   3,2
  383  0039  283E                      goto    u191
  384  003A  0821                      movf    _ISR_charBuf,w
  385  003B  3A50                      xorlw   80
  386  003C  1903                      btfsc   3,2
  387  003D  286E                      goto    u440

Ouch! :) Thanks for any help, TTYL

----------------------------------
Herbert's PIC Stuff:
http://repatch.dyndns.org:8383/pic_stuff/

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

.

2004\01\29@213239 by Brent Brown

picon face
For the first part you could try the follwing adn see what if it produces tighter
code:

switch(ISR_state){
       case 7:
       case 8:
       case 9:
       case 10:
       case 11:
       case 12:
       case 13:
               code.....
               break;
}

On 29 Jan 2004 at 21:18, Herbert Graf wrote:

{Quote hidden}

--
Brent Brown, Electronic Design Solutions
16 English Street, Hamilton, New Zealand
Ph/fax: +64 7 849 0069
Mobile/txt: 025 334 069
eMail:  spam_OUTbrent.brownTakeThisOuTspamclear.net.nz

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

.

2004\01\29@234122 by Bill Couture

picon face
On Thu, 29 Jan 2004, Herbert Graf wrote:

> For example this is an excerpt of my state machine:
>
>                 if ((ISR_state == 7)
>                         || (ISR_state == 8)
>                         || (ISR_state == 9)
>                         || (ISR_state == 10)
>                         || (ISR_state == 11)
>                         || (ISR_state == 12)
>                         || (ISR_state == 13))
>                 {
>                         if (ISR_charBuf == 0x0d)
>                                 ISR_state = 0;
>                         else if (ISR_charBuf == ',')
>                                 ISR_state++;
>                 }
>
> Any ideas as to how I might do the same sort of thing without using so much
> code?

How about
if ((ISR_state > 6) && (ISR_state < 14))
   {
   if (ISR_charBuf == 0x0d)
      ISR_state = 0;
   if (ISR_charBuf == ',')  /* can't be 0x0d and ',' at the same time */
      ISR_state++;
   }

Bill

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

.

2004\01\30@020702 by Herbert Graf

flavicon
face
> How about
>  if ((ISR_state > 6) && (ISR_state < 14))
>     {
>     if (ISR_charBuf == 0x0d)
>        ISR_state = 0;
>     if (ISR_charBuf == ',')  /* can't be 0x0d and ',' at the same time */
>        ISR_state++;
>     }
>
> Bill

       Hmm, that's one of those obvious ideas, that isn't obvious until somebody
mentions it to you! :) That one saved me 8 words, not much but something.
Thanks, TTYL

----------------------------------
Herbert's PIC Stuff:
http://repatch.dyndns.org:8383/pic_stuff/

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email .....listservKILLspamspam@spam@mitvma.mit.edu with SET PICList DIGEST in the body

.

2004\01\30@031625 by Rob Hamerling

flavicon
face
Herbert Graf wrote:

> I had a look at the assembly on another section of the state machine where
> it's even worse:
>
> if ((ISR_state == 1 && ISR_charBuf == 'P')
>
>    380  0036  0822                      movf    _ISR_state,w
>    381  0037  3A02                      xorlw   2
>    382  0038  1D03                      btfss   3,2
>    383  0039  283E                      goto    u191
>    384  003A  0821                      movf    _ISR_charBuf,w
>    385  003B  3A50                      xorlw   80
>    386  003C  1903                      btfsc   3,2
>    387  003D  286E                      goto    u440
>
> Ouch! :) Thanks for any help, TTYL

Why do you say 'worse' and why 'ouch'??
You did not mention any requirements (timing, memory space, etc). If
there are no such requirements and the code works as expected, then you
are done, and optimisation is a waste of time.

Regards, Rob.

--
Rob Hamerling, Vianen, NL phone +31-347-322822
homepage: http://www.robh.nl/

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservspamKILLspammitvma.mit.edu with SET PICList DIGEST in the body

.

2004\01\30@035229 by SCII?B?VHVncnVsIEdVQ0xV?=

flavicon
face
First of all , this code may not work properly becaseu switch statement
executes one state in each iteration but you want several statements to be
considered as one state(buecause you used ||)


switch(ISR_state){
       case 7:
       case 8:
       case 9:
       case 10:
       case 11:
       case 12:
       case 13:
               code.....
               break;

But You might try sth like this

for(int i = 0 ; i < 7; i++)
{
if(ISR_state == 7+i)
{
       swithc(ISR_charBuf )
       {
               case 0x0d: ISR_state = 0;
                       break;
               case ','    : ISR_state += 1;
                       break;
       }
}

}

}

I dont think this will increment code performance very  much but decreasese
siclomatic complexity

{Original Message removed}

2004\01\30@041546 by hael Rigby-Jones

picon face
>-----Original Message-----
>From: Herbert Graf [.....hgrafKILLspamspam.....EMAIL.COM]

>I had a look at the assembly on another section of the state
>machine where it's even worse:
>
>if ((ISR_state == 1 && ISR_charBuf == 'P')
>
>   380  0036  0822                      movf    _ISR_state,w
>   381  0037  3A02                      xorlw   2
>   382  0038  1D03                      btfss   3,2
>   383  0039  283E                      goto    u191
>   384  003A  0821                      movf    _ISR_charBuf,w
>   385  003B  3A50                      xorlw   80
>   386  003C  1903                      btfsc   3,2
>   387  003D  286E                      goto    u440
>
>Ouch! :) Thanks for any help, TTYL

You are looking in the wrong place in the list file. That assembly listing
does not do the same thing as the line of C.

The Hitech compiler is actually very good at optimising, it would not usualy
use a generic XOR method to compare to 0x01.  In fact I have just tested
this on my copy of PICC

   29  07F5  0B21                      decfsz  _ISR_state,w
   30  07F6  2FF5                      goto    L4
   31  07F7  0820                      movf    _ISR_charBuf,w
   32  07F8  3A50                      xorlw   80
   33  07F9  1D03                      btfss   3,2
   34  07FA  2FF5                      goto    L4

I don't understand why you are so concerned with the output of the compiler,
even using the XOR code it hardly seems like an excessively bloated
implementation. If your timing/space constraints are that tight, you should
probably be coding in assembly anyway.

Regards

Mike




=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================
Any questions about Bookham's E-Mail service should be directed to
EraseMEpostmasterspam_OUTspamTakeThisOuTbookham.com.

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservspamspam_OUTmitvma.mit.edu with SET PICList DIGEST in the body

.

2004\01\30@044113 by Bob Barr

flavicon
face
On Thu, 29 Jan 2004 21:18:54 -0500, Herbert Graf wrote:

{Quote hidden}

Are state machines implemented in C that much differently than the way
I was taught to do them in assembly language? Isn't there separate
code that gets executed based on the state variable? Once a state's
code is being executed, there's no need to check the state variable
again.

If this is the case, you could call a common exit function from each
state to detect the carriage-return and comma characters. (At a
minimum, you could test for the state variable being greater than 6
and less than 14 rather than testing for the individual values.).

{Quote hidden}

I can see how the 'xorlw 80' is checking for the character being 'P'
but how in the world can an 'xorlw 2' possibly check for the state
variable being 1? That line makes no sense to me. Am I missing
something obvious?


Regards, Bob

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email @spam@listservKILLspamspammitvma.mit.edu with SET PICList DIGEST in the body

.

2004\01\30@084731 by Herbert Graf

flavicon
face
{Quote hidden}

       Umm, it was pretty obvious (at least to most others here) I was concerned
about the number of words a simple line like what is above generates.

       Timing doesn't matter, it's code space that I'm concerned with. I'm
wondering if there is a more efficient way to encode a state machine using
Hitech PICCLITE. Thanks, TTYL

----------------------------------
Herbert's PIC Stuff:
http://repatch.dyndns.org:8383/pic_stuff/

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email KILLspamlistservKILLspamspammitvma.mit.edu with SET PICList DIGEST in the body

.
Return-Path: <>
Received: from mitvma.mit.edu ([18.92.0.3]) by tomts3-srv.bellnexxia.net
         (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP
         id <RemoveME20040128014312.FECG1829.tomts3-srv.bellnexxia.netTakeThisOuTspammitvma.mit.edu>>          for <spamBeGonepiclist_errorsspamBeGonespamSYMPATICO.CA>;
         Tue, 27 Jan 2004 20:43:12 -0500
Received:  by mitvma.mit.edu (IBM VM SMTP Level 430) via spool with SMTP id 6135 ; Tue, 27 Jan 2004 20:43:08 EST
Received: from MITVMA.MIT.EDU (NJE origin LISTSERV@MITVMA) by MITVMA.MIT.EDU (LMail V1.2d/1.8d) with BSMTP id 3110; Tue, 27 Jan 2004 20:43:09 -0500
Date:         Tue, 27 Jan 2004 20:43:08 -0500
From:         "L-Soft list server at MITVMA.MIT.EDU (1.8e)"
             <TakeThisOuTLISTSERVEraseMEspamspam_OUTMITVMA.MIT.EDU>
Subject: PICLIST: error report from YAHOO.COM
To:           RemoveMElistsjoshspamTakeThisOuT3MTMP.COM,
             piclist_errorsEraseMEspam.....SYMPATICO.CA
Message-ID:   <LISTSERV%EraseME2004012720430849spamMITVMA.MIT.EDU>
X-LSV-ListID: None

The enclosed message has been identified as a delivery error for the PICLIST
list because it was sent to 'RemoveMEowner-piclistEraseMEspamEraseMEMITVMA.MIT.EDU'.

------------------------------ Message in error -------------------------------
Received: from MITVMA (NJE origin SMTP@MITVMA) by MITVMA.MIT.EDU (LMail
         V1.2d/1.8d) with BSMTP id 3108; Tue, 27 Jan 2004 20:43:08 -0500
Received: from mta441.mail.yahoo.com [216.136.129.96] by mitvma.mit.edu (IBM VM
         SMTP Level 430) via TCP with SMTP ; Tue, 27 Jan 2004 20:43:08 EST
X-Comment: mitvma.mit.edu: Mail was sent by mta441.mail.yahoo.com
From: RemoveMEMAILER-DAEMONspam_OUTspamKILLspamyahoo.com
To: RemoveMEowner-piclistTakeThisOuTspamspammitvma.mit.edu
X-Loop: EraseMEMAILER-DAEMONspamspamspamBeGoneyahoo.com
Subject: Delivery failure

Message from yahoo.com.
Unable to deliver message to the following address(es).

<RemoveMEhbarregrdKILLspamspamyahoo.com>:
Sorry, your message to hbarregrdSTOPspamspamspam_OUTyahoo.com cannot be delivered.  This account is over quota.

--- Original message follows.

Return-Path: <spamBeGoneowner-piclistSTOPspamspamEraseMEmitvma.mit.edu>
Received: from 209.119.0.109  (EHLO cherry.ease.lsoft.com) (209.119.0.109)
 by mta441.mail.yahoo.com with SMTP; Tue, 27 Jan 2004 13:42:03 -0800
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <KILLspam12.00CBF6C5spamBeGonespamcherry.ease.lsoft.com>; Tue, 27 Jan 2004 13:24:56 -0500
Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (LISTSERV-TCP/IP release 1.8e)
         with spool id 0113 for EraseMEPICLISTspamEraseMEMITVMA.MIT.EDU; Tue, 27 Jan 2004
         13:24:50 -0500
Received: from MITVMA (NJE origin SMTP@MITVMA) by MITVMA.MIT.EDU (LMail
         V1.2d/1.8d) with BSMTP id 0683; Tue, 27 Jan 2004 13:23:38 -0500
Received: from pd3mo2so.prod.shaw.ca [24.71.223.10] by mitvma.mit.edu (IBM VM
         SMTP Level 430) via TCP with ESMTP ; Tue, 27 Jan 2004 13:23:37 EST
X-Comment: mitvma.mit.edu: Mail was sent by pd3mo2so.prod.shaw.ca
Received: from pd2mr2so.prod.shaw.ca (pd2mr2so-ser.prod.shaw.ca [10.0.141.109])
         by l-daemon (iPlanet Messaging Server 5.2 HotFix 1.18 (built Jul 28
         2003)) with ESMTP id <0HS5000I8U1SSW@l-daemon> for
         @spam@PICLIST@spam@spamspam_OUTMITVMA.MIT.EDU; Tue, 27 Jan 2004 11:01:04 -0700 (MST)
Received: from pn2ml7so.prod.shaw.ca (pn2ml7so-qfe0.prod.shaw.ca
         [10.0.121.151]) by l-daemon (iPlanet Messaging Server 5.2 HotFix 1.18
         (built Jul 28 2003)) with ESMTP id <0HS500A0HU1TAY@l-daemon> for
         spamBeGonePICLISTspamKILLspamMITVMA.MIT.EDU; Tue, 27 Jan 2004 11:01:05 -0700 (MST)
Received: from UALBERTA.ca (h24-65-14-55.ed.shawcable.net [24.65.14.55]) by
         l-daemon (iPlanet Messaging Server 5.2 HotFix 1.18 (built Jul 28
         2003)) with ESMTP id <0HS500M0FU1S9Z@l-daemon> for
         .....PICLISTspam_OUTspamMITVMA.MIT.EDU; Tue, 27 Jan 2004 11:01:05 -0700 (MST)
MIME-version: 1.0
X-Mailer: Mozilla 4.76 [en] (Win98; U)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
X-Accept-Language: en
References: <TakeThisOuTE1AlWmG-0000Es-BU.....spamTakeThisOuTsmtp.aaisp.net.uk>
Message-ID:  <TakeThisOuT4016A776.82C2B431KILLspamspamspamUALBERTA.ca>
Date:         Tue, 27 Jan 2004 11:01:26 -0700
Reply-To:     pic microcontroller discussion list <.....PICLISTspamRemoveMEMITVMA.MIT.EDU>
Sender:       pic microcontroller discussion list <RemoveMEPICLISTspamspamBeGoneMITVMA.MIT.EDU>
From:         Robert Rolf <spamBeGoneRobert.Rolf@spam@spamspam_OUTUALBERTA.CA>
Organization: U of Alberta
Subject: Re: [OT]: Flash memory & Spirt. Ceitgeist
To:           TakeThisOuTPICLISTspamspamMITVMA.MIT.EDU
Precedence: list

Howard Winter wrote:
{Quote hidden}

50-cent is the name of a very popular American Rap music group.

who on
> Earth is Kobe Bryant?  And why did they get in the top-10 in two categories?

An American basketball star accused of rape of a hotel worker. He claims innocence.

And why was Britney Spears the number one image search? Has the world no taste?

R

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

2004\01\30@084939 by Herbert Graf

flavicon
face
> >I had a look at the assembly on another section of the state
> >machine where it's even worse:
> >
> >if ((ISR_state == 1 && ISR_charBuf == 'P')
> >
> >   380  0036  0822                      movf    _ISR_state,w
> >   381  0037  3A02                      xorlw   2
> >   382  0038  1D03                      btfss   3,2
> >   383  0039  283E                      goto    u191
> >   384  003A  0821                      movf    _ISR_charBuf,w
> >   385  003B  3A50                      xorlw   80
> >   386  003C  1903                      btfsc   3,2
> >   387  003D  286E                      goto    u440
> >
> >Ouch! :) Thanks for any help, TTYL
>
> You are looking in the wrong place in the list file. That assembly listing
> does not do the same thing as the line of C.

       I made a typo. the ==1 should be an ==2.

{Quote hidden}

       I'm so concerned because I have a LARGE number of states, so even saving
one instruction per state makes a big difference. I don't know why I have to
EXPLAIN why I am "concerned".

> If your timing/space constraints are that tight,
> you should
> probably be coding in assembly anyway.

       Wow, that's a useful suggestion... thanks anyways.

----------------------------------
Herbert's PIC Stuff:
http://repatch.dyndns.org:8383/pic_stuff/

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservEraseMEspammitvma.mit.edu with SET PICList DIGEST in the body

.

2004\01\30@085145 by Herbert Graf

flavicon
face
> Are state machines implemented in C that much differently than the way
> I was taught to do them in assembly language? Isn't there separate
> code that gets executed based on the state variable? Once a state's
> code is being executed, there's no need to check the state variable
> again.

       Hmm, that's an interesting idea, I'll have to experiment with it.

> If this is the case, you could call a common exit function from each
> state to detect the carriage-return and comma characters. (At a
> minimum, you could test for the state variable being greater than 6
> and less than 14 rather than testing for the individual values.).

       You are right, per someone else's suggestion here, I tried that and it did
save me 8 words.

{Quote hidden}

       It's a typo, the ==1 should be an ==2. TTYL

----------------------------------
Herbert's PIC Stuff:
http://repatch.dyndns.org:8383/pic_stuff/

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email RemoveMElistservEraseMEspamspam_OUTmitvma.mit.edu with SET PICList DIGEST in the body

.

2004\01\30@094410 by hael Rigby-Jones

picon face
>> From: Mike Rigby-Jones
>> I don't understand why you are so concerned with the output of the
>> compiler, even using the XOR code it hardly seems like an
>> excessively bloated implementation.

>{Original Message removed}

2004\01\30@113755 by Alan B. Pearce

face picon face
> From the differences in code between the full version I
>use and the Lite version, it would seem that some
>optimisations have been omitted from the Lite compiler.

IIRC this is even stated on the HiTech web site. Certainly I have heard it
told around here before. So as the OP was wanting really compact code, it
would seem that it is inevitable that a licensed version of the compiler is
required if C must be used, or resort to spending some time (= money) with
assembler. I guess it comes down to which is the most cost effective, and
there is no guarantee that a licensed compiler will produce compact enough
code.

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email @spam@listservRemoveMEspamEraseMEmitvma.mit.edu with SET PICList DIGEST in the body

.

2004\01\30@114833 by Wouter van Ooijen

face picon face
> I guess it comes down to which is the most cost
> effective, and
> there is no guarantee that a licensed compiler will produce
> compact enough
> code.

Is it guaranteed that the OP's assembly will be compact enough?

;)

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email EraseMElistservspam@spam@mitvma.mit.edu with SET PICList DIGEST in the body

.

2004\01\30@115420 by Alan B. Pearce

face picon face
>> there is no guarantee that a licensed compiler will produce
>> compact enough
>> code.
>
>Is it guaranteed that the OP's assembly will be compact enough?
>
>;)

Well I guess he has control over that, where he doesn't necessarily have
control over it in a HLL :))

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email @spam@listservspam_OUTspam.....mitvma.mit.edu with SET PICList DIGEST in the body

.

2004\01\30@135714 by Andrew Warren

flavicon
face
Herbert Graf <spamBeGonePICLISTEraseMEspammitvma.mit.edu> wrote:

> Hello all, been trying to implement a state machine using PICCLITE
> and am encountering BIG code. I was wondering if anyone might have
> some ideas as to how I could implement a state machine more
> efficiently

Herbert:

>From the bits of code you've posted, it looks as though you test
ISR_state on practically every line of code.  Would it save space to
code the thing in the more traditional way, with a big "switch
(ISR_state)" statement (or the equivalent) at the top of your
program, so you didn't have to do all those repeated tests?

-Andy

=== Andrew Warren -- aiwspamBeGonespamcypress.com
=== Principal Design Engineer
=== Cypress Semiconductor Corporation
===
=== Opinions expressed above do not
=== necessarily represent those of
=== Cypress Semiconductor Corporation

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email RemoveMElistserv@spam@spamspamBeGonemitvma.mit.edu with SET PICList DIGEST in the body

.

2004\01\30@144601 by Rob Hamerling

flavicon
face
Herbert Graf wrote:

>>You did not mention any requirements (timing, memory space, etc). If
>>there are no such requirements and the code works as expected, then you
>>are done, and optimisation is a waste of time.
>
>
>         Umm, it was pretty obvious (at least to most others here) I was concerned
> about the number of words a simple line like what is above generates.

Probably not a coincidence. For assembler people it seems a way of life
to try making a program smaller and/or faster than _needed_ (I have done
a lot of assembler programming myself - not with PICs - and had the same
habit).
The point I tried to make is that if a program doesn't need to be made
smaller then every effort to make it smaller is unproductive. Who wants
to pay for wasted time?

Regards, Rob.

--
Rob Hamerling, Vianen, NL phone +31-347-322822
homepage: http://www.robh.nl/

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email .....listserv@spam@spamEraseMEmitvma.mit.edu with SET PICList DIGEST in the body

.

2004\01\30@190118 by Herbert Graf

flavicon
face
> Herbert Graf <.....PICLISTRemoveMEspammitvma.mit.edu> wrote:
>
> > Hello all, been trying to implement a state machine using PICCLITE
> > and am encountering BIG code. I was wondering if anyone might have
> > some ideas as to how I could implement a state machine more
> > efficiently
>
> Herbert:
>
> >From the bits of code you've posted, it looks as though you test
> ISR_state on practically every line of code.  Would it save space to
> code the thing in the more traditional way, with a big "switch
> (ISR_state)" statement (or the equivalent) at the top of your
> program, so you didn't have to do all those repeated tests?

       Well, the suggestions from here have let me optimize one section, however I
have something like the following which is REALLY ugly! :)

if ((ISR_state == 0 && ISR_charBuf == 'G')
       || (ISR_state == 1 && ISR_charBuf == 'F')
       || (ISR_state == 2 && ISR_charBuf == 'D')
       || (ISR_state == 3 && ISR_charBuf == 'V')
       || (ISR_state == 4 && ISR_charBuf == 'W')
       || (ISR_state == 5 && ISR_charBuf == 'H')
       || (ISR_state == 6 && ISR_charBuf == 'Y')
       || (ISR_state == 7 && ISR_charBuf == 'Z'))
       ISR_state++;

Any idea how I might restructure my thinking or code to make this a little
tamer? Thanks, TTYL

----------------------------------
Herbert's PIC Stuff:
http://repatch.dyndns.org:8383/pic_stuff/

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email .....listservSTOPspamspam@spam@mitvma.mit.edu with SET PICList DIGEST in the body

.

2004\01\30@190121 by Herbert Graf

flavicon
face
> >         Umm, it was pretty obvious (at least to most others
> here) I was concerned
> > about the number of words a simple line like what is above generates.
>
> Probably not a coincidence. For assembler people it seems a way of life
> to try making a program smaller and/or faster than _needed_ (I have done
> a lot of assembler programming myself - not with PICs - and had the same
> habit).
> The point I tried to make is that if a program doesn't need to be made
> smaller then every effort to make it smaller is unproductive. Who wants
> to pay for wasted time?

       I don't want it smaller "for fun", I'm running out of code space (as usual)
have many more features I want to add. Thanks, TTYL

----------------------------------
Herbert's PIC Stuff:
http://repatch.dyndns.org:8383/pic_stuff/

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservEraseMEspam@spam@mitvma.mit.edu with SET PICList DIGEST in the body

.

2004\01\30@191156 by Andrew Warren

flavicon
face
Herbert Graf <RemoveMEPICLISTspamspamBeGonemitvma.mit.edu> wrote:

> if ((ISR_state == 0 && ISR_charBuf == 'G')
>         || (ISR_state == 1 && ISR_charBuf == 'F')
>         || (ISR_state == 2 && ISR_charBuf == 'D')
>         || (ISR_state == 3 && ISR_charBuf == 'V')
>         || (ISR_state == 4 && ISR_charBuf == 'W')
>         || (ISR_state == 5 && ISR_charBuf == 'H')
>         || (ISR_state == 6 && ISR_charBuf == 'Y')
>         || (ISR_state == 7 && ISR_charBuf == 'Z'))
>         ISR_state++;
>
> Any idea how I might restructure my thinking or code to make this a
> little tamer?

   Make a constant array of 8 characters; initialize it with G, F,
   D, V, W, H, Y, Z.  Then:

       if (ISR_charBuf == array[ISR_state]) ISR_state++;

   -Andy

=== Andrew Warren -- spamBeGoneaiwKILLspamspam@spam@cypress.com
=== Principal Design Engineer
=== Cypress Semiconductor Corporation
===
=== Opinions expressed above do not
=== necessarily represent those of
=== Cypress Semiconductor Corporation

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservspam_OUTspam@spam@mitvma.mit.edu with SET PICList DIGEST in the body

.
Return-Path: <>
Received: from mitvma.mit.edu ([18.92.0.3]) by tomts12-srv.bellnexxia.net
         (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP
         id <spamBeGone20040130080755.ZENC5780.tomts12-srv.bellnexxia.net@spam@spammitvma.mit.edu>>          for <RemoveMEpiclist_errorsEraseMEspamKILLspamSYMPATICO.CA>;
         Fri, 30 Jan 2004 03:07:55 -0500
Received:  by mitvma.mit.edu (IBM VM SMTP Level 430) via spool with SMTP id 8262 ; Fri, 30 Jan 2004 03:07:54 EST
Received: from MITVMA.MIT.EDU (NJE origin LISTSERV@MITVMA) by MITVMA.MIT.EDU (LMail V1.2d/1.8d) with BSMTP id 9766; Fri, 30 Jan 2004 03:07:54 -0500
Date:         Fri, 30 Jan 2004 03:07:54 -0500
From:         "L-Soft list server at MITVMA.MIT.EDU (1.8e)"
             <spamBeGoneLISTSERVspam_OUTspamRemoveMEMITVMA.MIT.EDU>
Subject: PICLIST: error report from YAHOO.CO.UK
To:           .....listsjoshspamRemoveME3MTMP.COM,
             "For Blackholeeclipsespam@spam@Earthlink.Net" <EraseMEpiclist_errorsRemoveMEspamSTOPspamSYMPATICO.CA>
Message-ID:   <LISTSERV%RemoveME2004013003075436KILLspamspamTakeThisOuTMITVMA.MIT.EDU>
X-LSV-ListID: None

The enclosed message has been identified as a delivery error for the PICLIST
list because it was sent to 'spamBeGoneowner-piclistspam@spam@MITVMA.MIT.EDU'.

------------------------------ Message in error -------------------------------
Received: from MITVMA (NJE origin SMTP@MITVMA) by MITVMA.MIT.EDU (LMail
         V1.2d/1.8d) with BSMTP id 9764; Fri, 30 Jan 2004 03:07:54 -0500
Received: from mta118.mail.ukl.yahoo.com [217.12.11.55] by mitvma.mit.edu (IBM
         VM SMTP Level 430) via TCP with SMTP ; Fri, 30 Jan 2004 03:07:54 EST
X-Comment: mitvma.mit.edu: Mail was sent by mta118.mail.ukl.yahoo.com
From: RemoveMEMAILER-DAEMONspam_OUTspamyahoo.co.uk
To: owner-piclistspamspammitvma.mit.edu
X-Loop: spam_OUTMAILER-DAEMONspam_OUTspamspam_OUTyahoo.co.uk
Subject: Delivery failure

Message from yahoo.co.uk.
Unable to deliver message to the following address(es).

<viniciusbhspam_OUTspamyahoo.co.uk>:
Sorry, your message to RemoveMEviniciusbhKILLspamspam@spam@yahoo.co.uk cannot be delivered.  This account is over quota.

--- Original message follows.

Return-Path: <owner-piclistspamBeGonespam.....mitvma.mit.edu>
Received: from 209.119.0.109  (EHLO cherry.ease.lsoft.com) (209.119.0.109)
 by mta118.mail.ukl.yahoo.com with SMTP; Fri, 30 Jan 2004 08:07:56 +0000
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <KILLspam15.00CC3C7Aspam.....cherry.ease.lsoft.com>; Thu, 29 Jan 2004 21:15:38 -0500
Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (LISTSERV-TCP/IP release 1.8e)
         with spool id 7558 for spam_OUTPICLISTspamKILLspamMITVMA.MIT.EDU; Thu, 29 Jan 2004
         21:15:31 -0500
Received: from MITVMA (NJE origin SMTP@MITVMA) by MITVMA.MIT.EDU (LMail
         V1.2d/1.8d) with BSMTP id 2074; Thu, 29 Jan 2004 21:14:56 -0500
Received: from flamingo.mail.pas.earthlink.net [207.217.120.232] by
         mitvma.mit.edu (IBM VM SMTP Level 430) via TCP with ESMTP ; Thu, 29
         Jan 2004 21:14:55 EST
X-Comment: mitvma.mit.edu: Mail was sent by flamingo.mail.pas.earthlink.net
Received: from user-12hceq4.cable.mindspring.com ([69.22.59.68] helo=mikronus)
         by flamingo.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id
         1AmOBN-0006rb-00 for RemoveMEPICLISTRemoveMEspamEraseMEMITVMA.MIT.EDU; Thu, 29 Jan 2004
         18:14:57 -0800
References:  <KILLspamKHEAKGMGPPBIPOHGAOODKEMGCMAA.no_spamspamspamBeGonelocalnet.com>> MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Message-ID:  <01c601c3e6d6$db52eaa0$6401a8c0@mikronus>
Date:         Thu, 29 Jan 2004 20:14:56 -0600
Reply-To:     pic microcontroller discussion list <
PICLISTspamspamMITVMA.MIT.EDU>
Sender:       pic microcontroller discussion list <RemoveMEPICLISTspamBeGonespamRemoveMEMITVMA.MIT.EDU>
From:         Michael Johnston <KILLspamstoney40spamBeGonespamEARTHLINK.NET>
Subject: Re: [PIC]: Trouble assembling code for 16F84A
To:           @spam@PICLISTSTOPspamspam@spam@MITVMA.MIT.EDU
Precedence: list

Ken
I appreciate the information. I will go and download it and get it up and
running this weekend. I turned off the cap sentive switch while i was at so
that fix most of the problems but. I will need add a larger delay to the
code because i scanes so fast you can barley see it
Michael Johnston
{Original Message removed}

2004\01\30@204648 by William Chops Westfield

face picon face
On Friday, Jan 30, 2004, at 15:58 US/Pacific, Herbert Graf wrote:

>
> if ((ISR_state == 0 && ISR_charBuf == 'G')
>         || (ISR_state == 1 && ISR_charBuf == 'F')
>         || (ISR_state == 2 && ISR_charBuf == 'D')
>         || (ISR_state == 3 && ISR_charBuf == 'V')
>         || (ISR_state == 4 && ISR_charBuf == 'W')
>         || (ISR_state == 5 && ISR_charBuf == 'H')
>         || (ISR_state == 6 && ISR_charBuf == 'Y')
>         || (ISR_state == 7 && ISR_charBuf == 'Z'))
>         ISR_state++;
>
maybe it's not polite, but this isn't looking too much like a proper
state machine to me.  I thought a big point of a state machine was
that you SHOULDN'T be continually comparing against the state like
you are doing above.  You should have distinct code for each state:

switch (ISR_state) {
    case 1:
            if (ISR_charBuf == 'F')
               ISR_state++;
         break;
    case 2:
           if (ISR_charBuf == 'D')
          // etc
    case 3:
    case 4:
    case 5:
    case 6:
    case 7:
}

However, this DOESN'T necessarily produce very compact code.  It makes
nice fast and somewhat deterministic code, but there is always the
temptation to group common code from states together, as you are doing.
You can get better density by making things table driven or modular.
    case 1:
       inc_state_conditional('F');
or
    if (searchstring[ISR_STATE] == ISR_charbuf)
        ISR_state++;

The last big state machine I did was the "dispatch machine" code for
cisco
terminal servers, which let the user build state tables like:
    state-machine foo <state-number> <first-char-to-match>
                      <last-char-to-match> <next-state>
<special-actions>
It allows 10 states or so, so you can set up packet dispatch on
arbitrary
strings up to 10 characters long.  It has the obvious (and rather huge,
for a PIC) data structure behind it, but it would be smaller for fixed
strings.  (BTW.  There's a lesson here, somewhere.  This command is SO
mysterious to the average terminal server admin, that the only time it
gets used is if one of the three or so people at cisco who understand it
specifically generates a configuration for them.  Sigh.)

i don't know if any of these ideas will end up making smaller code.  I
hope your C compiler does jump tables for dense case statements...

If you're doing mostly string matching, you may want to look into some
of the assorted search algorithms in the literature.  these are pretty
similar to state machines, but you get to do  a bunch of simplifying
based on the fact the the number of actual states (matching some amount
of some string, NOT matching anything) is much smaller than the lengths
of  the strings you're searching for.  Or something like that.

BillW

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservspamBeGonespamspamBeGonemitvma.mit.edu with SET PICList DIGEST in the body

.

2004\01\30@211634 by Herbert Graf

flavicon
face
{Quote hidden}

       WOW!!! 42 words saved thanks to that brilliant idea! :) Thanks alot. TTYL

----------------------------------
Herbert's PIC Stuff:
http://repatch.dyndns.org:8383/pic_stuff/

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email spam_OUTlistservSTOPspamspammitvma.mit.edu with SET PICList DIGEST in the body

.

2004\01\30@225409 by Bob Ammerman

picon face
----- Original Message -----
From: "Andrew Warren" <RemoveMEaiwspamspamCYPRESS.COM>
To: <TakeThisOuTPICLISTspamspamRemoveMEMITVMA.MIT.EDU>
Sent: Friday, January 30, 2004 7:17 PM
Subject: Re: [PIC]: Hitech PICCLITE state machine optimization


{Quote hidden}

Or even:

   if (ISR_charBuf == "GFDVWWHYZ"[ISR_state]) ISR_state++

Or amazingly:

   if (ISR_charBuf == ISR_state["GFDVWHYZ"]) ISR_state++

Both of the above are legal ANSI "C" (and mean the same thing). With PIC C
compilers YMMV.

Note that in ANSI 'C',     x[y]    is _defined_ to be     *(x+y)

Bob Ammerman
RAm Systems

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservRemoveMEspammitvma.mit.edu with SET PICList DIGEST in the body

.

2004\01\30@231651 by Herbert Graf

flavicon
face
{Quote hidden}

       Hehe, interesting, both are kinda "weird" looking. Unfortunately both
those, while smaller then the original, are larger then Andy's suggestion.
Thanks though for the help. TTYL

----------------------------------
Herbert's PIC Stuff:
http://repatch.dyndns.org:8383/pic_stuff/

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email EraseMElistservSTOPspamspamRemoveMEmitvma.mit.edu with SET PICList DIGEST in the body

.

2004\01\31@013744 by Ken Pergola

flavicon
face
Hi Herbert,

If you are using PICC Lite v8.02PL1, you might want to experiment with
this:

>From HI-TECH's web site:
{
There has been a new pragma introduced to control the code generated for
switch statements.
This allows code to be generated for applications which are time-critical
or rely on minimal
code size (ie: state machines). A jump table may be generated in preference
to a direct
comparison or vice versa.


#pragma switch direct

5.13.3.5 The #pragma switch Directive
Normally the compiler decides the code generation method for switch
statements which results in the smallest possible code size. Specifying the
direct option to the #pragma switch directive forces the compiler to
generate the table look-up style switch method. This is mostly useful where
either timing or code size is an issue for switch statements (ie: state
machines) and a jump table is preferred over direct comparison or vice
versa. This pragma affects all code generated onwards. The auto option may
be used to revert to the default behaviour.
}



Herbert, this new pragma was introduced in PICC v8.02PL1, so it *may* also
work with PICC Lite v8.02PL1.


Best regards,

Ken Pergola

--
http://www.piclist.com hint: To leave the PICList
spam_OUTpiclist-unsubscribe-requestRemoveMEspamEraseMEmitvma.mit.edu

.

2004\01\31@045643 by Rob Hamerling

flavicon
face
Herbert Graf wrote:


>>The point I tried to make is that if a program doesn't need to be made
>>smaller then every effort to make it smaller is unproductive. Who wants
>>to pay for wasted time?
>
>
>         I don't want it smaller "for fun", I'm running out of code space (as usual)
> have many more features I want to add. Thanks, TTYL

Next time inform us about your requirements in stead of letting us guess
and make the wrong assumptions (and wasting our time).

Rob.

--
Rob Hamerling, Vianen, NL phone +31-347-322822
homepage: http://www.robh.nl/

--
http://www.piclist.com hint: To leave the PICList
TakeThisOuTpiclist-unsubscribe-requestRemoveMEspam@spam@mitvma.mit.edu

.

2004\01\31@070218 by Russell McMahon

face
flavicon
face
> >>The point I tried to make is that if a program doesn't need to be made
> >>smaller then every effort to make it smaller is unproductive. Who wants
> >>to pay for wasted time?

> >         I don't want it smaller "for fun", I'm running out of code space
(as usual)
> > have many more features I want to add. Thanks, TTYL
>
> Next time inform us about your requirements in stead of letting us guess
> and make the wrong assumptions (and wasting our time).

I've looked at that exchange several times and it looks the same each time
so I'll climb into my Nomex suit and say that I can't see how it's not
unnecessarily rude.

The original request seemed well couched ( to me anyway).
He said he had big code and wanted small code.

viz

===========

> Hello all, been trying to implement a state machine using PICCLITE and am
> encountering BIG code. I was wondering if anyone might have some ideas as
to
> how I could implement a state machine more efficiently.

       ....... example

> Any ideas as to how I might do the same sort of thing without using so
much
> code?

AND

> I had a look at the assembly on another section of the state machine where
> it's even worse:
> Ouch! :) Thanks for any help, TTYL

       ....... another example

===============

Granted, he didn't say WHY he wanted it smaller, but his REQUIREMENT seemed
clear enough (to me anyway).
Even if he was just wanting it smaller for fun, the requirement was still
well stated (unlike that of very many other people who ask questions which
very porrly state their requirement).

What's the problem?

cf Niven's 1st rule (adopted for use here) - 'Don't throw excrement at an
armed admin.'
(2nd rule is 'Don't stand next to a man who is throwing excrement at an
armed admin')


           Russell McMahon

--
http://www.piclist.com hint: To leave the PICList
EraseMEpiclist-unsubscribe-requestRemoveMEspammitvma.mit.edu

.
Return-Path: <>
Received: from mitvma.mit.edu ([18.92.0.3]) by tomts3-srv.bellnexxia.net
         (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP
         id <spam20040128024230.HEHN1829.tomts3-srv.bellnexxia.net.....spamspammitvma.mit.edu>>          for <piclist_errorsspam_OUTspam@spam@SYMPATICO.CA>;
         Tue, 27 Jan 2004 21:42:30 -0500
Received:  by mitvma.mit.edu (IBM VM SMTP Level 430) via spool with SMTP id 6165 ; Tue, 27 Jan 2004 21:42:26 EST
Received: from MITVMA.MIT.EDU (NJE origin LISTSERV@MITVMA) by MITVMA.MIT.EDU (LMail V1.2d/1.8d) with BSMTP id 4352; Tue, 27 Jan 2004 21:42:27 -0500
Date:         Tue, 27 Jan 2004 21:42:27 -0500
From:         "L-Soft list server at MITVMA.MIT.EDU (1.8e)"
             <.....LISTSERVspamspam.....MITVMA.MIT.EDU>
Subject: PICLIST: error report from YAHOO.COM
To:           listsjoshKILLspamspamEraseME3MTMP.COM,
             EraseMEpiclist_errors@spam@spam@spam@SYMPATICO.CA
Message-ID:   <LISTSERV%@spam@2004012721422665spamspamKILLspamMITVMA.MIT.EDU>
X-LSV-ListID: None

The enclosed message has been identified as a delivery error for the PICLIST
list because it was sent to 'spamBeGoneowner-piclistRemoveMEspamEraseMEMITVMA.MIT.EDU'.

------------------------------ Message in error -------------------------------
Received: from MITVMA (NJE origin SMTP@MITVMA) by MITVMA.MIT.EDU (LMail
         V1.2d/1.8d) with BSMTP id 4350; Tue, 27 Jan 2004 21:42:27 -0500
Received: from mta200.mail.scd.yahoo.com [66.218.86.116] by mitvma.mit.edu (IBM
         VM SMTP Level 430) via TCP with SMTP ; Tue, 27 Jan 2004 21:42:26 EST
X-Comment: mitvma.mit.edu: Mail was sent by mta200.mail.scd.yahoo.com
From: RemoveMEMAILER-DAEMONKILLspamspamRemoveMEyahoo.com
To: TakeThisOuTowner-piclistspammitvma.mit.edu
X-Loop: spamBeGoneMAILER-DAEMONKILLspamspamTakeThisOuTyahoo.com
Subject: Delivery failure

Message from yahoo.com.
Unable to deliver message to the following address(es).

<EraseMEhbarregrd.....spamKILLspamyahoo.com>:
Sorry, your message to spamhbarregrdspamyahoo.com cannot be delivered.  This account is over quota.

--- Original message follows.

Return-Path: <owner-piclistSTOPspamspammitvma.mit.edu>
Received: from 209.119.0.109  (EHLO cherry.ease.lsoft.com) (209.119.0.109)
 by mta200.mail.scd.yahoo.com with SMTP; Tue, 27 Jan 2004 13:45:40 -0800
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.00CBF82ASTOPspamspamKILLspamcherry.ease.lsoft.com>; Tue, 27 Jan 2004 13:53:27 -0500
Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (LISTSERV-TCP/IP release 1.8e)
         with spool id 0604 for @spam@PICLIST.....spamspamMITVMA.MIT.EDU; Tue, 27 Jan 2004
         13:53:22 -0500
Received: from MITVMA (NJE origin SMTP@MITVMA) by MITVMA.MIT.EDU (LMail
         V1.2d/1.8d) with BSMTP id 1494; Tue, 27 Jan 2004 13:52:51 -0500
Received: from smtp-out3.xs4all.nl [194.109.24.13] by mitvma.mit.edu (IBM VM
         SMTP Level 430) via TCP with ESMTP ; Tue, 27 Jan 2004 13:52:50 EST
X-Comment: mitvma.mit.edu: Mail was sent by smtp-out3.xs4all.nl
Received: from PAARD (a213-84-20-53.adsl.xs4all.nl [213.84.20.53]) by
         smtp-out3.xs4all.nl (8.12.10/8.12.10) with ESMTP id i0RIqqaY081198
         for <spamPICLIST.....spam.....MITVMA.MIT.EDU>; Tue, 27 Jan 2004 19:52:52 +0100 (CET)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Message-ID:  <000a01c3e506$c4d89a80$0b00a8c0@PAARD>
Date:         Tue, 27 Jan 2004 19:52:52 +0100
Reply-To:     pic microcontroller discussion list <PICLIST.....spamMITVMA.MIT.EDU>
Sender:       pic microcontroller discussion list <KILLspamPICLISTspam_OUTspamMITVMA.MIT.EDU>
From:         Wouter van Ooijen <spam_OUTwouterspamTakeThisOuTVOTI.NL>
Organization: Van Ooijen Technische Informatica
Subject: Re: [PIC:] duplicate device IDs in the 18F series
To:           .....PICLIST.....spamRemoveMEMITVMA.MIT.EDU
In-Reply-To:  <spam_OUT40168BAF.1000701TakeThisOuTspamEraseMEhccnet.nl>
Precedence: list

> Coincidence or not, only an hour after I wrote this today I received a
> sample 16F767. Its deviceID reads as 0x0EA1. According to the
> programming specifications (ds30492a.pdf) and the errata
> (ds80177a.pdf)
> this is an 16F777!! But it really is 28 pins DIP....

I just hope this is an engineering sample? Or is there another way to
distinguish this new chip?

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products

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


..
.

2004\01\31@075722 by Olin Lathrop

face picon face
Herbert Graf wrote:
>         I don't want it smaller "for fun", I'm running out of code
> space (as usual) have many more features I want to add.

Then ditch the compiler.  You've already wasted more time trying to get the
compiler to emit reasonable code than it would have taken to write in
assembler.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: To leave the PICList
EraseMEpiclist-unsubscribe-requestspamBeGonespamKILLspammitvma.mit.edu

.

2004\01\31@084538 by Sergio Masci

picon face
----- Original Message -----
From: Herbert Graf <RemoveMEmailinglist2spamBeGonespamspamFARCITE.NET>
To: <@spam@PICLISTspamspamMITVMA.MIT.EDU>
Sent: Friday, January 30, 2004 11:59 PM
Subject: Re: [PIC]: Hitech PICCLITE state machine optimization


{Quote hidden}

usual)
> have many more features I want to add. Thanks, TTYL

If you want very high density you need to move all the event handling into one
place and use state transition tables. If each table entry contains a minimum of
"current state", "event", "new state" you will be able to search the table as
opposed to using a direct index into it and you will trade space for speed
(slower but smaller). When you have done this you may find that you have events
that are common for ALMOST all states. You can extract these and build a table
of exceptions (states to which these events do not apply), maybe just an array
of bits where the current state is an index into the array and the corresponding
bit indicates wheather the event applies or not. There are all sorts of things
you can do provided you collect your event handling into one place.

Regards
Sergio Masci

http://www.xcprod.com/titan/XCSB - optimising structured PIC BASIC compiler

--
http://www.piclist.com hint: To leave the PICList
TakeThisOuTpiclist-unsubscribe-requestKILLspamspam@spam@mitvma.mit.edu

.
Return-Path: <>
Received: from mitvma.mit.edu ([18.92.0.3]) by tomts34-srv.bellnexxia.net
         (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP
         id <.....20040130073723.FPJD23141.tomts34-srv.bellnexxia.netRemoveMEspammitvma.mit.edu>>          for <KILLspampiclist_errorsspamTakeThisOuTSYMPATICO.CA>;
         Fri, 30 Jan 2004 02:37:23 -0500
Received:  by mitvma.mit.edu (IBM VM SMTP Level 430) via spool with SMTP id 8241 ; Fri, 30 Jan 2004 02:37:20 EST
Received: from MITVMA.MIT.EDU (NJE origin LISTSERV@MITVMA) by MITVMA.MIT.EDU (LMail V1.2d/1.8d) with BSMTP id 9165; Fri, 30 Jan 2004 02:37:20 -0500
Date:         Fri, 30 Jan 2004 02:37:20 -0500
From:         "L-Soft list server at MITVMA.MIT.EDU (1.8e)"
             <TakeThisOuTLISTSERVspamspam_OUTMITVMA.MIT.EDU>
Subject: PICLIST: error report from YAHOO.CO.UK
To:           RemoveMElistsjoshspamspamSTOPspam3MTMP.COM,
             "For .....BlackholeeclipseEraseMEspamEarthlink.Net" <spamBeGonepiclist_errorsspamRemoveMESYMPATICO.CA>
Message-ID:   <LISTSERV%.....2004013002372031EraseMEspamMITVMA.MIT.EDU>
X-LSV-ListID: None

The enclosed message has been identified as a delivery error for the PICLIST
list because it was sent to 'spamowner-piclistspam_OUTspam@spam@MITVMA.MIT.EDU'.

------------------------------ Message in error -------------------------------
Received: from MITVMA (NJE origin SMTP@MITVMA) by MITVMA.MIT.EDU (LMail
         V1.2d/1.8d) with BSMTP id 9161; Fri, 30 Jan 2004 02:37:20 -0500
Received: from mta108.mail.ukl.yahoo.com [217.12.11.45] by mitvma.mit.edu (IBM
         VM SMTP Level 430) via TCP with SMTP ; Fri, 30 Jan 2004 02:37:20 EST
X-Comment: mitvma.mit.edu: Mail was sent by mta108.mail.ukl.yahoo.com
From: spamMAILER-DAEMON@spam@spamSTOPspamyahoo.co.uk
To: spamBeGoneowner-piclistspamBeGonespam@spam@mitvma.mit.edu
X-Loop: RemoveMEMAILER-DAEMONRemoveMEspamRemoveMEyahoo.co.uk
Subject: Delivery failure

Message from yahoo.co.uk.
Unable to deliver message to the following address(es).

<viniciusbhKILLspamspamspamyahoo.co.uk>:
Sorry, your message to spam_OUTviniciusbh@spam@spamyahoo.co.uk cannot be delivered.  This account is over quota.

--- Original message follows.

Return-Path: <TakeThisOuTowner-piclistspam_OUTspammitvma.mit.edu>
Received: from 209.119.0.109  (EHLO cherry.ease.lsoft.com) (209.119.0.109)
 by mta108.mail.ukl.yahoo.com with SMTP; Fri, 30 Jan 2004 07:37:21 +0000
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <KILLspam9.00CC428F.....spamTakeThisOuTcherry.ease.lsoft.com>; Fri, 30 Jan 2004 1:33:38 -0500
Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (LISTSERV-TCP/IP release 1.8e)
         with spool id 1035 for TakeThisOuTPICLISTEraseMEspamRemoveMEMITVMA.MIT.EDU; Fri, 30 Jan 2004
         01:33:31 -0500
Received: from MITVMA (NJE origin SMTP@MITVMA) by MITVMA.MIT.EDU (LMail
         V1.2d/1.8d) with BSMTP id 7303; Fri, 30 Jan 2004 01:32:10 -0500
Received: from sj-iport-3.cisco.com [171.71.176.72] by mitvma.mit.edu (IBM VM
         SMTP Level 430) via TCP with SMTP ; Fri, 30 Jan 2004 01:32:10 EST
X-Comment: mitvma.mit.edu: Mail was sent by sj-iport-3.cisco.com
Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com
         with ESMTP; 29 Jan 2004 22:38:00 +0000
Received: from cisco.com (cypher.cisco.com [171.69.11.143]) by
         sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id i0U6WAqh004281 for
         <spam_OUTPICLISTRemoveMEspam.....MITVMA.MIT.EDU>; Thu, 29 Jan 2004 22:32:11 -0800 (PST)
Received: from mac.com (sjc-vpn1-253.cisco.com [10.21.96.253]) by cisco.com
         (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id WAA15055 for
         <spamPICLISTKILLspamspamKILLspamMITVMA.MIT.EDU>; Thu, 29 Jan 2004 22:32:10 -0800 (PST)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v552)
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.552)
Message-ID:  <spam02F5D2C6-52EE-11D8-9E8E-000A95E5DF26spam_OUTspammac.com>> Date:         Thu, 29 Jan 2004 22:32:01 -0800
Reply-To:     pic microcontroller discussion list <
STOPspamPICLISTspam_OUTspamspamBeGoneMITVMA.MIT.EDU>
Sender:       pic microcontroller discussion list <spam_OUTPICLISTspamspamBeGoneMITVMA.MIT.EDU>
From:         William Chops Westfield <EraseMEwestfwspamKILLspamMAC.COM>
Subject: Re: [PIC:] Disassemblers
To:           EraseMEPICLISTRemoveMEspamMITVMA.MIT.EDU
In-Reply-To:  <.....2193429B07D9914D97216EBBAA6AB8BD1A0542spamspam_OUTwhitlam.corp.gli.com.au>> Precedence: list

On Thursday, Jan 29, 2004, at 15:44 US/Pacific, Liam O'Hagan wrote:

>
> Can anyone tell me where the "bc", "a" and "h" etc are defined?
>
> The zilog user's manual and datasheet for the device don't explain
> what they
> are, neither does the source code I have.
>
>
BC, A, and H are standard register names for a Z80 style processor.
Is the "z86" you mention a Z80 variant, or a Z8 (entirely different
architecture!  Perhaps more than one!) of some kind?

That is, I think perhaps you have the wrong dissassembler...

(how does the dissassembled version of the binary that matches the
source you have look, compared to the source.)

BillW

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email @spam@listservEraseMEspamspammitvma.mit.edu with SET PICList DIGEST in the body
*** MESSAGE TRUNCATED ***


..
.

2004\01\31@093757 by Bill Couture

picon face
On Fri, 30 Jan 2004, Herbert Graf wrote:

> Well, the suggestions from here have let me optimize one section,
> however I  have something like the following which is REALLY ugly! :)
>
> if ((ISR_state == 0 && ISR_charBuf == 'G')
>         || (ISR_state == 1 && ISR_charBuf == 'F')
>         || (ISR_state == 2 && ISR_charBuf == 'D')
>         || (ISR_state == 3 && ISR_charBuf == 'V')
>         || (ISR_state == 4 && ISR_charBuf == 'W')
>         || (ISR_state == 5 && ISR_charBuf == 'H')
>         || (ISR_state == 6 && ISR_charBuf == 'Y')
>         || (ISR_state == 7 && ISR_charBuf == 'Z'))
>         ISR_state++;
>
> Any idea how I might restructure my thinking or code to make this a little
> tamer? Thanks, TTYL

const char desired_state_chars[8] = "GFDVWHYZ";

  if ((ISR_state < 8)
        && (ISR_charBuf == desired_state_chars[ISR_state]))
     ISR_state++;

Bill

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestTakeThisOuTspamKILLspammitvma.mit.edu

.

2004\01\31@115108 by Herbert Graf

flavicon
face
> >>The point I tried to make is that if a program doesn't need to be made
> >>smaller then every effort to make it smaller is unproductive. Who wants
> >>to pay for wasted time?
> >
> >
> >         I don't want it smaller "for fun", I'm running out of
> code space (as usual)
> > have many more features I want to add. Thanks, TTYL
>
> Next time inform us about your requirements in stead of letting us guess
> and make the wrong assumptions (and wasting our time).
>
> Rob.

       Sir, yes, sir...

----------------------------------
Herbert's PIC Stuff:
http://repatch.dyndns.org:8383/pic_stuff/

--
http://www.piclist.com hint: To leave the PICList
RemoveMEpiclist-unsubscribe-requestTakeThisOuTspammitvma.mit.edu

.

2004\01\31@115724 by Anthony Toft

flavicon
face
If this is C like code...

Why no make an array of states, each member being a function pointer to
the function that implements the state actions.

Then in your machine structure, keep the function pointer and the state
number, as you _end_ each state you just switch the function point for
the next one.

No big 'if' statement, no switch no nothing, _and_ it mirrors the "state
machine" model better (ie. The state transition is the last thing a
state does)...

I can elaborate on this (with an example) if you'd like but I don't have
any examples infront of me right now.

> {Original Message removed}

2004\01\31@115726 by Herbert Graf

flavicon
face
> Herbert Graf wrote:
> >         I don't want it smaller "for fun", I'm running out of code
> > space (as usual) have many more features I want to add.
>
> Then ditch the compiler.  You've already wasted more time trying
> to get the
> compiler to emit reasonable code than it would have taken to write in
> assembler.

       I disagree. For the moment you are correct, but very soon I'll need to add
some stuff that would take me a LONG time to develop in assembly (the
writing of it would be quick but the debugging would be "interesting").

       I still do assembly for certain projects, but C is "easier" to get going,
with the con of being "bigger" and less efficient, so at the beginning I
evaluate whether going with C or doing it asm is the better choice. I've
made my choice for this project and I've had no reason to diverge, yet.

       FWIW I'm not stubborn about it, I've had one project which started in ASM
and was moved to C (due to the complex nature of the FAT file system). I've
also had a project where I started in C and moved to ASM. I'm pretty good at
converting code from one to the other! :)

       I know YOU don't "like" compilers, but that's no reason for noone else to
like them. TTYL

----------------------------------
Herbert's PIC Stuff:
http://repatch.dyndns.org:8383/pic_stuff/

--
http://www.piclist.com hint: To leave the PICList
@spam@piclist-unsubscribe-requestSTOPspamspammitvma.mit.edu

.

2004\01\31@115932 by Herbert Graf

flavicon
face
> > >     Make a constant array of 8 characters; initialize it with G, F,
> > >     D, V, W, H, Y, Z.  Then:
> > >
> > >         if (ISR_charBuf == array[ISR_state]) ISR_state++;
> > >
> > >     -Andy
> >
> >         WOW!!! 42 words saved thanks to that brilliant idea! :)
> Thanks alot. TTYL
>
> I didn't see this response before I wrote mine, but you need to check
> ISR_state for valid array index befor the ISR_charBuf compare.  Array
> index out of range is a bad thing...

       You are of course right, realized that as I wrote the code, which is
working BTW. :) Thanks, TTYL

----------------------------------
Herbert's PIC Stuff:
http://repatch.dyndns.org:8383/pic_stuff/

--
http://www.piclist.com hint: To leave the PICList
TakeThisOuTpiclist-unsubscribe-requestTakeThisOuTspamRemoveMEmitvma.mit.edu

.


'[PIC]: Hitech PICCLITE state machine optimization'
2004\02\02@080527 by Alan B. Pearce
face picon face
>I still do assembly for certain projects, but C is "easier" to get
>going, with the con of being "bigger" and less efficient, so at the
>beginning I evaluate whether going with C or doing it asm is the
>better choice. I've made my choice for this project and I've had
>no reason to diverge, yet.
>
>FWIW I'm not stubborn about it, ...

The bit you do seem to be stubborn about is paying for a compiler that will
do the optimisations fully. As has been stated here last week, the PICCLite
does not have all the optimisations available. You get what you pay for ...
pay nothing, get no optimisation. If things really are that tight already,
and you have more features to add, then you are in big strife anyway, and
probably need to go to a bigger memory PIC from the sound of it.

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

.

2004\02\02@193548 by Reggie Berdin

picon face
One solution is to make ISR_state bit mapped.  A high on bit 0 for state 0,
bit 1 for the next state.  Comparisons will become only 1 instruction long.
Just rotate left to move to next state.  I have done this on all my state
machines.

This will not be compatible with Andy's constant array suggestion on a part
of your code.  But you could still maintain a sequential state variable and
a bit mapped one using lookup tables.

regards,
Reggie


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.564 / Virus Database: 356 - Release Date: 1/27/2004

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2004\02\02@203304 by Herbert Graf

flavicon
face
> One solution is to make ISR_state bit mapped.  A high on bit 0
> for state 0,
> bit 1 for the next state.  Comparisons will become only 1
> instruction long.
> Just rotate left to move to next state.  I have done this on all my state
> machines.
>
> This will not be compatible with Andy's constant array suggestion
> on a part
> of your code.  But you could still maintain a sequential state
> variable and
> a bit mapped one using lookup tables.

       Wow, that's a cool idea, I'll keep that one in mind. Thanks, TTYL

----------------------------------
Herbert's PIC Stuff:
http://repatch.dyndns.org:8383/pic_stuff/

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2004\02\03@032008 by hael Rigby-Jones

picon face
>-----Original Message-----
>From: Herbert Graf [spam_OUTmailinglist2spamspam.....FARCITE.NET]
>
>        Notice who I was "rude" (in your opinion) to: the
>people who DIDN'T help, the people who took the high and
>mighty approach of throwing more money at the problem, the
>people who seem to have lost sight of what a hobbyist project
>is all about. Can't blame them, after all once you've reached
>a certain rung on the ladder the rungs before are simply to be
>stepped on. Quite understandable, as was my response.
>

I don't wish to add any fuel to the fire, but I think you have misunderstood
me.  You are obviously trying to cram a fair bit of functionality into a
small device.  Nothing wrong with that at all, in fact it's part of the PIC
philosophy.  You are also learning to effectively use the free version of
Hitechs C compiler, which is a great tool and will hopefully convince you of
the benefits of a HLL as it did me.

What I was trying (and failing apparently) to suggest is that for maximum
functionality in a small device, a non-optimising C compiler is not the tool
of choice.  I didn't actually recommend shelling out for the full version of
HiTech (which is beyond the budget of the vast majority of hobbiests I
suspect) but that for maximum functionality in a small space assembly is
hard to beat.  Better yet you can look into using inline assembly (if the
Lite version supports it), or linking in assembler modules to give you the
best of both worlds.

Through the suggestions given on here you have made the code fit so far, and
obviously that is great both as a learning experience and for your project.
However I still maintain my comment about the code reduction not being of
the compilers making.  I certainly agree that you have to learn how to
coerce the compiler to create efficient code, but in your case although the
functionality stayed the same, the approach taken was radicaly different,
i.e. using a lookup table instead of implicit comparisons, which is a human
optimisation.  Had you subtley re-written the the original approash and
saved some code/cycles, then I would consider that an artifact of the
compiler.

Regards

Mike




=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================
Any questions about Bookham's E-Mail service should be directed to
postmaster.....spam@spam@bookham.com.

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

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