Searching \ for '[PIC]: Programming logic solving' 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/devprogs.htm?key=programming
Search entire site for: 'Programming logic solving'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: Programming logic solving'
2003\02\18@070704 by Timothy Box

flavicon
face
Hi all

Being a self taught programmer I often waste a lot of time converting "I
WANT TO DO XXXX" into code. Do our learned gentlemen have any pointers to
how they would tackle the task or perhaps a good site.

I know it all depends on exactly what X is so for the sake of discussion :-

As an example I had to write a message inputting system much like that used
in a Mobile phone.

Read in a char from the key pad and convert the multiple key presses into
chars that changed with each key press. But if after a preset time no char
had been pressed the last char was the entered char and the cursor moves on.
Also if you pressed a new key while the last key had not timed up the last
char was the entered char and cursor moved the new char pressed it next
entered char being timed as part of the char rotation sequence.

Read in a cursor movement that lets you move a cursor back and forward
through the text but take into account the fact that the current displayed
char was still being timed and set that char to be an entered char.

Read in a number from the number pad and make that a fixed char and move the
cursor on to the next char place. But if there was a timed char being input
make that a fixed char, move the cursor on and make the entered number a
fixed char too.


While the individual routines was all relatively easy combining the
different permutations of fixing the char and moving the cursor took me a
whole day to sort out.

I tried flow charts, loads of bits of paper with PESUDO code. In the end it
was a logic table that made it work.

I listed out all the possible permutations that the keys, timers and input
states could be in then set a number or rules biased on those states to
decide what was to happen.

Now I really like that method but it cannot be applied to every problem so I
would like to know how the experts tackle structure and code sequencing
development.


Regards

Tim

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

2003\02\18@120944 by Ned Konz

