[Message Prev][Message Next][Thread Prev][Thread Next][Message Index][Thread Index]

Re: Switching audio via an Ocelot and SECU's



Ah, I see the problem.  You are obviously from the software world.  I'm from
the hardware world.

I come from an era when we could do just about anything in 16K.  In another
life we developed a computer graphics adventure game (Powerstar) for the old
Atari 8-bit computer.  It fit into a 16K cartridge, and included 256 graphic
images, text for each location, puzzles, and some animation.  While a LONG
way from today's graphics, we managed to build each image from roughly 16
bytes of compacted data in a 1/4 second.  Several lines of text describing
each location cost us another 16 bytes average.  The Ocelot has more memory
than I will ever need.

Regarding CMax, it is NOT a natural for me.  It comes from the industrial
automation world, and evolved from relay logic.  It is not at all like
assembly language programming.  Assembly is similar to high level, but
without all the structure.  It has subroutines, passing multiple parameters,
and all that.  I did most of my work with Motorola microcontrollers, which
have a rich set of instructions, including hardware multiply.  The PIC on
the other hand is downright archaic.  I think it received so much acceptance
because it is cheap and simple.  Did I say it is CHEAP.

I built industrial automation equipment (another garage operation) for
companies that relied on that equipment for their productivity.  It had to
work non-stop day in and day out.  It was a crisis when something broke
down.  I still remember an early morning I was called into their facility to
fix a problem.  They said "Your equipment won't indicate continuity!", and
placed a clip lead across those inputs to my controller to prove it.  I ran
a short internal diagnostic, and said "Your clip lead is open."  After that
they checked their wiring first.

I've participated in the ADI users group for several years, and have had to
find things myself.  No, it's not Google.  But it works.

So, go ahead and get your mini PC and all your high-end GUI stuff.  My
simple Ocelot and X10 will still be chugging along fine until we finally
have to downsize a decade or two from now.  It's kind of like the
refrigerator.  It does what it is designed to do.  We never really think
about it, but it would be hell to be without it.

Jeff

"Robert Green" <ROBERT_GREEN1963@xxxxxxxxx> wrote in message
news:bradnXYix52n7n_enZ2dnUVZ_t2dnZ2d@xxxxxxxxxx
> "Jeff Volp" <JeffVolp@xxxxxxx> wrote in message
> news:6csEf.909$fM1.140@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> >
> > I have to jump in here to defend ADI.  Being a wizard on imbedded system
> > design doesn't make one a wizard on HTML or JAVA.  They are different
> > skills.  And I would rather have someone who focuses his full effort on
> > hardware designing my automation equipment.
>
> C'mon Jeff, you don't have to a wizard to know there are serious, serious
> problems with the ADI site.  Part of being a good manager is to *find* the
> people with the skills you lack to perform quality work that you can't do,
> but that *should* be done.  I really feel as if I have to pull teeth to
get
> to information buried in the forum.  A company's website projects its
> corporate image - that's just how it is - it's not my interpretation.  If
a
> company's website is full of warts, it just *has* to make a logical person
> stop, think, and worry about overall quality issues.
>
> > Our Ocelot runs 24/7 week after week with no glitches.  That is expected
> > of industrial automation equipment, which is where the Ocelot came from.
> > People here talk about X10 not being reliable.  I would never trust my
> > automation to a PC running 24/7, at least not using any M$ software more
> > complicated than DOS.
>
> I'd use Linux on a MiniITX with a fanless 1GHz CPU, ethernet, video,
audio,
> USB, 256MB of memory, Firewire, serial and parallel ports and it would
cost
> me *less* than one Ocelot and one SECU or Bobcat module.   It would likely
> take up the same amount of cabinet space, too.  But it would be infinitely
> more capable.  What happens when you run out of memory on the Ocelot?  Can
> you snap in another 1GB?
>
> Then there's C-MAX,  It's a natural language for microcoders like you and
> Dave but it's just plain bizarre to anyone like me who was taught
structured
> and modular programming.  So, to use an Ocelot I need to learn a new
> webforum tool, a new programming language unlike any I have ever dealt
with
> and work around frustrating limitations in I/O and RF connectivity.  With
a
> major player leaving like Dan Boone leaving, a website with a homepage
> invitation to a *2005* conference, a hard to search, hard to use forum and
a
> *unique* programming language, Ocelot's fading fast as a serious candidate
> for running my new home for the next 20 years.  It's also a PITA to have
to
> search for Ocelot or Leopard information because 99% of such search words
> lead to cats.  There's lots and lots of discussion of the VIA Eden MiniITX
> boxes:
>
> http://groups.google.com/groups?q=via+eden&sa=N&tab=wg
>
> in lots of different conferences.  It's a vibrant, growing product and
there
> are dozens of websites devoted to some really creative uses of the
product.
> Sadly many of these apps can't run via Ocelot, they are really too
complex.
> Maybe the ADI site and the "feline" product line is moribund because the
> handwriting is already on the wall.  Fanless, low-power CPU PC's running
> Linux from a compact flash card are the future for HA embedded
controllers.
>
> Then there's the issues of spares.  If I carried on-site spares for my
> Ocelot system I'd have a box of extra and expensive HW doing nothing.  A
> spare for a MiniITX box is a working computer that can be earning its keep
> running tests while still serving as a spare for the HA server.
>
> I haven't punched all the factors into my Multiple Attribute Decision
> Modeling software, <g> but it's becoming more and more clear that a mini
PC
> is the way for *me* to go, especially now that they have so many I/O ports
> embedded on the motherboard.  I can store data from transponders which the
> Ocelot won't easily allow, I can hook in digital capture boards, use large
> touchscreen monitors, incorporate talking caller ID, MUX switching via
> serial port, IR I/O via the printer port.  For HA purposes Dave's BXAHT
was
> the missing link for me.  While I would have to work it over hard to talk
to
> an Ocelot the way I wanted, it can talk to a PC serial port just fine!
The
> execution speed of a 1 GHz PC running from a CF card should be quite fast
> enough for most apps!
>
> Will a mini PC crash more than an Ocelot?  Absolutely.  But if you run the
> right OS, modern PCs are really far more reliable now than they ever were.
> Can it do more than the Ocelot?  Absolutely.  Given that they cost the
same
> now, it's a tradeoff I am willing to make.   It's a tradeoff I feel I
*have*
> to make because I sense a wilting of ADI's commitment to the Ocelot world.
> I've been orphaned more than once my manufacturers big and small.  It's
not
> a pleasant position.
>
> A mini PC can support real-time video using a USB LCD touch screen for
less
> than the cost of a Leopard.  It may be that we've reached the "tipping
> point" for microcontrollers in that price range.
>
> --
> Bobby G.




comp.home.automation Main Index | comp.home.automation Thread Index | comp.home.automation Home | Archives Home