gnupic: Re: [gnupic] Potential PIC project ?


Previous by date: 2 Jan 2006 03:57:27 +0000 Re: [gnupic] Relocatable code and EXTERN, Scott Dattalo
Next by date: 2 Jan 2006 03:57:27 +0000 Re: [gnupic] Potential PIC project ?, Rick Altherr
Previous in thread: 2 Jan 2006 03:57:27 +0000 Re: [gnupic] Potential PIC project ?, Rick Altherr
Next in thread: 2 Jan 2006 03:57:27 +0000 Re: [gnupic] Potential PIC project ?, Rick Altherr

Subject: Re: [gnupic] Potential PIC project ?
From: ####@####.####
Date: 2 Jan 2006 03:57:27 +0000
Message-Id: <20060102041220.1D64B129B60@mmi01.absamail.co.za>

Rick Altherr


On Dec 31, 2005, at 6:57 AM, ####@####.#### wrote:

> > Ser/Par-port to USB-based flash-mem-sticks ?
> >
> > I still maintain that PIC users have been misled.
> > The basic PIC architecture [small memory space], only made
> > sense and was justified for SSI [was it 8, 12, 18 pin DIL - I've  
> > forgotten].
> >
> > For the types of projects now handled by PIC, a 'proper' uProc, with
> > [not a Harvard architecture] a 16bit adr-space is cheaper.

Rick Altherr wrote:
> That all depends on the project.  I have a lot of Atmel ATmega8s and  
> they do
> have some nice advantages (GCC support, libc, etc), but the number of
> peripheral interfaces available on the same class of device is limited
> (ATmega8s have plenty of ADC channels, but no interrupt on change, or  
> other similar features unless you move up to a much larger part).   
> The PICs do have many
> quirks and can be a pain to program, but they do serve a low price  
> point with
> the necessary functionality.  For most cases, a PIC is superior to  
> the Atmels
> simply for the additional features offered at the price point.  For  
> some cases,
> however, the additional ease of the Atmels is better.  But, in either  
> case,
> the Havard architecture has little to do with which uC is  
> appropriate.  The
> instructions available, the peripherals, and the supporting tools are  
> more important.

Yes and I'm guessing that such tools are better availbale for the 
'old uProcs': Z8x, Motorola: 61/3xx & Intel...?

MicroChip is a con: they pulled in the hobbyists with a system which
justified the problematic programming, because of the truly minimum
hardware.   Once the users were invested in the software, they
inappropriately expanded the hardware.  Ie. the software doesn't scale.

> >  ------------
> > USB-based flash-mems have flooded the market, and are very
> > cost effective.  Yet still many machines in use don't have USB ports.
> >
> > Apparently the USB-based flash-mem-sticks are SCSI based.
> > Which will be replaced first [by USB]: ser [RS232] or par-port ?
> >
> USB-based flash devices are actually really USB.  The OS chooses to  
> view them
> as a SCSI device, but there is actually no reason that they cannot be  
> viewed
> any other way.

OK, I made a big mistake. Obviously the SCSI/USB conversion is made
 by the OS.   Since Iomega also converted [par-port] to SCSI, it's
 apparently easier than other options ?

> > I always thought of the par-port [centronics] as being the most
> > 'universal', and that's why Iomega chose the make a par-port
> > external Zip-drive.   Probably the par-port, even with minimum
> > input lines - 3 I think - is faster than RS232 ?
> >
> The parallel port pushes data in parallel (hence the name), and requires
> at least 1 pin per bit of data you wish to send in parallel.  Since the
> overall speed of a parallel port is slower than RS-232, the number of  
> bits sent in parallel is high to achieve an overall high thru-put.

In the past I had investigated making a minimal modem, where the
Tx waveform would be built from a resistance ladder on the par-port.
And I found that par-port speed is high.  Re. USB driver, the par-port
channel can be narrow. Iomega-Zip has 3 [width] drivers, were one
is selected/used, after the unput-width is probed/determined.

> > There could be a lot of users for [PIC based] adaptors for USB-flash.
> >
> > Including a notebook, of my 4 machines only one has USB-ports.
> > So a main advantage of USB-flash tranporting data between
> > machines is not available.  Diskette is becoming increasingly
> > unreliable and annoying ?
> >
> I agree that an adapter could be useful, but what you are actually  
> planning
> to make is a serial or parallel port USB adapter.  That is a fairly  
> complex
> beast, but could possibly be done.  Overall it would probably be  
> easier to
> build a serial port device than a parallel port device, but either way
> will involve an large amount of code to simulate a USB root, not to  
> mention
> the necessary drivers for the OS you wish to use it under.

I'm not planning anything beyound talking. I'm just interested in
the market economics.  RS232 to USB adaptors are already sold.
And there's already a linux Iomega Par-port driver. 

The 'demographics' is fascinating: how long will RS232/parports
still be bulk-produced & why did USB take so long to stabilise.

== Chris Glur.


Previous by date: 2 Jan 2006 03:57:27 +0000 Re: [gnupic] Relocatable code and EXTERN, Scott Dattalo
Next by date: 2 Jan 2006 03:57:27 +0000 Re: [gnupic] Potential PIC project ?, Rick Altherr
Previous in thread: 2 Jan 2006 03:57:27 +0000 Re: [gnupic] Potential PIC project ?, Rick Altherr
Next in thread: 2 Jan 2006 03:57:27 +0000 Re: [gnupic] Potential PIC project ?, Rick Altherr


Powered by ezmlm-browse 0.20.