flavicon
face
On Tuesday 18 February 2003 04:06 am, Timothy Box wrote:
> Hi all
>
> Being a self taught programmer I often waste a lot of time
> converting "I WANT TO DO XXXX" into code. Do our learned gentlemen
> have any pointers to how they would tackle the task or perhaps a
> good site.
[snip[
{Quote hidden}

Look at statecharts and finite state machines. These are easily coded,
and give a very clean way to express solutions to event-driven
problems.

I'm working on building a visual statechart compiler for PICs and
other small micros, as well as a set of assembler macros for doing
state machine coding on the PIC 18F series. I hope to make it into a
product.

The book "Practical Statecharts in C/C++" by Miro Samek is quite good.
You can ignore its focus on C and C++ if you wish (though he provides
working frameworks for both languages).

His web site is at http://www.quantum-leaps.com and he has quite a bit
of good material there.

--
Ned Konz
http://bike-nomad.com
GPG key ID: BEEA7EFE

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

2003\02\18@144113 by Tal

flavicon
face
I don't pretend to have the secret that will make one a programmer in
10secs but here is a try anyway. It is based on the example you
mentioned. I will use the concepts of 'abstraction', and 'data hiding'
and 'bottom up'.

Think about the problem and try to identify the 'objects' or 'terms'
that can be used to model it.

For example, one object is the 'key information'. It represents the list
of characters associated with each physical key.
The services you can get from this thing are:

give_me_the_number_of_chars_in_the_list_of_given_key(key_code) and
give_me_the_nth_char_in_the_list_of_given_key(key_code, n)

You can represent the data as a two dimensional array and write the two
function (choose better names) to access the data. This is called
'encapsulation' or 'data hiding' and now you don't need to worry anymore
about the format of the data.

Next thing is a timer. You need a way to determine if the timeout
expired. The operations you will get from this thing may looks like:

Restart_timer()
Is_timer_expired() -> return true/false
Increment_Counter()    (in case you are not using hardware timer or
interrupts)

Then, you need to represent the keyboard itself, for example by
implementing a function that tells you if a new key is available:

Give_me_new_key() -> returns 0 if no new key is available

Then, you need to model the display, for example by implementing methods
like

Write_char()
Move_cursor()  etc.

Now, that you set the foundation, you are ready to design the top level
behavior but without getting into the fine details since you have the
functions that do the actual work for you.

You will also need few variables for the thing to work. For example a
variable that holds the value of the current key (use a special value
such as zero to indicate 'none'). Then a variable to hold the index of
the current char of the current key, etc.

Hope that this helps.

Tal







> {Original Message removed}

2003\02\18@181133 by Timothy Box

flavicon
face
Thanks for the reply

As I was saying the coding for the separate routines was not the problem it
was working out the Logic holding them all together.

BTW as an aside all key board scanning and timers were interrupt driven. The
nice thing about having your key reading routines running in a interrupt
routine is all the key denounce etc is done with out waiting and you can
easily implement auto repeating on the keys with out having to worry about
it in you main code.

I must thank you again for putting together such a excellent reply many
thanks

Tim

{Original Message removed}

2003\02\18@181136 by Timothy Box

flavicon
face
Wow

I had heard about state machines before. I will defiantly have to read up on
it properly now.


Cheers Tim

{Original Message removed}

2003\02\19@083234 by Alan B. Pearce

face picon face
> Being a self taught programmer I often waste a lot of time
> converting "I WANT TO DO XXXX" into code. Do our learned
> gentlemen have any pointers to how they would tackle the task
> or perhaps a good site.
>
> I know it all depends on exactly what X is so for the sake of
> discussion :-
>
> As an example I had to write a message inputting system much
> like that used in a Mobile phone.

As a self taught programmer as well, here is what I find useful. I believe
this technique is termed "top down" programming (start at the big picture
and get more detailed).

Start by writing what you want to do as a series of comments. So for your
example you would start like this.

; Procedure to read keys from keyboard
; Multiple presses of same key toggle selected character
;
; On Entry : Nothing.
;
; Uses : Keyboard Interface Register
;        Temp register
;        keyboard delay timer
;
; On Exit : register "Keychar" contains selected character. Null represents
invalid character.
;
Keyread:    ; entry point label
;
; comments about setting Keychar to "NULL"
; Comments about checking to see if key is pressed.
; comments about how the code will read from keyboard register
; comments about checking read character against previous char
; is previous character same as new char?
; comments about result of decision
; comments about starting keyboard delay timer
; comments about waiting for delay to time out and checking for new char.
; comments about what to do if key pressed (where to loop to etc)
; comments about what to do if delay times out
;


These are not ideal examples of comments, but setting down a few comments
like this gets the thought process going about what needs to be achieved,
and how the result is going to be returned to the calling program. Intently
read the comments again the following day as though you are trying to read
someone else's program, and you will realise where you make errors in your
logic, and how portions of it can be split off into further subroutines and
so on. Once you have the whole program for the PIC done this way you will
find that there are portions that can be made quite generic (a.go. a generic
routine that reads the keypad) which will offload some of the code out of
this portion of the code.

Once you are satisfied with this level of coding you can then go down
inserting actual code between the lines of comments. You will then have a
fully commented listing that will help you understand why you have done
things a certain way. Do not forget to add comments to the lines of machine
code as you go - you will still need these to deal with things like
describing why you have had to use a certain skip instruction in front of a
branch, and to describe the polarity of the bit you are testing (bit 7 is
clear when no character ready). This will save you hours of pouring over a
nonworking device when trying to debug it.

Once you have been through this a few times then you will have modules that
you will find you can plug into new projects. This allows you to do some
level of "bottom up" programming (start at a detail point and grow the
project around it - adding features etc).

To aid this use linkable modules in your projects. Look at the development
environment which has been made available to us by Olin Lathrop at
http://www.embedinc.com/pic and think about how you can use the modules he
has already written, and what is more debugged, ready for use. He has a
standard template for use when starting a new module that leads you through
most of the process I have described above. It also has many macros that
make short work of dealing with many of the PIC processor idiosyncrasies.
This leads to more productive programming on your part, and less time spent
dealing with silly faults because you forgot to change ram banks, or set the
correct bits when calling an out of page subroutine.

Off course you could hide all this by using a high level language, but the
basic premise of writing code that I have given above still holds. Use the
comments to get yourself thinking about how the code is going to eventually
work.

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

2003\02\19@151101 by Tal

flavicon
face
Theoretically speaking, the PIC itself is a finite state machine. The
states are represented by the content of its memory and registers and
the transitions are done each clock based on the current state and
values of the input pins.

With this model, programming is merely selecting a starting state for
the PIC. This holds to virtually any computer in the world.

This is a theoretical observation that does not have much practical
value.

Tal

> {Original Message removed}

2003\02\19@172320 by Timothy Box

flavicon
face
Many thanks

Very good advice. While I follow your methods normally, once in the flow of
writing I often fail to comment to the enth degree (unless writing asm that
is) and end up having to come back a day or so later to finish off. I keep
changing my mind over commenting, do I do it every line or only commenting
when it is not absolutely obvious in the code. I try to make it that you
never have to read the code to see what is going on you should be able to
from reading the comments. As you can see I keep changing my mind.

I keep to high level languages for most of my coding and only code in asm
for the interrupt routines and speed related issues.

One trouble with the comments is the headers take more space than the code!

Thanks again

Tim

'########## MENU_SELECTION_SUB ######################
'#
'#      DESCRIPTION:
'#      HANDLES THE DISPLAYING AND SELECTION OF MENUS FROM
'#    A SCROLLED LIST ON A 2 X 16 LCD DISPLAY
'#    LIST IS SCROLLED UP AND DOWN WHEN "KEY" = "UP_KEY" OR "DOWN_KEY"
'#    MENU TITLE IS DISPLAYED ON LINE 1
'#    SUB MENU'S TO SELECT ON 2ND LINE
'#      \/ IS DISPLAYED AT POS 16 ON LINE 2 TO INDICATE MORE
'#      MENUS AVAILABLE BY SCROLLING DOWN
'#      ^ IS DISPLAYED AT POS 16 ON LINE 2 TO INDICATE MORE
'#      MENUS AVAILABLE BY SCROLLING UP
'#    \/^ WHEN MORE AVAILABLE UP OR DOWN
'#      "KEY" = "ENTER_KEY" SELECTS MENU DISPLAYED ON LINE 2
'#      RETURNS WITH NUMBER OF MENU SELECTED IN "MENU_SLCTD" (1 TO NO_MENUS)
'#      RETURNS 0 IF "KEY" = "MENU_KEY"
'#    RETURNS 255 IF UP OR DOWN KEY NOT PRESSED FOR X 100THS SECOND
"MENU_TIMEOUT_VAL"
'#    MENU TITLES ADDED TO MSG_CNTRL_SUB LIST WITH THE MENU TITLE LOCATED IN
'#    MENU_MESSG_NO (ALIASED TO "MESSG_NO" VAR)AND SUB MENUS LOCATED AFTER
IN LIST
'#      NUMBER OF SUB MENUS TO BE DISPLAYED IN "NO_MENUS"
'#      RECOMMEND USING BRANCH TO JUMP TO ROUTINE ON RETURN
'#      NOTE. MIN NUMBER MENUS = 2
'#
'#      UNIQUE VARS REQUIRED (OR ALIAS'S)
'#      WORDS
'#      MENU_TIMEOUT_VAL
'#
'#      BYTES
'#      MENU_MESSG_NO, MENU_SLCTD, NO_MENUS, END_OF_MENUS, MENU_DSPLY_NO
'#
'#    BITS
'#    MENU_TIMEOUT_REQ
'#      MENU_TIMEOUT (ALIAS WITH TMR_FLAG FROM TIMER CODE)
'#
'#      CONSTANTS OR VARS
'#    NONE (KEY_SCAN TO HAVE UP_KEY ETC CON ED)
'#
'#    SUBROUTINES REQUIRED
'#    KEY_SCAN, TIMERS, MSG_CNTRL_SUB
'#
'#      EXAMPLE CALL:-
'#      MENU_MESSG_NO = SENSOR_MENU
'#    NO_MENUS = 7                  ' NUMBER SUB MENUS
'#      MENU_TIMEOUT_VAL = 6000         ' 100THS SECOND BEFORE TIME OUT
'#    MENU_TIMEOUT_REQ = TRUE           ' TIME OUT REQUIRED
'#      GOSUB MENU_SELECTION_SUB
'#
'###################################################





{Original Message removed}

2003\02\20@040846 by Alan B. Pearce

face picon face
>While I follow your methods normally, once in the flow of writing
>I often fail to comment to the enth degree (unless writing asm that
>is) and end up having to come back a day or so later to finish off.
>I keep changing my mind over commenting, do I do it every line or
>only commenting when it is not absolutely obvious in the code. I
>try to make it that you never have to read the code to see what is
>going on you should be able to from reading the comments. As you can
>see I keep changing my mind.

Well, some of this relates to using sensible names in variable declaration.
If you use names like "foo" and "bar" then you have to explain  what these
mean in a comment, each time you use them. If you use names like
"time_of_day" then the line of code probably does not need a comment, the
comments at the beginning of the block should do, with the occasional
interspersed comments like "update hours here".

>I keep to high level languages for most of my coding and only code
>in asm for the interrupt routines and speed related issues.

Well fair enough, but somewhere along the line the program structure still
needs to be laid out, and the method I showed is just as valid for an HLL as
ASM.

>One trouble with the comments is the headers take more space than the code!

Maybe, but if that is what is necessary to explain how the code works then
so be it. You should have enough comments that you can come back to it some
time after not having dealt with it for a while, and be able to pick up
enough from the comments that you get no surprises when you need to alter
the code. This is why it is necessary to do copious comments when doing some
real tricky coding that uses sneaky tricks with flags or registers.

Include anything that might be a caveat if you wish to do something else on
a port later. One that caught me out was with the 16F877, using I2C. It is
documented that you cannot alter the TRIS register once the I2C port is up
and running, without possibly locking up the I2C port, even though it is
other bits that you are altering. This is the sort of "gotcha" that needs to
be documented with a comment in the port declaration section of the code.

I have subroutines that do things like send CR/LF to the serial port. The
comments in the header are probably twice the number of lines that are
occupied by the code, partly because the header is built around a standard
template. The code is self explanatory really, but the header helps to
identify where the subroutine is when scrolling through the code.

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

2003\02\20@041301 by John Sanderson

flavicon
face
Hello Timothy & PIC.ers,

As has been pointed out by a few others, do some research on state-machines.
I had only a vague idea of the concept when I started using PICs, and
somehow (eesshh.. brain-burning stuff) produced my original products
without them.
The project definitions would not differ vastly from your own.

One day, browsing through the p*clist, I came across Andy Kunz's treatise on
his use of the things. He gave us some very tightly written asm code, which
I scratched my hair out trying to follow, but the concept was very clear
:--

LOOP_1      looping in a known state, give it a number (eg. 0-100).
|
\/
monitor all possible trigger conditions which could kick the program to
another state.
|
\/
on recognition of any such trigger (stimulus) call a transition subroutine,
followed by a destination state.
The transition subroutine *and* destination state are both optional, the
destination state can even be the original one.
|
\/
no stimuli?  >> goto LOOP_1

The whole shebang gets formalised in a neat table, I've been adapting the
technique for +/- 4 years now & can't consider using any other way of
writing code for target apps. with multiple stable states.
I'll send you more info, off-list if you want.
..mmm... If Andy's around maybe he could comment & give us the latest
skinny on these..

       best regards,   John

{Quote hidden}

..
<el snippo>


eMail from the desk of John Sanderson.
JS Controls, PO Box 1887, Boksburg 1460, Rep. of S. Africa.
Tel / Voice / Fax  :  011 893 4154
email  :  jsand @pixie.co.za
Cell : 082 741 6275
Manufacturer & Purveyor of laboratory force testing apparatus and related
products & services.

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

2003\02\20@050803 by Timothy Box

flavicon
face
part 1 3846 bytes content-type:text/plain; (decoded 7bit)


The state-machines type of programming really has me very interested. I have
been using that type of approach in my interrupt routines. I was worried
though that I was writing poor code as the flow was in trapped in my head
and could never document that flow easily with just comments at the end of
the line. The fact that it is a well recognised system and that there are
proper ways to generate a "neat table" for the permutations is some thing I
have to follow up.

This is really what I have been looking for!

The fact that Timers are an integral part of the system is really at the
heart of my programming philosophy. I never use a DELAY routine, it is such
a waste of processor time. And as a result I have not yet had to go above
4Mhz except on speed critical systems such as encoder readers. In some of my
programs I have up to 36 timers running.

As a thank you to every one I have attached a timer routine that I use. It
is very compact (only for the 18 series) and very expandable. The code in
the file is configured for 24 16 bit timers. To use load the timer with the
value you wish to count down from. Set the appropriate bit in TMRFLAGSX.X
and away it goes. Just check the bit to see if it has timed up.


Thanks

Tim

{Original Message removed}
part 2 4240 bytes content-type:application/octet-stream; (decode)

part 3 2 bytes
-

2003\02\20@052049 by Russell McMahon

face
flavicon
face
> As has been pointed out by a few others, do some research on
state-machines.

A state-machine should not be feared as something complex - it is simply a
structured way of looking at a set of conditional jumps or case statements.
Despite this it is a very powerful and useful model of many types of
reality.

Another major aspect of state machines is that they lend themselves
absolutely ideally to interrupt driven operation. Trying to perform multiple
tasks ("multitasking") without using state machines (or a Real Time
Operating System (RTOS) which effectively does the same thing) is very very
hard. With state machines, on each interrupt you generally increment (or
decrement) a timer and then inspect a list of activities to see if each
requires "service" at the resultant timer value. (Rather than sharing a
single timer, you may have one "timer" or software counter per task and
process the related task when the timer reaches zero.) Any task requiring
service  directs you to its current state. Appropriate activities (if any)
are performed. A decisions is made as to what the next state should be and
the appropriate timer is reset to wake you up again in this new state in due
course. It may sound a little complex if you've never done it but it makes
life much much easier than alternatives.



As a typical example I have a multi state-machine application (versions
happen to be on AVR & SX but that's irrelevant) that

- reads a 9600 baud hardware UART and carries out basic actions
- * implements a 4800 baud software UART to talk to a GPS unit
- * reads a magnetic card swipe reader (2 channel clock and level data
inputs),
- switches on and off data and power to a printer and GPS,
- * reads the speed of a serial square wave (vehicle speed), ,
- Operates a serial input shift register to add extra input lines.
- Writes to a parallel data port.
, (* Optionally implements another software UART to talk to a terminal, )
- * Implements a circular buffer to buffer GPS and magnetic card reader data
to hw UART.
- Sends a subset or all or no GPS data to hw UART.

Items marked with a * are interrupt driven state machines that operate
entirely autonomously as "virtual peripherals" (to coin a phrase :-) ). They
need no program intervention to operate and may as well, from the
programmer's point of view) be hardware peripherals (once you've got their
software working :-) ).


