Subject:
Re: [gnupic] Potential PIC project ?
From:
Rick Altherr ####@####.####
Date:
2 Jan 2006 05:08:25 +0000
Message-Id: <CC895236-D22F-4CD5-A777-02B2A6DCCA6E@kc8apf.net>
See below
--
Rick Altherr
####@####.####
"He said he hadn't had a byte in three days. I had a short, so I
split it with him."
-- Slashdot signature
On Jan 1, 2006, at 8:12 PM, ####@####.#### wrote:
> 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.
This is true for many different things. The biggest problems with
PICs are that Microchip is rather inconsistent with how they do
things. The instruction set stays relatively similar from device to
device, but the programming methods change with nearly every chip
release. The other problems with the hardware are more of an issue
with a not completely thought out design for the uC. A simple
harvard architecture with a set of general purpose registers, stack
manipulation instructions, and a stack pointer would make things much
nicer and not add much in the way of cost. I'm sure that a number of
the Microchip engineers wish they could go back in time and change
how they did the first chip. Now they are stuck with a large legacy
base and just have to hack around it to make it better.
>
>>> ------------
>>> 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 ?
In all honesty, you can always convert from a parallel to serial
device quite easily. The parallel port does provide an advantage in
raw throughput since it sends as a relatively fast rate and sends a
byte in parallel allowing for speeds up to 5MB/s. Serial ports are
typically (on a PC) 115Kbps. Using a parallel port to emulate
something like USB would simply require a shift register in the
device which would just eat up board space. Either that, or you
would need all the pins to emulate the parallel port on the PIC.
>
>>> 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.
parallel ports can be high speed, but are really limited by how fast
the computer can copy data into the registers to send it. Serial
ports are also limited, but usually by the internal logic. Either
way can be implemented, but serial ports offer a simpler
implementation and generally require less parts.
>
>>> 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.
>
Every new technology takes a while to catch on. In the computer
space, it can take a very long time for the major producers to
actually implement and ship a computer with the new technologies.
USB ports have been on computers since 1998, but the problem of
having useful devices was tantamount. Initially, support for USB
keyboards was dismal. For the longest time, the only useful USB
devices were mice and printers. Even those were difficult to get
working correctly. Not to mention that real USB HID support was not
present in any version of windows until Windows 98 SE.
Legacy devices are hard to get rid of because they are well known and
simple. I doubt serial ports will ever go away until you can use the
USB client portion of a uC with the same amount of ease.
> == Chris Glur.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
>
