Skip to content

Digest Number 171

1 message · 2004-03-27 → 2004-03-27 · Yahoo Group era · View archive on archive.org

Participants: Scott A. Rossell

Preserved from the Timex/Sinclair 2068 Yahoo Group (2001–2019), which is no longer online. Text reproduced from the archive.org archive; email addresses masked.

Messages

1. RE: [ts2068] Digest Number 171

Scott A. Rossell · Sat, 27 Mar 2004 11:21

Well, it appears the project has taken a middle-of-the-road solution
using a $300 power train with a $100 Pentium 133 laptop and a control
application written in Liberty BASIC.  An interesting design idea for an
inexpensive convergent laser distancing system came up though using two
cheap laser pointers set at converging angles with a b&w ccd and a
transparent metric ruler to guage distances from oncoming objects (like
walls).  I guess I feel somewhat justified in that Liberty BASIC is very
much like the legacy 8-bit BASIC languages of the 1980's.

-----Original Message-----
From: [email] [mailto:[email]] 
Sent: Thursday, March 25, 2004 1:24 PM
To: [email]
Subject: [ts2068] Digest Number 171



There is 1 message in this issue.

Topics in this digest:

      1. Re: Do you have 8-bit withdrawals?
           From: "Jeff" <[email]>


________________________________________________________________________
________________________________________________________________________

Message: 1
   Date: Wed, 24 Mar 2004 00:16:54 -0000
   From: "Jeff" <[email]>
Subject: Re: Do you have 8-bit withdrawals?

 In response to sarossellsantee:

  This is a tough decision.  I try to use the appropriate technology for
a given situation with the final metric being whether the design meets
the requirements spec.  Most of the goodies are being designed for the
PC market and so you can be pretty much locked into using Wintel
hardware unless you want to spend a lot of time fiddling with writing
drivers and adapting the hardware to your 8 bit micro.  If the project
is what pays the rent, you really need to use tools that will maximize
your productivity and give the customer what she/he wants.  

  Having said the above, if you read the engineering trades (EE Times
and EDN, for instance) you will see that for deeply embedded designs
(usually defined as something with no direct or only a minimal user
interface such as a microwave oven controller), the 8 bit processors are
the bread and butter devices.  There is still a premimum on writing
tight, correct code and using all of the tricks we learned on (in my
case) the TS1000 or other early computers.  Bloated, poorly written
software just can't hack it in this application nor in high rel
applications such as avionics, nuclear control, medical, or other areas
where sloppiness can cost big bucks or lives.

  Too often those who write the specs get enamoured with adding bells,
whistles, and gizmos that either are not well thought out, not needed or
just flat compromise the integrity of the design and push you into using
more technology than needed.  For instance, the example of using a
wireless LAN to update the software in a security 'bot borders on the
criminally stupid.  I spent enough years in military comms to understand
that this operation should be done using physical connection behind a
locked access door on the 'bot to minimize the possibility of corrupted
downloads and/or someone hacking into the 'bot and compromising its
function.

  Use what makes sense.  If relatively simple control and interfacing is
required, 8 bit processors (maybe even distributed processors) probably
make the most sense.  If the on-board functions must include machine
vision, voice recognition, or other computationally exepensive
operations, then use a 32 or 64 bit device with the horsepower you need.





________________________________________________________________________
________________________________________________________________________



------------------------------------------------------------------------
Yahoo! Groups Links




------------------------------------------------------------------------

Indexed under

TS2068 / TC2068