Example of an interrupt driven software UART Receiver
This requires ONLY 2 states!
Assume
   An IRQ occurs at 4 x the bit rate
   At each IRQ process the current state.
   A timer named Timer (just a memory location) is decremented once per
interrupt

This is indicative of state machine method - not of good programming style
:-)
(ie this is to show method, not how it would necessarily be done in detail).

NO bells and whistles here (no start bit recheck, stop bit check etc)
Data "appears" in DatatOut when a byte is received and flag ReadyFlag is set
to 1.
User must retrieve byte before another byte is received and reset ReadyFlag
to 0.
(Could as easily be interrupt on output)
Data is N81 (8 data bits no parity, 1 start, 1 stop).
E&OE (written on the fly).

____________

Initialisation ; call me once at start up
   State = 0
   ReadyFlag=0
   Timer = 1

; __________________

; INTERRUPT CODE:
   ; once per interrupt
    Decrement Timer
   If Timer > 0 then goto otherstuff
   If State = 0 then goto State0
   If State = 1 then goto State1
Otherstuff:
   ..................
; ______

/ State0:
If input = high then     ; Loop forever while line idle
   Timer = 1    ; do state 0 again in 1 tick
If input = low then     ; start bit
   Timer = 6                ; no debounce check
   State = 1                 ; next time do bit inputting
   Counter = 8           ; inputting 8 bits
   Data = 0
