[Coco] COCO Robot update.

[Frank Pittel]

Once upon a time the cost (in term of complexity, time, etc) was high
enough that it was important to keep the count down. This was back in
the day when the "support" chips cost more then the processor. Having
a microcontroller that eliminates the address decoding and manipulations
with the control lines/buss and chips that go along with that was made it
fast and cheap to have multiple micros.

My introduction with microcontrollers started with the 68hc11 and while an
improvement in the microprocessors but clearly a long way from current offerings.
By removing all or most support hardware the price has gotten to the point of it
being faster, easier and cheaper to use multiple smaller micros instead of trying
to get all of the software into one!

The Other Frank


On Sun, Apr 08, 2012 at 12:00:44AM -0700, Steve Bjork wrote:
> I find it interesting that the idea of using distributed processing
> was against the grain.  After all, modern object-oriented
> programming is distributed processing of a program.  Be it hardware
> or software, I find that breaking down the job into small and easy
> to manage tasks makes for easy to design and build systems.  (and a
> lot less errors in the final product.)
> 
> All of may Z-80 and 6809 games used object-oriented programming.
> Since the name "object-oriented" had NOT yet to be coined, I called
> it D.C.B for Data Control Block coding.  But this style of coding
> was the natural direction programmers were taking the art.
> 
> In my Halloween display that I do every year, the whole system is
> based on simple modules that preform their task independently.
> There are signal lines that tell some props to fire while keeping
> other props quiet.  (just like the singals you send to a code
> object.)  One of the key signal is the "QUIET" line that keeps other
> props from firing when a prop has pulls it low to do its show.  When
> the line returns to the high state, another prop can grab it to do
> its show.  To keep props from colliding,  each device has a priority
> number start with 1 to 10.  (It waits that number of seconds before
> trying to grabbing the control line.)
> 
> The great benefit to this system is no Master Control Program to
> waste time on.  (Or take over the world of TRON)
> 
> On a picaxe side-note, the new 18m2+ chip can run 8 tasks at the
> same time.  The older 18m2 could only run 4 tasks at once.  All in
> BASIC to boot!
> 
> Steve
> 
> 
> 
> On 4/7/2012 10:25 PM, Frank Pittel wrote:
> >Steve,
> >
> >My understanding was that the robot control was to be built "in parts"
> >and that the OP was looking for a way to "blink" leds at random rates.
> >While that can be done with "discrete" electronics I've come to the conclusion
> >that these types of things are better done with microcontrollers (not microprocessors),
> >pics, etc. Let's face it $3 for an 8pin DIP microcontroller is going to be able
> >to do a lot more then $3 in 555 timers, resistors, caps, etc!
> >
> >While the larger PICs are capable of doing a lot on there own they are by definition
> >intended to work under the control of a more capable processor. When I first started
> >working with them a year or so ago that fact went against the grain for me. I kept trying
> >to do everything with a single controller. Then it dawned on me that I'm better off using
> >2,3 chips of lower capability under the control of something more powerful then trying to
> >do it all from one very powerful chip.
> >
> >Currently I'm working with the parallax "propeller" (an 8 "core" controller) and their discontinued
> >"SX" pics. Both can be programmed in Basic as well as assembly. The propeller can also be programmed
> >in forth and C!! As soon as I'm done with my current project I'm going to look into the picax. I think
> >it can be used for a number projects I have in mind. Unfortunately none involve the coco. :-(
> >
> >The Other Frank
> >
> 
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco