The Cyber-Spy.Com Usenet Archive Feeds Directly
From The Open And Publicly Available Newsgroup
This Group And Thousands Of Others Are Available
On Most IS NNTP News Servers On Port 119.
Cyber-Spy.Com Is NOT Responsible For Any Topic,
Opinions Or Content Posted To This Or Any Other
Newsgroup. This Web Archive Of The Newsgroup And
Posts Are For Informational Purposes Only.
From: "Sergio Masci"
Subject: Re: Program help needed
X-Newsreader: Microsoft Outlook Express 5.00.2615.200
Date: Sat, 21 Sep 2002 16:25:07 +0100
NNTP-Posting-Date: Sat, 21 Sep 2002 16:19:21 BST
Organization: ntlworld News Service
Ok you asked for opinions.
Break your code down into modules and check the correct operation of each
module in isolation from the others. By this I meen feed values in at one
end and check the results at the other. Use a simulator for this.
Alternatively you could break your system down into seperate well defined
states and check the operation of your system under each state. You would
use input changes and timeouts as events. When an event occures your system
would perform a transition from one state to another. During the transition
you would execute a state transition function which would probably
correspond to some code you have already written somewhere in your existing
system. While in a particular state you might monitor some external
condition and generate an event if it occures or does not occure within a
given time. This would be a state monitor function and again you probably
already have this code somewhere in your system. This type of system is
called a state machine. Withing your current monolithic system (this is a
technical and not a derogitory term) you probably check for many things in
one or more very big loops. Your new state monitor functions would break
these loops down into much smaller sections of code since not all the code
in your loops will be relevent in all states. If you find that your state
monitor functions or event transition functions are checking for or many
things each time through the function and that this processing is common to
and replicated in many places, you should consider further breaking down you
system into multiple state machines. Here a state machine would handle a
subsystem. Three subsystems three state machines. They can comunicate with
each other by sending each other events OR you could have an additional
state machine that looks after the higher level functionality and receives
events from and sends events to each of the subsystem state machines.
There is a tool that allows you to build state machines for PICs by drawing
them as diagrams. It also supports multiple interacting state machines on
the same PIC. It has a powerful simulator that can handle multiple
interacting PICs and is state machine aware so it can trap missed events and
shows event transitions. It also handles source level debugging of your
assembler and XCSB (structured PIC BASIC).
The assembler that this tool comes with also generates optimised assembler
from high level statements such as A[j] = B[j] * C[j+1] So that should also
be of benefit to you. An online demo of the high level capabilities of the
assembler call XCASM is available at: http://xcprod.com/titan/web_demo.html
Although the simulator is currently only specific to the 16F84. The
assembler and XCSB can be used to generate code for any of the 14 bit core
PICs such as the 16F628, 16F874 and the 16F877 etc.
Look at the PIC edition of ZMech at http://www.xcprod.com/titan/ZMECH_PIC
The non PIC edition generates C code which you can then put through any of
several existing C compilers.
Danny wrote in message
> Hi, I started to write a program for the PIC microcontroller as a burglar
> alarm, the program was written in .asm/assembly language.
> The program uses the timers, macros, and is fragmented in the respect that
> it has a different subroutine for each function it has to handle.
> The program now doesn't seem to work, could someone please help me by
> looking over the program, and perhaps debugging it, or telling me what the
> mistakes are, anything would be a great help, and the more opinions I can
> get the better. For the length of the program, it would be a great shame
> having to completely scrap the whole lot.
> If any one would like to help me at all, please post back, and I'll send
> the source code, and/or the project files that have been build from MPLAB.
> The program is being written for the PIC16f874
> Thanking in advance
Go Back To The Cyber-Spy.Com
Usenet Web Archive Index Of
The sci.electronics.design Newsgroup