goto otherstuff     ; or some other common end point


/ State1:    ; input a bit
Place input bit into carry
Rotate Data right with carry    ; input bit moves into MSB
Decrement Counter
If Counter = 0 then
   State = 0
   ReadyFlag = 1
   DataOut = Data
   Timer = 1               ; half bit time
If Counter >0 then
   timer = 4               ; wait one bit time then come back here
goto otherstuff     ;  Djkstra would be sad :-)

; That's it.

;Try it, you'll like it.

           ; Russell McMahon

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

2003\02\20@070947 by John Lawton

flavicon
face
At 09:08 20/02/03, John wrote:

>One day, browsing through the p*clist, I came across Andy Kunz's treatise on
>his use of the things. He gave us some very tightly written asm code, which
>I scratched my hair out trying to follow, but the concept was very clear

John, could you point me to that posting please?

John

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
John Lawton Electronics
Custom Electronics Design & Development, Cambridge, UK
Tel 01223 520604  designspamspam_OUTjle.co.uk  http://www.jle.co.uk
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

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

2003\02\20@072832 by Timothy Box

flavicon
face
A state-machine should not be............ "virtual peripherals" (to coin a
phrase :-) ). They
need no program intervention to operate and may as well, from the
programmer's point of view) be hardware peripherals (once you've got their
software working :-) ).

