[PCR-1000] PCR-1000 Web Control?

[Jay A. Kreibich]

On Mon, Feb 09, 2004 at 05:39:22PM -0000, Max Topley scratched on the wall:
> ----- Original Message ----- 
> From: "Jay A. Kreibich" <jak@uiuc.edu>
> To: <pcr-1000@mailman.qth.net>
> Sent: Monday, February 09, 2004 4:14 PM
> Subject: Re: [PCR-1000] PCR-1000 Web Control?
> 
> 
> >   I've been looking at doing something similar with a TINI module:
> 
> Have you seen the prices? OUCH!

  Yeah... about $65 USD for a module that includes everything plus
  $35 USD for a dev board *with* a regulated power supply (at least
  inside the US).  I know that's still over twice of a PIC, but you
  also don't have to deal bits and parts.  Two parts, ready to be put
  in an enclosure for most projects.  The time that saves me is well
  worth the money.

  It is also a bit more robust with on-board Ethernet, CAN, I2C,
  one-wire, and 3 serial interfaces built in, along with an 8 bit
  databus that can be exposed if you know what you are doing.  Also
  supports IPv6, which is useful for large internal networks you want to
  self-configure.  The CAN and I2C interfaces (and libraries) are
  also very useful for integrating things like that audio encoder chip.

  I realize there are PICs that support these kinds of interfaces, but
  I don't recall one that supports all of them.

  So in some sense, you get what you pay for.  The question is then
  what you need.  TINIs are overkill for most of the PIC projects I've
  seen, no question about it.  If all I wanted was a "networked serial
  port" to control the PCR-1000, I'd say that about this project too.

  But not if you want to include the audio chip.  I think it becomes an
  option worth looking at for something like that.

> >   This particular chip does bi-directional MP3 [d/e]ncoding in
> >   hardware,

> Nice chip. What's the guide price?

  Been awhile since I seriously looked at this, but I think it is
  around $35 USD, q 1.

> >   The TINI is a bit more expensive than the PIC, but comes with a full
> >   TCP/IP suite,
> 
> But Microchip's TCP/IP stack is free, as is their IDE with assembler +
> simulator. Their development kit is a LOT cheaper, as well. 

  Microchip's is cheaper than free?  Any machine with any Java IDE will
  work as a base development platform.   DallasSemi's conversion tools for
  translating the generic .class files into the custom TINI class files
  are free also.  You have to agree to a license that puts some limits on
  commercial distribution (mostly having to do with compatibility, not
  cost-- all these conditions are met if you use their pre-packaged 
  modules), but the tools and runtime are both free.  There are some 
  assembly tools out there too, and the APIs provide ways to call 
  "native" functions for those one or two critical loops.

  The only thing that costs is the third party C compiler, if you
  choose to go down that route.  And, yes, it is very expensive.

> It's largely a
> matter of taste, though. I've used PICs a lot, and I have the equipment
> available, such as an ICE and a "C" compiler.

  Yes... if you have an investment in PICs, they are less expensive and
  very flexible for fairly simple projects.  My experience is that the
  "startup" cost for PICs is much higher, however.  In my case that
  counts.

  And actually, I'll even have to take the "simple projetcs" part back.
  Looking at the latest samples of PICs, I see they have come a long
  way since I last looked at them.  Some of these are, indeed, very nice
  packages.

> > and allows you to do all your development in Java (for
> >   what that's worth).
> 
> YUK! Not for bare-metal coding, thanks.

  Well, like I said, "for what that's worth."  For some people this is
  a plus, for others it is not.
  
  That said, Java's actual code is more bare-metal than most assembly 
  hackers are willing to admit.  After all, every Java compiler out
  there compiles Java code into a virtual ISA.  There are some chips
  out there that run the ISA directly, although the TINI is not one
  of those-- there is a set of tools to convert the Java .class binary
  files into native instructions for the TINI.  End result is that most
  of your code is compiled down to the microcontroller's native ISA--
  not a virtual machine or emulation.  This is true about nearly all Java
  environments using JIT compilers, but in the cast of the TINI it is a
  pre-process.

  Now it is still true that the code is compiled, and there isn't quite
  the control you have with assembly, but that question is more or less
  Java independent.  Personally I think that attitude is really
  stuck in the 80s.  For most of the world "whole project" benefits of
  a high(er) level language far outweigh the performance advantages for
  anything more complex than a 100 lines of code, or so.  If you do
  extensive profiles and find a critical loop, re-code that (and only
  that).

  Also don't forget that we aren't exactly counting individual cycles
  here.  It isn't difficult to tweak the TINI microprocessor to run at
  75 MHz.

> Java's a fine language on PCs with oodles of RAM, but any heap-based 
> language really blows goats in an embedded system without
> memory management.

  I would agree that is one of Java's biggest weak points.  Memory
  management is a bit tricky.  Again, however, much of this is from the
  hype surrounding the language, and not the actual environment.  If
  you will recall, way back when Java was originally designed it was as a
  embedded language that allowed extremely fast prototyping.  The whole
  idea of a universal VMs for desktop systems came later.

  If you strip the language down and throw out all the GUI stuff (which
  consumes huge amounts of resources) and get down to the core language,
  it isn't too bad.  As much as I tend to dislike GC languages, I also
  have to admit that a memory leak in a embedded device is much more
  critical than one in a computer application.  People have a
  remarkable tolerance for dealing with a computer that crashes.  They
  do not deal well with an alarm clock or remote control that crashes.

  And no, 1MB of run-time RAM is not a ton of memory next to my laptop,
  and you can't be silly about it,  but it is an amazing amount next to
  the PICs we were using when I was a student (again, I realize that
  some modern PICs pass this up).  Again, it depends on your needs.
  Most people hit the 1MB file-system flash limit long before they hit
  the run-time RAM limit.

  There are other advantages Java.  If, for example, you are writing
  something that doesn't involved physically adding hardware to the dev
  board (e.g. everything is hooked up via the standard ports such as
  the serial ports or other I/O ports) you can develop one set of code
  for both the PC and the TINI.  The exact same serial port and
  networking code that runs on the TINI will run on the PC.  This is
  especially handy for writing protocol encoding/decoding modules for
  things such as XML-RPC where you have a PC trying to manage one or
  more TINIs on the network.  They can both run the exact same code
  base which makes development of the protocol handlers much easier and
  faster.

  Like I said before, most of your choice boils down to what you need.
  In my case, I'm much more interested in software than hardware, so
  I'll happily pay more if it reduces the time I need to fiddle with
  physically putting things together.  For me, the TINI does this.
  This isn't true for everyone.

   -j




-- 
                     Jay A. Kreibich | Integration & Software Eng.
                        jak@uiuc.edu | Campus IT & Edu. Svcs.
          <http://www.uiuc.edu/~jak> | University of Illinois at U/C