"since some PICs have an "unadvertised"  4-bit D/A"

I had not herd of that, I think a Google search is in order, combined with
Joe's  tip that could be a very useful tool.
any pointer would help, but I don't want to derail the thread as the topic
is getting interesting.

Cheers
Chris



On 19 April 2013 22:31, Barry Gershenfeld <gbarry42@gmail.com> wrote:

> I like that idea!  And since some PICs have an "unadvertised"  4-bit D/A,
> this suggests a zero-added-parts option that I may try out someday, just =
to
> do it.
>
> I'm encouraged to see that some people stick to the dirt-simple method of
> timer flags and explicitly coded switch statements as state machines.  Th=
is
> technique has worked very well for me.  Any application that needs far le=
ss
> time that the processor provides is well adapted to this.  And the
> processors just keep getting faster (with more memory) anyway.  There are
> even cases where there's one time critical task, and that can be handled
> and still leave left over time for all the slow running stuff to get done
> as well.   I imagine DSP work wouldn't fit well here.
>
> I have inherited other people's "task" designs, and they did work and wer=
e
> somewhat fun to use.  But they didn't really accomplish anything that I
> couldn't figure out how to do otherwise.  And then we have the embedded
> OSes  with the threads.  And the programmers end up with their threads
> locking out the other threads so nothing bad happens.  So then it perform=
s
> the same as any of the preceding schemes.  But they're trickier to manage=
..
>
> Your outlook will, of course, differ.
>
>
>
> On Fri, Apr 19, 2013 at 9:30 AM, Joe Wronski <jwronski@stillwatereng.net
> >wrote:
>
> > For tweaking the amount of code executed in each state machine, it can
> > be useful to use a D/A converter, or a few (3) bits driving an R2R
> > ladder.  Say you have 5 tasks in your main loop:
> >
> >
> > int main() {
> >      // initialize stuff...
> >      while(1) {
> >          one_machine();
> >          two_machine();
> >          ...
> >          five_machine();
> > }
> >
> > You can assign each machine an int value, and start each machine's
> > routine with an assignment of it's value to the D/A or R2R port. You ca=
n
> > watch the D/A or R2R with a scope, and learn how the work is being
> > distributed among the machines, and adjust code based on that.
> >
> > #define ONE_VALUE 1
> > one_machine() {
> >          r2r_port =3D ONE_VALUE;
> >          // work...
> > }
> >
> > I don't recall where I first heard of it, but I've used it and it was
> > useful.  If focusing on a single machine, you can use the same techniqu=
e
> > for each state in the machine.
> >
> > Joe W
> >
> >
> > On 4/19/2013 3:23 AM, Veronica Merryfield wrote:
> > > I have used a state machine based co-operative multitasking approach =
in
> > many systems. The main code is a loop calling each task state machine,
> > which is a large switch statement, usually. Finding the right size of
> block
> > and unrolling loops can get tedious and it can look messy but it does
> work
> > well. I have had such systems deal with timers and comms, the interrupt
> > handles just raise flags and the code in the state machines handles
> things.
> >
> >
> >
> --
> http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
> View/change your membership options at
> http://mailman.mit.edu/mailman/listinfo/piclist
>
--=20
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
.