This is all music to my ears. Exactly the way I like to do things.

I am not alone.......

Tim

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

2003\02\20@081802 by Sergio Masci

picon face
----- Original Message -----
From: Timothy Box <RemoveMETimTakeThisOuTspamTJBSYSTEMS.COM>
To: <spamBeGonePICLISTspamBeGonespamMITVMA.MIT.EDU>
Sent: Thursday, February 20, 2003 10:06 AM
Subject: Re: [PIC]: Programming logic solving


>
> The state-machines type of programming really has me very interested. I
have
{Quote hidden}

A "neat [state transition] table" can actually be viewed as set of high
level instructions which have their "microcode" written in native machine
code. If done properly the "microcode" consists of very small fragments of
code which can be shared by several states or state transitions. This means
that several complex pieces of code can often be reduced to a single simple
code fragment and several state entries in the state transition table (which
share the fragment). The logic density goes up for a given amount of program
space at the cost of processing speed, kind of like using interpreted BASIC.
However unlike using interpreted BASIC each "token" in a state machine
(entry in the state transition table) is highly tailored to the job in hand
doing things directly related to the task in native machine code, unlike
interpreted BASIC which is executing pseudo machine code (that emulates a
more powerful processor) which is in turn executed as native machine code
fragments.

State transition tables have a further property that BASIC tokenised
programs don't have. Each state effectively excludes processing that has
been done in a previous state. This is like building your own BASIC
interpreter each time you write a program, with specialised tokens that
thread their way through your code optimising the way the work is done.

Hand coding a state machine using if statements, switch statements or even
function tables is like programming a processor in machine code using
binary. Yes we can all do it but how large a program would you realistically
produce using this method. How long before you fall back to macro assembler
or even a C compiler. To really get to grips with state machines and enjoy
the real benefits they provide, you need to be able play with them as you
would a high level language, tinkering, experimenting. The best way that I
have found to do this is via state diagrams and the appropriate tools. You
need to be able to draw your state diagram, play with the code produced and
go back and edit the diagram until you get what you want.

Ok, I guess talk is cheap so I'll have to point you at something a little
more concrete.

The following set of pages shows what a I mean about small code fragments is
a state machine (you need to click on "STF_M_init_transfer" or "STF_S_busy"
to actually get the code fragment to come up)

www.xcprod.com/titan/ZMECH-DOC/generate/state-machine/MODE-B-STATE-DE
SC/diag-01.html

To actually see what this state machine belongs to (it's actually part of a
much bigger set of interacting state machines) look here:

http://www.xcprod.com/titan/ZMECH-DOC/generate/state-machine/block-indx.html

Regards
Sergio Masci

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

2003\02\27@034511 by jim barchuk

flavicon
face
Hi Timothy, John, and All!

On Thu, 20 Feb 2003, John Sanderson wrote:

> One day, browsing through the p*clist, I came across Andy Kunz's treatise on
> his use of the things. He gave us some very tightly written asm code, which
> I scratched my hair out trying to follow, but the concept was very clear
> :--

There was another request to a more exact reference to this that I don't
see a reply to. Which is why I'm CCing a copy of this direct.

{Quote hidden}

I want to expand on this a bit, to describe how I 'think' about the way
things were explained to me a ton of years ago, mostly about how to design
'code for hardware.' It's applicable to pure software too but particularly
appropriate for hardware.  This guy designed sub navigation systems,
mostly software but was also totally competent in hardware, so he pretty
well knew his stuff. It's also probably related in a way to 'state machine
thinking' but I've never read much about that so don't know.

One of the things he said once was 'there's top-down programming, and
bottom-up, I write inside-out.'

The reason it works so well is that a linear/unidirectional technique can
get one *STUCK* in a spot that demonstrates that the entire original
problem analysis was *WRONG* and an entire data restructure and code
rewrite is required. Starting at one end leads to branches and branches of
routines that each do a certain thing. Then you notice that this branch
way over <--here needs to talk to that branch way over there--> buuut for
some silly reason you didn't realise that as you were writing the
different routines. And that may be either a small detour/adjustment or a
total disaster. Thinking from the inside out helps to see both points of
view at the same time; thinking about the input and output from the point
of view of the process. It also might lead to different and -better- ways
of thinking about the input and output resulting in less hardware or more
efficient user interface or whatever.

At the inside is the -interface- between input and output, described above
as top/input/stimulus, (middle)/process/monitor, and bottom/output/call.

Looking up from the inside, define all the possible 'outside world' inputs
that might be coming in. Arrange data storage for them, bits, bytes,
tables, whatever they require.

Looking down from the inside, list all the routines you'll need to 'make
the data do something,' turn an output on/off, write a byte to a stream,
display something on an LCD, or in pure programming output to a file or
write something on the screen.

Then go back to the inside and think about the process required to connect
the input to the output. That's usually a loop that makes decisions about
how bits and bytes that have been set by the input, and calls appropriate
output routines. It should do very little 'doing,' mostly 'thinking.'

The idea is to try so see the whole picture at once from the process POV,
not just input or output; to see the forest and the trees at the same
time.

Have a :) day!

jb

--
jim barchuk
RemoveMEjbspamTakeThisOuTjbarchuk.com

--
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

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