Searching \ for 'PIC Development Tools' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=pic
Search entire site for: 'PIC Development Tools'.

Truncated match.
PICList Thread
'PIC Development Tools'
1995\11\17@051702 by Joel Carvajal

flavicon
face
Somewhere I read there is a new list for PIC Development Tools.  Please
count me in.

About the Development Tool someone is asking for, I just want to know:

       Do you need to evaluate programs in real-time?

If not, maybe we could design an In-Circuit Simulator.  Here's how it works:

       Code Simulation is on PC.  A circuit containing any microcontroller
       connects to a target board for the PIC.  The I/O lines of the PIC is
       simulated by the microcontroller.  Any instruction causing an I/O
       access will be relayed to the microcontroller by the PC through
       RS232.  The result is non-real time I/O access.

       The microcontroller can do the programming as well.

Sorry I cannot explain the concept fully or clearly.  I'm in a rush so
I'll discuss it more next time -- if anyone is interested please let me
know.

I've designed In-Circuit Emulator for the 68HC11 as a hobby (for work, I
do 32 and 64) maybe I could help out design a low-cost In-Circuit Emulator
for the PIC.

Joel Carvajal
spam_OUTjoelTakeThisOuTspamtds.pfi.net

1995\11\17@090422 by Siegfried Grob

flavicon
face
Joel Carvajal wrote:


> Somewhere I read there is a new list for PIC Development Tools...
I don't know of any. If you have more details, please let us know

> About the Development Tool someone is asking for, I just want to know:
>        Do you need to evaluate programs in real-time?
No! or at least in many cases not.


> If not, maybe we could design an In-Circuit Simulator.  Here's how it works:
>        Code Simulation is on PC.  A circuit containing any microcontroller
>        connects to a target board for the PIC.  The I/O lines of the PIC is
>        simulated by the microcontroller.  Any instruction causing an I/O
>        access will be relayed to the microcontroller by the PC through
>        RS232.  The result is non-real time I/O access.
>
>        The microcontroller can do the programming as well.

In recent years Parallax produced a simulator exactly as you described.
It was called Reflection and was able to simulate the 16C5x, 16C71 and 16C84.
After they released their hardware emulator they stopped production of
Reflection. Once I had such a thing in my hands but other guys had already
played with it and damaged. Inside there was pretty little hardware:
a voltage regulator with the necessary components, a MAX232 for serial inter-
facing, a PIC in DIP18 and another PIC in PLCC44, connected to the destination
circuit via flat ribbon cable and with a DIP18/28 connector at the other end,
substituting the real PIC.

Now that Parallax is not producing Reflection any more, they could release
Hard&Software into public domain? Parallax, we know that you are listening,
are you willing to give us more details? please! If you refuse to tell us
the hardware and PIC firmware, you could at least tell us the protocol used
for communication between the PC running your easy-to-use PSIM simulator and
Reflection, so PSIM could be used with only the hardware to be built.

If only 18pin and 28pin PICs have to be simulated, a 16C74 seems to be the
adequate interface controller. A PIC probably is the best IC to simulate
another PIC. If the user can accept to have two pins unused (necessary for
communication to PC) even the big 40pin-PICs could be supported.


More comments?

Siegfried

1995\11\17@103949 by Bill Cornutt

flavicon
face
----------
{Quote hidden}

And the microcontroller could be a PIC?

Bill C.

1995\11\17@120926 by John Payson

flavicon
face
> Now that Parallax is not producing Reflection any more, they could release
> Hard&Software into public domain? Parallax, we know that you are listening,
> are you willing to give us more details? please! If you refuse to tell us
> the hardware and PIC firmware, you could at least tell us the protocol used
> for communication between the PC running your easy-to-use PSIM simulator and
> Reflection, so PSIM could be used with only the hardware to be built.
>
> If only 18pin and 28pin PICs have to be simulated, a 16C74 seems to be the
> adequate interface controller. A PIC probably is the best IC to simulate
> another PIC. If the user can accept to have two pins unused (necessary for
> communication to PC) even the big 40pin-PICs could be supported.

I'd been thinking of doing this, but using either printer port with either
a simple cable (in case the PIC application needs <=5 open-collector I/O
pins and the rest of the pins can be input-only or output-only) or else
some simple hardware (e.g. 3 74HC125's and 4 74HC574's).  My plan was to
emulate the 16C5X by doing a PIC to 80x86 translation; since the PIC code
is read-only, there would be no need for real-time translation.  If I were
to do this, I would expect to get real-time or near-real-time for non/IO
bound 4MHz applications on a DX266.


'PIC Development Tools'
1997\10\21@072405 by Rob Bristow
flavicon
face
Hi

I am just beginning to do development on the PIC16C73A (about 2 months now) but I am not sure what tools to use in the development.  I would love to be able to develop in C but have been warned that compilers cannot be trusted.  I have tried the PCW C compiler with reasonable, but not brilliant results.  Now I have reverted back to assembly using MPASM.

If anyone has the time or inclination please let me know what the popular/reliable PIC development tools are.

I would appreciate any feedback.

Martin McArthur
weapontspamKILLspamdbn.lia.net

1997\10\21@081144 by tjaart

flavicon
face
Rob Bristow wrote:
>
> Hi
>
> I am just beginning to do development on the PIC16C73A (about 2 months now)
but I am not sure what tools to use in the development.  I would love to be
able to develop in C but have been warned that compilers cannot be trusted.  I
have tried the PCW C compiler with reasonable, but not brilliant results.  Now
I have reverted back to assembly using MPASM.
>
> If anyone has the time or inclination please let me know what the
popular/reliable PIC development tools are.
>
> I would appreciate any feedback.
>
> Martin McArthur
> .....weapontKILLspamspam.....dbn.lia.net

If you really just started and haven't spent one cent, buy the Scenix
development kit for $250. You get a programmer cable that also doubles
as an ICE adapter, and a few samples. The parts are ALL flash, and run
up to 20 times faster than PICs. The Scenix has a few extra commands
to make life easier.
Have a look at http//:http://www.scenix.com for datasheets


Here is more info on the SX Key development system from Parallax
(http://www.parallaxinc.com/)

Comprehensive In-circuit Development System
       Integrated Design Environment
       Editor with find/replace and text size
       Assembler uses popular Parallax PIC16C5x dialect
       Programmer can load PIC16C5x hex files for SX retargetting
       Debugger provides symbolic and source-level viewing
       Assemble, program, and execute with a single mouse click

Miniature SX Key Development Tool
       0.5  x 1.5  module with 4-pin socket for VSS, VDD, OSC1, and OSC2
       6-foot quality coax cable with host serial connector
       Works directly in target system - just provide a 4-pin header
       Single-Step, Breakpoint, and Asynchronous Break at full speed

Complete Development System
       SX Key Hardware
       SX Key Development Software
       2 Sample SX chips
       SX Demo Board
       Source code examples
       Manual


Of course, you can also buy the Microchip PICMaster (ICE) at $2490
and a PICstart plus (programmer) at $148.88 to do the same thing
for PICs. Every time you need a new PICMaster probe for a new part,
it will also set you back a few hundred dollars (EVERY Scenix
chip has a built-in ICE). Except for the 16F84 PICs, you will also
have to throw the parts away after programming, or use the expensive
EPROM version (available in DIP only) that will die if you
write-protect them.

You probably want to know why all Microchip parts aren't flash or
have the bondout pads (present on all the silicon) connected to the
outside world. I have no idea. Maybe Microchip wants to give their
competitors a head start. <VVBG> At least, with the future parts
road map, we can rest assured that Microchip can see about fifty
years into the future to the time that they will, like everybody
else, have flash parts and bondout pins. What a relief.

--
Friendly Regards

Tjaart van der Walt
EraseMEtjaartspam_OUTspamTakeThisOuTwasp.co.za
_____________________________________________________________
| WASP International http://www.wasp.co.za/~tjaart/index.html |
|       R&D Engineer : GSM peripheral services development    |
|   Vehicle tracking | Telemetry systems | GSM data transfer  |
|    Voice : +27-(0)11-622-8686 | Fax : +27-(0)11-622-8973    |
|              WGS-84 : 26010.52'S 28006.19'E                 |
|_____________________________________________________________|

1997\10\21@093218 by Andy Kunz

flavicon
face
At 01:19 PM 10/21/97 +0200, you wrote:
>Hi
>
>I am just beginning to do development on the PIC16C73A (about 2 months
now) but I am not sure what tools to use in the development.  I would love
to be able to develop in C but have been warned that compilers cannot be
trusted.  I have tried the PCW C compiler with reasonable, but not
brilliant results.  Now I have reverted back to assembly using MPASM.

I used to use PCW, and fell back to assembly.  Now I use the HiTech C
compiler and love it!  I've done several projects with it and have had
quite satisfying results.

Andy

==================================================================
Andy Kunz - Montana Design - 409 S 6th St - Phillipsburg, NJ 08865
         Hardware & Software for Industry & R/C Hobbies
       "Go fast, turn right, and keep the wet side down!"
==================================================================

1997\10\21@111726 by Matt Bonner

flavicon
face
Tjaart van der Walt wrote:
> You probably want to know why all Microchip parts aren't flash or
> have the bondout pads (present on all the silicon) connected to the
> outside world. I have no idea. Maybe Microchip wants to give their
> competitors a head start. <VVBG> At least, with the future parts
> road map, we can rest assured that Microchip can see about fifty
> years into the future to the time that they will, like everybody
> else, have flash parts and bondout pins. What a relief.

Tjaart,
Are you trying to put my company out of business?  :-0
If MChip made ALL their parts Flash, then NONE of them would work at
high temperatures.  Maybe 50 years into the future when Flash is as
robust as regular EPROM....okay, maybe 5 years.
--Matt

1997\10\21@134356 by Tom Rogers

flavicon
face
part 0 3150 bytes
!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
Hmmm. OK, Tjaart said:

>If you really just started and haven't spent one cent, buy the Scenix
>development kit for $250. You get a programmer cable that also doubles
>as an ICE adapter, and a few samples. The parts are ALL flash, and run
>up to 20 times faster than PICs. The Scenix has a few extra commands
>to make life easier.
>Have a look at http//:www.scenix.com for datasheets


OK, I did. They're still incomplete. And the development kit isn't available
at any price, to anyone. Best guess at Parallax is "mid-December", and it's
not just because the chips aren't available yet.


>Of course, you can also buy the Microchip PICMaster (ICE) at $2490
>and a PICstart plus (programmer) at $148.88 to do the same thing
>for PICs. Every time you need a new PICMaster probe for a new part,
>it will also set you back a few hundred dollars (EVERY Scenix
>chip has a built-in ICE). Except for the 16F84 PICs, you will also
>have to throw the parts away after programming, or use the expensive
>EPROM version (available in DIP only) that will die if you
>write-protect them.

Of course, nothing. The "also" here is incorrect, because you can't get any
Scenix stuff yet. And when you can, only an idiot would jump right into
releasing a design with one. There is going to be a shakedown period that is
not to be avoided, but may be ignored by the inexperienced. And, just to be
fair, you cannot do with the Scenix embedded stuff what you can with the
PICMaster, unless there's a hugh amount of on chip buffer devoted
exclusively to debug.

>Friendly Regards
>
>Tjaart van der Walt
>mailto:tjaart@wasp.co.za

Regards, yerself. I don't like the misleading tone of your posts. Scenix is
vapourware for now and may be useful some time next year only if they can
stay on schedule and don't have any major glitches in production. All of
which is iffy, to say the least. Hyping unseen products to inexperienced
engineers isn't going to help Scenix any, and isn't going to impress or
influence the people at Microchip.

When the Scenix stuff is available I'll get it and evaluate it, and I'll use
it where prudent. Thats what engineering is all about. For right now, if
anybody wants to do a PIC based design, the choices are Microchip and
Microchip. Which, after careful consideration, I (and a bunch of other
people that have done this before) have decided is a pretty good choice for
some jobs.

The thing is, I know what my opinion is based on. I just can't figure out
what yours is based on.

--Tom Rogers  VP-R&D  Time Tech Inc.
 

1997\10\21@193303 by Andy Kunz

flavicon
face
>>Of course, you can also buy the  Microchip PICMaster (ICE) at $2490
>>and a PICstart plus (programmer) at  $148.88 to do the same thing
>>for PICs. Every time you need a new  PICMaster probe for a new part,
>>it will also set you back a few hundred  dollars (EVERY Scenix
>>chip has a built-in ICE). Except for the 16F84  PICs, you will also
>>have to throw the parts away after programming, or  use the expensive
>>EPROM version (available in DIP only) that will die if  you
>>write-protect them.

Or you can get a Tech-Tools Mathias at half those prices, with tech support
and follow-on that can't be beat!

>""  here is incorrect, because you can't get any
>Scenix stuff yet. And when you  can, only an idiot would jump right into
>releasing a design with one. There  is going to be a shakedown period that

Very good points for all to consider.

Another very important aspect is using a fab-less vendor vs. one with their
own factories.

>Scenix is
>vapourware  for now and may be useful some time next year only if they can

Could it even just be a charade by a another company looking to feel out
the 8-bit embedded market?  Is Scenix still going to be Scenix in another
year, or will it become a subsidiary of Intel or Atmel or Philips or
National etc.

Andy

==================================================================
Andy Kunz - Montana Design - 409 S 6th St - Phillipsburg, NJ 08865
         Hardware & Software for Industry & R/C Hobbies
       "Go fast, turn right, and keep the wet side down!"
==================================================================

1997\10\21@193918 by William Chops Westfield

face picon face
I lot of the people on this list probably shouldn't consider designing
with a scenix until you can buy them from digikey (and we'll see what the
low-volume prices end up like.)  Otherwise, you might as well be using
(insert favorite unobtainable microcontroller here.)

BillW

1997\10\22@005407 by tjaart

flavicon
face
Tom Rogers wrote:
>
> Hmmm. OK, Tjaart said:
>

<A lot of flames extinguished. Snippety snip. Whew!>

> The thing is, I know what my opinion is based on. I just can't figure out
> what yours is based on.

The following :
1) All the other vendors have already gone flash. Not Microchip. My
  customers want to know why we cannot just reprogram (I mean everybody
  does it, right?). When I politely try to explain to them that
Microchip
  chose not to go flash when they should have, they tell me : "We don't
  give a damn" This is a valid attitude.
2) All the PICs out there already have ICE capability built-in on the
  silicon. Why not use it? Why make people pay $2490 + probe for an ICE
  when they can get it for $5 ? (Wait - I think I am getting it)
3) After spending a fortune on development tools and learning curves, I
  expect a silicon company to at least stay in the race.
4) If we are understaffed, we hire more people. When Microchip are
  understaffed, they bring out a "roadmap into the future". This is
  nothing other than damage control. Microchip have more vice
presidents
  than the damn UN, but obviously not enough engineers.
5) Many people have mailed me privately because they are, um too careful
  to have unfriendly Mchip attention. The only flames I received came
  publicly (like yours). This is enough reason in itself.

If you want to continue this discussion, go private.

--
Friendly Regards (really)

Tjaart van der Walt
tjaartspamspam_OUTwasp.co.za
_____________________________________________________________
| WASP International http://www.wasp.co.za/~tjaart/index.html |
|       R&D Engineer : GSM peripheral services development    |
|   Vehicle tracking | Telemetry systems | GSM data transfer  |
|    Voice : +27-(0)11-622-8686 | Fax : +27-(0)11-622-8973    |
|              WGS-84 : 26010.52'S 28006.19'E                 |
|_____________________________________________________________|

1997\10\22@011104 by Bob Lunn

flavicon
face
Bob Lunn
10/22/97 03:11 PM


> 1) All the other vendors have already gone flash.
>    Not Microchip.

    But Tjaart, you recommended (in very strong terms)
    a _particular_ vendor.

    This vendor has _not_ 'already gone flash'.  They
    have announced their intention to supply a flash
    based product in the near future.

    In contrast, Microchip have been supplying a flash
    based product for many years!

___Bob

1997\10\22@012358 by tjaart

flavicon
face
Bob Lunn wrote:
>
> Bob Lunn
> 10/22/97 03:11 PM
>
> > 1) All the other vendors have already gone flash.
> >    Not Microchip.
>
>      But Tjaart, you recommended (in very strong terms)
>      a _particular_ vendor.
>
>      This vendor has _not_ 'already gone flash'.  They
>      have announced their intention to supply a flash
>      based product in the near future.
>
>      In contrast, Microchip have been supplying a flash
>      based product for many years!
>
> ___Bob

Privately answered.

--
Friendly Regards

Tjaart van der Walt
@spam@tjaartKILLspamspamwasp.co.za
_____________________________________________________________
| WASP International http://www.wasp.co.za/~tjaart/index.html |
|       R&D Engineer : GSM peripheral services development    |
|   Vehicle tracking | Telemetry systems | GSM data transfer  |
|    Voice : +27-(0)11-622-8686 | Fax : +27-(0)11-622-8973    |
|              WGS-84 : 26010.52'S 28006.19'E                 |
|_____________________________________________________________|

1997\10\22@012548 by Bob Blick

face
flavicon
face
At 01:31 PM 10/21/97 -0400, you wrote:
which is  iffy, to say the least. Hyping unseen products to inexperienced
engineers  isn't going to help Scenix any, and isn't going to impress or
influence the  people at Microchip.

I saw it, it appears to work. I also saw it running(warm to the touch) at
almost 100MIPS. The programming cable works, the software they had running
it was incomplete, but definitely more than vapor.

Let's hope that the bond they have with Parallax is secure, and that
Parallax stays the course as well.

Microchip was interested, but I don't think they fear them. They are doing
quite well, and the market that they lose to Scenix will not be that great.
More likely, they'll take some pointers from them towards improving the PIC
line.

Pretty much looks like a win all around.

Cheerful regards,

Bob

http://www.bobblick.com/

1997\10\22@020528 by William Chops Westfield

face picon face
   1) All the other vendors have already gone flash. Not Microchip. My
      customers want to know why we cannot just reprogram (I mean everybody
      does it, right?). When I politely try to explain to them that Microchip
      chose not to go flash when they should have, they tell me : "We don't
      give a damn" This is a valid attitude.

Huh?  There's a very small subset of microcontrollers available with flash
program memory, and MANY of those carry a hefty price premium.  Looks to me
like Atmel is the only manufacturer throwing flash controllers in the
very-low-end arena, with microchip coming in second by having the 16C/F84.
What other $6 or less flash microcontrollers are YOU talking about?


   2) All the PICs out there already have ICE capability built-in on the
      silicon. Why not use it? Why make people pay $2490 + probe for an ICE
      when they can get it for $5 ? (Wait - I think I am getting it)

I don't want the pins wasted.  I thought (special) bond-out chips were
common practice for microcontroller ICE support.  It'd be cool to have the
"extra" 4 pins on a PLCC-44 be some sort of background debugger interface,
but I don't want my 18 pin controller to be a 24(?) pin controller...

BillW

1997\10\22@021625 by tjaart

flavicon
face
William Chops Westfield wrote:
>
>     1) All the other vendors have already gone flash. Not Microchip. My
>        customers want to know why we cannot just reprogram (I mean everybody
>        does it, right?). When I politely try to explain to them that Microchip
>        chose not to go flash when they should have, they tell me : "We don't
>        give a damn" This is a valid attitude.
>
> Huh?  There's a very small subset of microcontrollers available with flash
> program memory, and MANY of those carry a hefty price premium.  Looks to me
> like Atmel is the only manufacturer throwing flash controllers in the
> very-low-end arena, with microchip coming in second by having the 16C/F84.
> What other $6 or less flash microcontrollers are YOU talking about?
Huh? Did I say $6 or very-low-end? How about mid-range? Have a look at
Motorola.
For my purposes, a 84 is little other than a reprogrammable 555 with
extra pins.
>
>     2) All the PICs out there already have ICE capability built-in on the
>        silicon. Why not use it? Why make people pay $2490 + probe for an ICE
>        when they can get it for $5 ? (Wait - I think I am getting it)
>
> I don't want the pins wasted.  I thought (special) bond-out chips were
> common practice for microcontroller ICE support.  It'd be cool to have the
> "extra" 4 pins on a PLCC-44 be some sort of background debugger interface,
> but I don't want my 18 pin controller to be a 24(?) pin controller...
They don't actually have to be on extra pins. Even if they had to be,
two
pins would be a small price to pay. Scenix use the (existing) osc pins.
I'm
not sure how Motorola do it though.

--
Friendly Regards

Tjaart van der Walt
KILLspamtjaartKILLspamspamwasp.co.za
_____________________________________________________________
| WASP International http://www.wasp.co.za/~tjaart/index.html |
|       R&D Engineer : GSM peripheral services development    |
|   Vehicle tracking | Telemetry systems | GSM data transfer  |
|    Voice : +27-(0)11-622-8686 | Fax : +27-(0)11-622-8973    |
|              WGS-84 : 26010.52'S 28006.19'E                 |
|_____________________________________________________________|

1997\10\22@023313 by Bob Lunn

flavicon
face
Bob Lunn
10/22/97 04:34 PM


> I saw it, it appears to work. I also saw it running
> (warm to the touch) at almost 100MIPS. The programming
> cable works, the software they had running it was
> incomplete, but definitely more than vapor.

    I honestly _don't_ want to be too pedantic
    about this.  But I believe there is a huge
    difference between a company that is shipping
    a working product, and a company that has a
    working product that they intend to ship at
    some point in the future.

    With the information I have to hand about the
    Scenix chip I could _not_ recommend it for a
    new design.

___Bob

1997\10\22@025140 by tjaart

flavicon
face
Bob Lunn wrote:
>
> Bob Lunn
> 10/22/97 04:34 PM
>
> > I saw it, it appears to work. I also saw it running
> > (warm to the touch) at almost 100MIPS. The programming
> > cable works, the software they had running it was
> > incomplete, but definitely more than vapor.
>
>      I honestly _don't_ want to be too pedantic
>      about this.  But I believe there is a huge
>      difference between a company that is shipping
>      a working product, and a company that has a
>      working product that they intend to ship at
>      some point in the future.

This is true. Having said that, there is also a huge
difference between a company that has a 'future road
map' for flash products (to keep investors happy), and
one that's shipping in January 1998.

--
Friendly Regards

Tjaart van der Walt
RemoveMEtjaartTakeThisOuTspamwasp.co.za
_____________________________________________________________
| WASP International http://www.wasp.co.za/~tjaart/index.html |
|       R&D Engineer : GSM peripheral services development    |
|   Vehicle tracking | Telemetry systems | GSM data transfer  |
|    Voice : +27-(0)11-622-8686 | Fax : +27-(0)11-622-8973    |
|              WGS-84 : 26010.52'S 28006.19'E                 |
|_____________________________________________________________|

1997\10\22@030847 by Bob Lunn

flavicon
face
Bob Lunn
10/22/97 05:05 PM


> This is true. Having said that, there is also a huge
> difference between a company that has a 'future road
> map' for flash products (to keep investors happy), and
> one that's shipping in January 1998.

    But now you're comparing pears and coconuts.

    On the one hand: a company with a range of products
    covering a broad span of functionality and performance;
    at highly competitive prices; with a reputation for
    reliable supply; and with a long history of on-going
    innovation and development.

    On the other hand: a company that may ship a chip soon.

    With which am I going to bet my customers business?

___Bob

1997\10\22@030854 by Bob Lunn

flavicon
face
Bob Lunn
10/22/97 05:05 PM


> For my purposes, a 84 is little other than a
> reprogrammable 555 with extra pins.

    So the Scenix chip is little other than a
    (faster) reprogrammable 555 with extra pins?

___Bob

1997\10\22@080213 by Mike Smith

flavicon
face
-----Original Message-----
From: Bob Lunn <spamBeGoneblunnspamBeGonespamKEYCORP.COM.AU>
To: TakeThisOuTPICLISTEraseMEspamspam_OUTMITVMA.MIT.EDU <RemoveMEPICLISTspamTakeThisOuTMITVMA.MIT.EDU>
Date: Wednesday, 22 October 1997 16:39
Subject: Re: PIC Development Tools


{Quote hidden}

Which is probably why Scenix made it a superset of the PIC 5x's.  Smooth
migrations?
Just having a second-source should make you happier.

MikeS
<mikesmith_ozEraseMEspam.....relaymail.net>

1997\10\22@090712 by Tom Rogers

flavicon
face
-----Original Message-----
From: Mike Smith <EraseMEmsmithspamPASTEUR.DIALIX.COM.AU>

>Which is probably why Scenix made it a superset of the PIC 5x's.  Smooth
>migrations?
>Just having a second-source should make you happier.

Yo, guys! This is not a second source, unless the world has gone wacky. A
second source is a drop in replacement in every way, including all the
unanticipated behavior of a system during the entire product life cycle. In
particular you have to include the programmed behavior of the personnel that
are actually making the thing; any change in any part of the procedure makes
this part a suitable substitution, maybe, but not a second source. From what
I can tell, my binaries and programming procedures won't transfer directly;
in fact, it seems that I'll have to have a second round of system qual test
to use the Scenix chip as a substitute, along with the second set of
manufacturing and QA procedures.

I don't even understand what the debate is about. The Scenix chip
announcement is interesting, but it doesn't have much overlap with the
Microchip stuff in application space. I can't recall thinking once that I
could use it in place of an existing PIC chip in an existing application; I
might use the speed of the thing to make a new design task easier (and
therefore faster to complete, smaller and more reliable code, etc.) or to do
something I couldn't do with a slower PIC chip, or to enable improvements in
an existing product undergoing redesign, but these possibilities don't fill
my vision of the future.

I think Micro chip must recognize this, an idea confirmed in part by their
public reaction to the Scenix announcement. This isn't the 70's, where there
are these neat new things we don't have any idea how to really use; I
guarantee you that Scenix doesn't want to wait as long as Intel did to see a
market develop. Given that, I don't feel this stuff warrants the full wowie
treatment. It's really just incremental engineering with a valid recognition
of the underlying (so called) paradigm shift that a really fast, dumb chip
makes possible. Which is, really, marketing stuff, and not that flattering
to those of us that have been using the PIC family for years with exactly
the view that Scenix wants to claim as unique. If anyone thinks bright guys
like the Andys haven't been programming virtual peripherals and reaping the
rewards all these years, well, then, you've got something to learn.

'Nuff said -- Tom Rogers

1997\10\22@095523 by Tom Rogers

flavicon
face
Tjaart said:


<A lot of flames extinguished. Snippety snip. Whew!>
{Quote hidden}

But not a valid statement. All the other vendors? Where's your list? If your
customers want some other chip, why don't you give it to them? Why is this
Microchip's problem?

>2) All the PICs out there already have ICE capability built-in on the
>   silicon. Why not use it? Why make people pay $2490 + probe for an ICE
>   when they can get it for $5 ? (Wait - I think I am getting it)

Yikes! There's so much wrong in this statement I don't know where to start.

>3) After spending a fortune on development tools and learning curves, I
>   expect a silicon company to at least stay in the race.

The race? What race? You're the one dropping the flag; I suspect Microchip
is zooming along at their normal pace, which isn't that different than any
other silicon vendor.

>4) If we are understaffed, we hire more people. When Microchip are
>   understaffed, they bring out a "roadmap into the future". This is
>   nothing other than damage control. Microchip have more vice
>presidents
>   than the damn UN, but obviously not enough engineers.

What are we debating, the merits of various managerial structures? If you
have a specific complaint, take it to Microchip. (Hmm. I've heard that
before..)

>5) Many people have mailed me privately because they are, um too careful
>   to have unfriendly Mchip attention. The only flames I received came
>   publicly (like yours). This is enough reason in itself.

Paranoia? Or the appearance of it for some hidden purpose? Who can tell..
(Its a joke. mate.)

>If you want to continue this discussion, go private.
>
>--
>Friendly Regards (really)
>
>Tjaart van der Walt


Yeah, OK, I'm not disputing the friendly part at all. I have two clearly
defined objectives here.

First, I don't really see the point of your arguments, unless its to badger
Microchip, and this isn't the place for that. You are reaching a large
audience that is in part somewhat impressionable. What I hear in the
Scenix/anti-Microchip thread is not exemplary of prudent engineering
practices. I work for a small company that has had the problems one might
expect with the PIC stuff, and Microchip has been responsive to them in an
appropriate way. I don't mean that I wouldn't wish the world was different,
but they aren't doing anything different than other successful vendors.

If you think Scenix will be different, then you can kiss them goodbye,
'cause they won't get through the next round of capitalization. Financial
guys like to see that startups know the secret handshake, and knowing the
secret handshake leads directly to a company like Microchip and a zillion
others. Right or wrong, its the way its done, and there are patterns of
behavior built in to these companies that satisfy most engineers needs. Why
doesn't it work for you? I don't know, but I don't think teaching budding
engineers how the system doesn't work is really what its all about.

Which gets to my second objective: I got tired of listening to the tilt of
opinion, so I decided to stick my weight on the other end of the see-saw.
Maybe the less experienced list members will see a more balanced outlook,
maybe not. Having the debate in private isn't going to accomplish that, so I
won't bother. It looks more level to me, now, so I'm about to shut up.

--Tom Rogers

1997\10\22@100022 by tjaart

flavicon
face
Tom Rogers wrote:
>
> Tjaart said:
>
> <A lot of flames extinguished. Snippety snip. Whew!>
> >
<Even more flames extinguished.>

Let's take it private.

--
Friendly Regards

Tjaart van der Walt
RemoveMEtjaartEraseMEspamEraseMEwasp.co.za
_____________________________________________________________
| WASP International http://www.wasp.co.za/~tjaart/index.html |
|       R&D Engineer : GSM peripheral services development    |
|   Vehicle tracking | Telemetry systems | GSM data transfer  |
|    Voice : +27-(0)11-622-8686 | Fax : +27-(0)11-622-8973    |
|              WGS-84 : 26010.52'S 28006.19'E                 |
|_____________________________________________________________|

1997\10\22@102412 by Walter Banks

picon face
----------
> From: Mike Smith <RemoveMEmsmithspam_OUTspamKILLspamPASTEUR.DIALIX.COM.AU>
>
> Which is probably why Scenix made it a superset of the PIC 5x's.
> Smooth migrations?


The Scenix SX instruction set is NOT a true superset of the Microchip
5X's. There are enough similarities that some code will run. View it as
the relationship between a 8080 and Z80. Some of the 5X code will
run on the SX  and very little of the SX code will run on the 5X.

I agree with Tom Rogers and others on the list that there is very little
overlap between Scenix and Microchip parts in terms of applications.
My reaction the first time I saw the specifications for the part was
surprise at the simple solution that Scenix had found to two problems
that chip companies in general have had. They have had to support
many different parts to cover a wide range of applications and they
have had to manufacture, characterize  and inventory many different
parts. I had a wow factor over the 50-100MIPS because that opened
new application area's.  Existing designs using Microchip 5X parts
are very unlikely to start using Scenix.

Walter Banks

1997\10\22@131629 by Wayne Foletta

flavicon
face
I know the 555 and others that I helped design at Signetics.
The 84 is no 555! The 84 is a lot of power for less than $4 now and
going down.

-Wayne

{Quote hidden}

1997\10\22@164548 by Andy Kunz

flavicon
face
>1) All the other vendors have already gone flash. Not Microchip. My
>   customers want to know why we cannot just reprogram (I mean everybody
>   does it, right?). When I politely try to explain to them that
>Microchip
>   chose not to go flash when they should have, they tell me : "We don't
>   give a damn" This is a valid attitude.

There is an alternative that I use - I get the program right the first time
(well, _almost_ the first time <G>).  If the idea is to provide one set of
hardware to perform multiple software functions, this can also be handled
as the final step of assembly, where it should be.

>2) All the PICs out there already have ICE capability built-in on the
>   silicon. Why not use it?

Well, for one reason IT TAKES I/O!!!  I _like_ to have 13 useful pins on an
18-pin device, not 13 useful pins on a 28-pin one.

>3) After spending a fortune on development tools and learning curves, I
>   expect a silicon company to at least stay in the race.

How about a 25MHz ICE?  Is that somehow _not_ staying in the race?

>4) If we are understaffed, we hire more people. When Microchip are
>   understaffed, they bring out a "roadmap into the future". This is
>   nothing other than damage control. Microchip have more vice
>presidents
>   than the damn UN, but obviously not enough engineers.

When some people are proven wrong, they write long e-mails...

>If you want to continue this discussion, go private.

But then the newer folks on the list won't benefit from the experience of
engineers who _know_ their stuff.  I suggest it all be public for the
benefit of everyone who reads the thread.

Andy

==================================================================
Andy Kunz - Montana Design - 409 S 6th St - Phillipsburg, NJ 08865
         Hardware & Software for Industry & R/C Hobbies
       "Go fast, turn right, and keep the wet side down!"
==================================================================

1997\10\22@172850 by Andy Kunz

flavicon
face
At 04:01 PM 10/22/97 +0200, you wrote:
>Tom Rogers wrote:
>>
>> Tjaart said:
>>
>> <A lot of flames extinguished. Snippety snip. Whew!>
>> >
><Even more flames extinguished.>
>
>Let's take it private.

Feeling a little warm under the collar, are we????

Tjaart, you know I like you and respect your opinions.  I don't necessarily
agree with them all the time, but the world couldn't handle TWO of me (or
you).

We need to keep this open, because engineers DO and MUST differ.  Even big
guys.  Look, the USSR built its space program on solid-fuel boosters, the
USA did it on liquid fuel.  The Soviets were first to launch a satellite,
and the USA first (only) to land on the moon.  Does either make one right
and the other wrong?

Let's keep it public, so everybody can see the merit in each side's
arguments and make the decision that supports THEIR situation correctly.
After all, some of us can't handle the noise a 50MHz chip is going to blow
around when a 4MHz part will do the job.

Andy

==================================================================
Andy Kunz - Montana Design - 409 S 6th St - Phillipsburg, NJ 08865
         Hardware & Software for Industry & R/C Hobbies
       "Go fast, turn right, and keep the wet side down!"
==================================================================

1997\10\22@180519 by William Chops Westfield

face picon face
I wouldn't mind seeing the following matrix filled out:

                <24pins           28-32pins          40+pins
               ------------       --------------     --------------------

OTP             MChp PIC $3             etc.
               Zilog Z8 $3
               Nat COPS $4
               Mot 6805 ?
               Phillip 80751 ?

UV-erasable

EEPROM or       MChip 16x84 $5      Scenix(?)         Mot 68hc11
FLASH           Atmel x51  $4                         Atmel x51
               Atmel AVR $3                          etc.


For example, will the scenix chip really be the first 28 pin flash
microcontroller?  The Z8 familly doesn't have UV parts, and they're
prohibitively expensive in the COPS line ($30+).  Useful data for
all thos applications that need "some" microcontroller, with speed
and peripherals not that important...

BillW

1997\10\22@201804 by Bob Lunn

flavicon
face
Bob Lunn
10/23/97 10:18 AM


> Let's keep it public, so everybody can see the merit
> in each side's arguments and make the decision that
> supports THEIR situation correctly.

    I'm not going to put up the emails I received
    from Tjaart after our public discussion, but
    I will state publicly the points I made in my
    emails to Tjaart.

    1.   Large volume users will not sacrifice
         price or performance for eerom (they
         don't need it).

    2.   Eerom is useful to low volume users.

    3.   Therefore, Microchip will not commit
         substantial resources to development
         of eerom.

    This led to a discussion on innovation.  My
    points were:

    1.   Each year for most of this decade I
         have been able to deliver more grunt
         at lower cost to my customers by using
         Microchip components.

    2.   Whichever way you slice it, I call this
         innovation, and I like it.

    3.   In the past year alone, Microchip has
         released the 12C5xx, 16C5xx, and 16C7xx
         ranges, and announced the 12C6xx range.

___Bob

1997\10\22@203910 by Steve Baldwin

flavicon
face
> I wouldn't mind seeing the following matrix filled out:
>
>                  <24pins           28-32pins          40+pins
>                 ------------       --------------
--------------------
>
> OTP             MChp PIC $3             etc.

Good idea and excellent web site fodder.
It would be a good idea to state a quantity, say at 100 pieces for OTP, 1's
for EPROM and both for Flash.
If you want 100k, it's a different ball game.

BTW. Moto 68HC705J1A <$2 list (OTP)

Steve.

======================================================
 Very funny Scotty.  Now beam down my clothes.
======================================================
Steve Baldwin                Electronic Product Design
TLA Microsystems Ltd         Microcontroller Specialists
PO Box 15-680                email: RemoveMEstevebKILLspamspamkcbbs.gen.nz
New Lynn, Auckland           ph  +64 9 820-2221
New Zealand                  fax +64 9 820-1929
======================================================

1997\10\22@203915 by William Chops Westfield

face picon face
>     1.   Large volume users will not sacrifice
>          price or performance for eerom (they
>          don't need it).

How valuable is in circuit programming?  My impression is that it is
extremely valuable in arenas where the program changes frequently, but
that manufacturing lines aren't quite set up to handle it yet.  This
also implies that it's more valuable where the code is bigger and the
processor is more expensive, rather unlike the low-end PICs.

I know that loadable microcode has saved our butt countless times in very
large embedded systems, even when that meant changing 13 socketed ROMs.  It
was much more pleasant when that became 1 big EPROM (thanks to auto-loading
microcode RAMs), and even better when you could change things over the
network.  There's a Cirrus Quad UART controller that's now available with
downloadable RAM microcode thanks to us (I think.)


>     3.   In the past year alone, Microchip has
>          released the 12C5xx, 16C5xx, and 16C7xx
>          ranges, and announced the 12C6xx range.

I was extremely pleased with what microchip did to get 8pin micros.  They
could have simply put in a low-end PIC without all the pins connected, but
they went considerably beyond that.  High points!

BillW

1997\10\22@215314 by Bob Lunn

flavicon
face
Bob Lunn
10/23/97 11:54 AM


I said:

> 1.   Large volume users will not sacrifice
>      price or performance for eerom (they
>      don't need it).
And then Bill asked:

> How valuable is in circuit programming?

    Bill, I'm not sure what the link is between
    eerom and in-circuit programming?

    All but the lowest end PIC's (and most of
    those are no longer available) can be pro-
    grammed in-circuit.

    If you're asking how valuable is in-circuit
    RE-programmability then, in my experience,
    for high volume users not much.

    If I shipped a million mix-masters/blow dryers/
    ring tone generators/display multiplexors/keyless
    door locks/dog-collar alarms (etc etc) last year,
    I'm not likely to want to go back this year and
    update all those units in the field.

    The cost of the service call, or of having the
    unit returned to the factory, is probably many
    times the cost of just replacing the unit (or of
    just replacing the controller chip).

    The cost equation may be different if my units
    are already connected to a comms network and can
    be accessed remotely.  But this is still the
    exception, not the rule.

___Bob

1997\10\22@215733 by Bob Lunn

flavicon
face
Bob Lunn
10/23/97 11:57 AM


> Just having a second-source should make you happier.

    Yes, it does.  But I would see Holtek as a
    more significant 'second source' at this
    stage than Scenix (who could easily be a
    one-hit wonder, though I hope not).

___Bob

1997\10\23@005542 by tjaart

flavicon
face
Andy Kunz wrote:

> >If you want to continue this discussion, go private.
>
> But then the newer folks on the list won't benefit from the experience of
> engineers who _know_ their stuff.  I suggest it all be public for the
> benefit of everyone who reads the thread.

This thread has obviously become less than usefull. It seems there are
three distinct views on this :
1) Mchip needs competition to whack their asses into faster R&D.
2) The competition is probably good for all of us. Let's wait and see.
3) I am emotionally attached to Microchip. I love 'em! (Wave a lighter
  and play some anthem type music!)

The aspects to consider are :
1) Part performance (speed, ROM, RAM).
2) Manufacturing (In circuit programming etc).
3) Serviceability in the field (reprogrammable and bond-out).
4) Development tools cost.
5) Development tools support.
6) Development tools reliability.
7) Does the company have a track record for reliability?
8) Does the company have a track record for lead times?
9) How quickly does the company respond to market need changes?
10) How quickly does the company fix bugs?
11) Is there a second source?
12) Do you ever get to speak to a listening engineer?
13) Is there a library of software to choose from?
14) Is there a range of products to choose from?
15) Do you need a range of products, or can you use virtual devices?

It is obvious that not one silicon vendor can fulfill all of these
requirements (yet).

--
Friendly Regards

Tjaart van der Walt
tjaartSTOPspamspamspam_OUTwasp.co.za
_____________________________________________________________
| WASP International http://www.wasp.co.za/~tjaart/index.html |
|       R&D Engineer : GSM peripheral services development    |
|   Vehicle tracking | Telemetry systems | GSM data transfer  |
|    Voice : +27-(0)11-622-8686 | Fax : +27-(0)11-622-8973    |
|              WGS-84 : 26010.52'S 28006.19'E                 |
|_____________________________________________________________|

1997\10\23@012008 by Mike Keitz

picon face
On Wed, 22 Oct 1997 13:12:31 -0400 Wayne Foletta <spamBeGonewayneSTOPspamspamEraseMEELECTROTEK.COM>
writes:
>I know the 555 and others that I helped design at Signetics.
>The 84 is no 555! The 84 is a lot of power for less than $4 now and
>going down.

Interesting, since I just wired up a 555 to generate test pulses for a
pulse amplifer which will eventually be driven by an '84.  The PIC will
be doing much more than just generating pulses though.

I'm using a proto-board to fully exploit the 555's total in-circuit
reprogrammability.  It costs much less than $4, and has a supply voltage
range and output current capability that no microcontroller can touch.
No ICE is available though.

1997\10\23@015157 by James M.

flavicon
face
After all the flames, the list responded with
indignation that someone would want to
withdraw from such a useless discussion.
Kudos to you, Tjaart, for handling a lot of flames
with class.

James

----------
> From: Tjaart van der Walt <KILLspamtjaartspamBeGonespamwasp.co.za>
> To: EraseMEPICLISTspamEraseMEMITVMA.MIT.EDU
> Subject: Re: PIC Development Tools
> Date: Wednesday, October 22, 1997 9:56 PM
>
> Andy Kunz wrote:
>
> > >If you want to continue this discussion, go private.
> >
> > But then the newer folks on the list won't benefit from the experience
of
{Quote hidden}

1997\10\23@015923 by Bob Lunn
flavicon
face
Bob Lunn
10/23/97 04:00 PM


> After all the flames, the list responded
> with indignation that someone would want
> to withdraw from such a useless discussion.

    Gee, if this was a flame war then I
    can chuck that asbestos suit.  A more
    mild mannered exchange of views and
    opinions would be hard to find!

___Bob

1997\10\23@022018 by Mike Keitz

picon face
On Thu, 23 Oct 1997 06:56:11 +0200 Tjaart van der Walt
<spamBeGonetjaartspamKILLspamwasp.co.za> writes (subject to deletion):

>This thread has obviously become less than usefull.

It started when you suggested a beginner forget Microchip entirely and
spend their first (and only) $250 on the non-existant, completely
unproven Parallax-Scenix stuff.

Regardless of any "emotional attachment" to Microchip, I don't think that
was good advice.  If they want to shun Microchip, look to Atmel, Holtek,
Zilog, etc - which have actual chips widely available, some with months
of experience behind them.

The Microchip chips are years to decades old, which I consider a positive
attribute.  They are not perfect, but they are well-known and widely
used.  And generally easy to find and buy.


>The aspects to consider are :
>1) Part performance (speed, ROM, RAM).

Low processor speed can often be compensated for with additional software
development.  This is the predominant method in the low-end market.  They
wouldn't be "low-end" parts otherwise.

I still wonder why no PICs (or AVR's) have more than a few hundred bytes
RAM.  True not many applications use more than a few dozen bytes.  But I
have some in mind that need a couple Kbyte.  Especially with dual serial
ports and decent processing speed, the opportunity is ripe for buffers,
protocol converters, error correctors, etc.

>2) Manufacturing (In circuit programming etc).
>3) Serviceability in the field (reprogrammable and bond-out).

Many, many PIC-containing products will never be repaired or
reprogrammed.  Even if the chip were in-circuit reprogrammable, the cost
to do so would be more than the price of replacing the entire product
with a new or upgraded one.

>14) Is there a range of products to choose from?
>15) Do you need a range of products, or can you use virtual devices?

With any programmable chip, there will almost always be some
functionality which is not needed or used by the program for the task at
hand.  This represents wasted silicon area, pin count, power consumption
- all of which add up to cost.  Therefore, there is a use for a range of
chips that provide reduced functionality, as long as the additional
complications of manufacturing them (instead of just one "super" version)
still allow a lower cost.

>
>It is obvious that not one silicon vendor can fulfill all of these
>requirements (yet).

If they did, we couldn't afford it.

1997\10\23@025511 by tjaart

flavicon
face
Mike Keitz wrote:
>
> On Thu, 23 Oct 1997 06:56:11 +0200 Tjaart van der Walt
> <.....tjaartspam_OUTspamwasp.co.za> writes (subject to deletion):
>
> >This thread has obviously become less than usefull.
>
> It started when you suggested a beginner forget Microchip entirely and
> spend their first (and only) $250 on the non-existant, completely
> unproven Parallax-Scenix stuff.
If I had to start from scratch now, I'd definitely not go Microchip. I'd
stay on the PIClist though... :)

>
> Regardless of any "emotional attachment" to Microchip, I don't think that
> was good advice.  If they want to shun Microchip, look to Atmel, Holtek,
> Zilog, etc - which have actual chips widely available, some with months
> of experience behind them.
Time didn't correct BRGH=1 on the '74. There will always be problems
with
all the micro's. What makes the difference is how they react to them. If
they decide to fix it, the time it takes is important.

I concede that Scenix has no track record to this regard, but this
should
not be held against them. I rather think they have something to prove...


> If they did, we couldn't afford it.
True

--
Friendly Regards

Tjaart van der Walt
TakeThisOuTtjaart.....spamTakeThisOuTwasp.co.za
_____________________________________________________________
| WASP International http://www.wasp.co.za/~tjaart/index.html |
|       R&D Engineer : GSM peripheral services development    |
|   Vehicle tracking | Telemetry systems | GSM data transfer  |
|    Voice : +27-(0)11-622-8686 | Fax : +27-(0)11-622-8973    |
|              WGS-84 : 26010.52'S 28006.19'E                 |
|_____________________________________________________________|

1997\10\23@031713 by William Chops Westfield

face picon face
   > After all the flames, the list responded
   > with indignation that someone would want
   > to withdraw from such a useless discussion.

Well of course.  After all, this is merely a minor variation of the "which
microprocessor manufacturer is the most innovative?", a time-honored
religious issue on which many megabytes have been spewed forth...

:-)
BillW

1997\10\23@035719 by wterreb

flavicon
face
I was following this thread with interested because I've expected
this clash between Microchip fans and anti-Microchip fans for a long
time now.   What I find really strange is that the person/persons who have
complained most about Microchip for more than a year now still keeps
on using PICs and subscribing to the PICLIST regardless.

I have always thought that it is unfair to publicly attack a big
organization like Microchip on a mailinglist like this, especially if
the accusations is of such a non-specific nature.   And it is even
worse to make such public accusations and then want to continue the
conversations in private without letting the other side of the story
also get out in the open.

So, what I really want to say is that it was good to see that common
sense still prevail and people still stand up for someone (or some
company in this case) that is falsely accused.  And it was good that
this was kept in the public so that the other side of the story could
also come into the light.

Even though I've used Microchips products for more than ten years, I
still get excited about new products all the time. It was PICs that
first kindled my interest in microcontrolelrs and set me on my
current career path.  And they have helped me make some good money
too, so I've got a soft spot for this company.    I'm glad to see
that there are many others in the world that feel like me about this.

Friendly Regards (especially to Microchip)
Werner

1997\10\23@040138 by Bob Lunn

flavicon
face
Bob Lunn
10/23/97 06:03 PM


> If I had to start from scratch now, I'd definitely
> not go Microchip.

    Interesting...  I have the impression that
    you regularly use a number of different
    micros, so you're in a position to offer
    an informed opinion.

    Consider this:

    A client comes to you with a product spec.

    He wants prototypes in a month, and volume
    production to start in three months.

    Initial volume is 2500 pcs per year.

    Microprocessor cost should not exceed US$3.50

    If (note _if_) the microprocessor used was
    a pic, then the code would not exceed 2k,
    and ram would not exceed a few dozen bytes.

    The product requires a bidirectional asynch
    serial port; not less than 1200 baud, not more
    than 9600 baud.

    Other I/O is just switch inputs and led outputs.
    Ten pins should be enough, but if more are
    available they can be used to add operator
    selected operational modes.  This is nice, but
    no big deal.

    You have no existing investment in development
    tools, support software, etc.

    Which microprocessor do you choose?

___Bob

1997\10\23@041430 by Bob Lunn

flavicon
face
Bob Lunn
10/23/97 06:16 PM


> Which microprocessor do you choose?

    Oh, and perhaps some discussion about
    your reasons?

    Also, of course, all other contributions
    solicited.  :)

___Bob

1997\10\23@042724 by Bob Lunn

flavicon
face
Bob Lunn
10/23/97 06:27 PM


> Do you need a range of products, or can you use
> virtual devices?

    "Gee, Mr Scenix, that's a lovely shiny new
     box you've got there!  Can I look inside?"

    "Why of course, Mr Engineer."

    "But..  It's empty!"

    "No, no, no.  It's chock full of Virtual
     Devices!"

What do you do when you have absolutely no hardware
peripherals?

I laughed and laughed when I read Scenix's description
of Virtual Peripherals.  I suppose it sounds better
than "bit banging".

___Bob

1997\10\23@043936 by William Chops Westfield

face picon face
   I laughed and laughed when I read Scenix's description
   of Virtual Peripherals.

Heh.  Following in Intel's footsteps, I guess.  I had the same uneasy
reaction about (?) "Native Signal Processing".  Like I want my $600 pentium
chip doing the work of a $100 modem (or was that the $50 sound card)?

In the scenix case, seems by the time you have all your virtual peripherals
implemented, there wouldn't be room for much else.  (OTOH, I bet lots of
PIC peripherals go entirely unused a lot of the time.)

I'm also worried that the Scenix is advertising (more or less) a price for
there chip (in 1K quantities) about the same as the competing PICs in ones.
There's a lot of room to do screwy things with the small quantity pricing if
scenix decides they aren't interested in the 2500 unit/year (200/month)
businesses (not to mention all us amateurs.)

BillW

1997\10\23@050024 by Antti Lukats

flavicon
face
At 06:27 PM 23/10/97 +301000, you wrote:
{Quote hidden}

why, Bob??

The idea of 'Virtual Peripheral' or 'virtual hardware'
isnt new and used in many succesful things - well Win 95
isnt so popular amongst PICLISTers but it sure uses the
same idea ie lotsa things there are 'virtual' ie multiply
tasks 'see' hardware that isnt there or is been used by
some other task at the same time.

What Scenix (or actually Chip Cracey from Parallax)
is marketing is almost the same - small interupt handler
code running at blazing speed emulating the lacking
hardware functions. Due to the ultimate high speed of SX
the list of 'virtual functions' is really impressive.

It defenetly is possible and makes sense to use this
technolgy on a small range microcontrollers - well we
are using the same approuch with AT90S1200 that only
has 512 words of code memory and 3 level stack.
A Virtual UART takes < 60 words of code, and is pretty
much a TRUE full duplex UART for the programmer side:
write to RAM location and Poll Status bit - same functions
you would do with real hardware UART, except the UART
functionality is simulated.

PIC chips are just 'a little bit' to slow to take real
advantage from the 'virtual hardware' approuch.
AVR' micros and SCENIX of course are much more suitable.

antti



http://avrbasic.com         -- AVR Basic Compiler
http://sistudio.com/bswfe   -- Basic Stamp Windows Front End

1997\10\23@063337 by Steve Baldwin

flavicon
face
>      Which microprocessor do you choose?

Assuming this is a snap quiz, Atmel 2051 is the first thing that pops into
my mind.
Simple, no frills UART. Right size, ROM, RAM, etc. Price OK.
Stable, free assembler on net.
Parallel port programmer schematics & s/w on web site. (Get the PCB made at
the same time as clients proto so they pay for it).
Local supplier on the ball.
And if they are paying for a month to do that, I'll serve it on toast. :-)

Probably the wrong answer here in PIC Temple.
Note: This was the first contender that popped into my head. I'd give any
real client a bit more effort than that.

Steve.

======================================================
 Very funny Scotty.  Now beam down my clothes.
======================================================
Steve Baldwin                Electronic Product Design
TLA Microsystems Ltd         Microcontroller Specialists
PO Box 15-680                email: TakeThisOuTstevebKILLspamspamspamkcbbs.gen.nz
New Lynn, Auckland           ph  +64 9 820-2221
New Zealand                  fax +64 9 820-1929
======================================================

1997\10\23@122340 by John Payson

picon face
> The idea of 'Virtual Peripheral' or 'virtual hardware'
> isnt new and used in many succesful things - well Win 95
> isnt so popular amongst PICLISTers but it sure uses the
> same idea ie lotsa things there are 'virtual' ie multiply
> tasks 'see' hardware that isnt there or is been used by
> some other task at the same time.

Actually, the Atari 2600 video computer system (came out in '77) tended to
use a "virtual display system"; the display hardware on that thing is dirt
simple, but with proper software it can do some amazing things (Solaris, for
example, is incredible).  Interestingly, until Activision came on the scene,
the "virtual display" was chunky and pretty feeble-looking; Activision used
some cool hacks to double the display resolution and most programmers since
have followed their lead.  As a result, while the early Atari graphics weren't
as good as, e.g., the Magnavox Odyssey2, changes in the "virtual platform"
were able to improve the Atari's graphics while no such improvement could be
made to those of the Odyssey2.

1997\10\23@123420 by Mike Keitz

picon face
On Wed, 22 Oct 1997 18:52:40 -0300 Antti Lukats <.....anttispamRemoveMESISTUDIO.COM>
writes:

>The idea of 'Virtual Peripheral' or 'virtual hardware'
>isnt new and used in many succesful things -

Exactly.  Take an old idea, give it a new name, try and promote it as
something revolutionary.  "Virtual Peripherals" have been implemented on
processors much less powerful than PIC, as well as much more.  Other than
a faster chip and a ton of marketing hype, there is nothing new under the
sun.

1997\10\23@130813 by Engineering Department

flavicon
face
< Tjaart van der Walt writes in part>
> > If they want to shun Microchip, look to Atmel, Holtek,
> > Zilog, etc - which have actual chips widely available, some with months
> > of experience behind them.

Umm.  We've been going for over six months
to verify some specifications on a Zilog
Z86129.  Zilog claimed a feature when
we specified the part, but now they can't
find the person who says he exercised
the feature.

Granted this is a specialty chip, so it makes
sense that only a few folks at Zilog would
know much about it.  But it's been a long
time and we're holding production as a
result.

May end up having to use a PIC to fill
in the missing feature <G>.

Cheers,

Win Wiencke
Image Logic Corporation
RemoveMEImageLogicspamspamBeGoneibm.net

1997\10\23@142021 by Wayne Foletta

flavicon
face
Sorry - maybe I missed the orginal post. Thought 555 referred to
Signetics' NE555 - a linear circuit, a timer only. When I left there in
the early 80's my designs only used OT programming (Zener zapping) at
the wafer level. Have they changed that to eeprom bits for in-circuit
trim or function changes?
-Wayne

{Quote hidden}

1997\10\23@174345 by Mike Keitz

picon face
On Thu, 23 Oct 1997 11:10:29 -0500 John Payson <RemoveMEsupercatEraseMEspamspam_OUTMCS.NET> writes:
>> The idea of 'Virtual Peripheral' or 'virtual hardware'
>> isnt new and used in many succesful things - well Win 95
>> isnt so popular amongst PICLISTers but it sure uses the
>> same idea ie lotsa things there are 'virtual' ie multiply
>> tasks 'see' hardware that isnt there or is been used by
>> some other task at the same time.
>
>Actually, the Atari 2600 video computer system (came out in '77)
>tended to
>use a "virtual display system"; the display hardware on that thing is
>dirt
>simple,

I think it was just a couple of clock generators and a shift register.
Did it have any DMA logic or did the 6502 have to stoke it constantly
during the visible part of the scan?

The really interesting thing is that there was nowhere near enough RAM in
the box to store a whole picture in dot-matrix form at once (128 bytes?).
So the software had to generate each line of video right before it was
displayed.  All that was stored in the RAM was the line being displayed,
the one being generated, and game variables like the position of each
object on screen.  During the vertical blanking interval, there was time
to make high-level analysis of who is worthy of redisplay in the next
field.

This combination of big ROM, small RAM, and fast CPU sounds a lot like a
PIC chip.  It should be possible to clone many of the 2600 games
(especially simple ones like Pong, Space Invaders, maybe even Pac-Man)
into a PIC, using the SSP to shift video out, making a single-chip game
(not that GI didn't already have dedicated single-chip games).

In color?  If the PIC will go 57.28 MHz, this allows a dot clock of
14.7456 MHz, allowing several awful shades of color (Why "Cyan" and
"Magenta" rather than nice pure red and blue?  Because the phase is
even).  A persistent rumor claims the 16C5x parts will wail away at 50
MHz with external clocking.  Otherwise some external color logic may be
needed.  Maybe using the USART and the SSP at the same time could
generate 2-bit pixels for the color matirx.

1997\10\24@045618 by Bob Lunn

flavicon
face
Bob Lunn
10/24/97 06:56 PM


>> The idea of 'Virtual Peripheral' or 'virtual hardware'
>> isnt new and used in many succesful things -
>
> Exactly.  Take an old idea, give it a new name, try and
> promote it as something revolutionary.

    Yeah, but not quite the cause of my mirth.

    Scenix may flog multiple execution units as being
    novel when they aren't.  But at least the Scenix
    chip _has_ multiple execution units.

    A "Virtual Peripheral (tm)" isn't anything.  The
    Scenix chip doesn't 'have' Virtual Peripherals (tm).

    Or, it doesn't 'have' Virtual Peripherals (tm) to
    any greater or lesser degree than any other Turing
    Machine.

___Bob

Oh, the (tm) is serious!

1997\10\24@050032 by Bob Lunn

flavicon
face
Bob Lunn
10/24/97 07:00 PM


> Atmel 2051 is the first thing that pops into my mind.
> snip...
> Probably the wrong answer here in PIC Temple.

    No, the sort of answer I was looking for.  If this
    thread has any worth, it would be to challenge our
    predisposition/inertia to PIC's.

___Bob

PS:  Tjaart, still interested in your response (really).

1997\10\24@051635 by William Chops Westfield

face picon face
    Or, it doesn't 'have' Virtual Peripherals (tm) to any
    greater or lesser degree than any other Turing Machine.

The Xerox Alto (grand-pappy of all window systems) was said to have
multi-processing capability at the microcode level, which always sounded
pretty cool to me (and would get you real close to true "virtual
peripherals".)  I was never well enough acquainted with its architecture to
tell whether this was a good idea, whether it has ever been implemented in
any microprocessors, or even whether it is legitimately obsoleted by other
features, but it still sounds cool...

BillW

1997\10\24@090935 by Mike Smith

flavicon
face
-----Original Message-----
From: Bob Lunn <@spam@blunnRemoveMEspamEraseMEKEYCORP.COM.AU>
To: EraseMEPICLISTspam@spam@MITVMA.MIT.EDU <@spam@PICLISTspam_OUTspam.....MITVMA.MIT.EDU>
Date: Thursday, 23 October 1997 9:49
Subject: Re: PIC Development Tools


{Quote hidden}

No?  What about products that utilise EE (program and data space) to change
their product in the field?   This is a huge market.  Modems all (or nearly
so) do it - smartcard apps to some extent... Those are two I came up with
without thinking hard about the subject.

>
>     2.   Eerom is useful to low volume users.

See above re market.

>
>     3.   Therefore, Microchip will not commit
>          substantial resources to development
>          of eerom.

Silicon companies go thru phases.  Immature.  Flexible and vigorous.
Inflexible and slow.  Calcified and dead.
At the moment I'd rate Scenix in category 1, Atmel in category 2, MicroChip
in category 3(.8)

Where do you want to go today?  Probably Atmel.

>
>     This led to a discussion on innovation.  My
>     points were:
>
>     1.   Each year for most of this decade I
>          have been able to deliver more grunt
>          at lower cost to my customers by using
>          Microchip components.

Ask yourself if the 'most of this decade' was in the former or latter years
of it.

>
>     2.   Whichever way you slice it, I call this
>          innovation, and I like it.
>
>     3.   In the past year alone, Microchip has
>          released the 12C5xx, 16C5xx, and 16C7xx
>          ranges, and announced the 12C6xx range.

Derivative stuff, NOT innovative.  The 'compiler friendly' products in their
future directions catalog remain vapourware.  One page wonders.  Not even a
list of instructions or architecture drawing.

MikeS
<spamBeGonemikesmith_ozEraseMEspamrelaymail.net>

1997\10\24@091018 by Mike Smith

flavicon
face
>>3) After spending a fortune on development tools and learning curves, I
>>   expect a silicon company to at least stay in the race.
>
>How about a 25MHz ICE?  Is that somehow _not_ staying in the race?


Are we talking PICS here?  The fastest ICE (16c7x) I can get is 10MHz.  So
far as I know, this is a boondout chip limitation.

MikeS
<mikesmith_ozspamBeGonespamrelaymail.net>

1997\10\24@091056 by Mike Smith

flavicon
face
-----Original Message-----
From: Walter Banks <RemoveMEwalter@spam@spamspamBeGonebytecraft.com>
To: Mike Smith <.....mikesmith_oz@spam@spamEraseMErelaymail.net>; .....PICLISTRemoveMEspamMITVMA.MIT.EDU
<.....PICLISTSTOPspamspam@spam@MITVMA.MIT.EDU>
Date: Wednesday, 22 October 1997 23:52
Subject: Re: PIC Development Tools


{Quote hidden}

If I use the z80 - 8080 analogy, then ALL the 5x will run on the SX, but a
lot faster and most of the SX will run on the 5x, but slower.  (the z80
topped out at 8MHz+ the 8080 was, um, 1MHz?)   This probably isn't true for
the SX - 5x scenario.  As they say, YMMV <g>  I'll take your statement as
true ahead of the z80 analogy, cos I'm sure you've got silicon and very
detailed information, that we lack.  (Also a NDA :(   )

{Quote hidden}

A 5x 'equivalent' that outperforms the only EE chip that MicroChip produce
is going to be a handy prototyping tool at any speed.  Lots of ppl use the
84 for the ease of reprogram + the low cost. (comparing with jw's)  Wouldn't
you see the 84 market being savaged?  Doesn't it also make higher level
languages (c, forth, basic) more attractive to use compared with assembly?
(speed factor)

MikeS
<RemoveMEmikesmith_ozspamspamBeGonerelaymail.net>

PS Can you reply to piclist only? I got a dupe of this <g>

1997\10\24@092409 by Mike Smith

flavicon
face
<snipt>

>I still wonder why no PICs (or AVR's) have more than a few hundred bytes
>RAM.  True not many applications use more than a few dozen bytes.  But I
>have some in mind that need a couple Kbyte.  Especially with dual serial
>ports and decent processing speed, the opportunity is ripe for buffers,
>protocol converters, error correctors, etc.

Agreed.  Suspect that its cost / die space required.  Someone said the 17xx
external rams needed to be very fast.  This is expensive, in SRAM.  SRAM
also is somewhat expensive of die real estate.

MikeS
<spamBeGonemikesmith_ozKILLspamspam@spam@relaymail.net>

1997\10\24@093414 by Mike Smith

flavicon
face
-----Original Message-----
From: Bob Lunn <blunnspam_OUTspam@spam@KEYCORP.COM.AU>
To: spamBeGonePICLIST@spam@spamMITVMA.MIT.EDU <RemoveMEPICLISTEraseMEspamKILLspamMITVMA.MIT.EDU>
Date: Thursday, 23 October 1997 15:31
Subject: Re: PIC Development Tools


{Quote hidden}

<mandatory asbestos suit statement follows>

Windows 95 is a perfect operating system.  It runs on a 386 with 4M of ram
quite adequately.  I know this is so because Bill Gates says so.

<g>

MikeS
<spamBeGonemikesmith_ozspam_OUTspamRemoveMErelaymail.net>

Medical authorities warn that the wearing of asbestos suits is a health
hazard.

1997\10\24@095325 by tjaart

flavicon
face
Mike Smith wrote:
>
> <snipt>
>
> >I still wonder why no PICs (or AVR's) have more than a few hundred bytes
> >RAM.  True not many applications use more than a few dozen bytes.  But I
> >have some in mind that need a couple Kbyte.  Especially with dual serial
> >ports and decent processing speed, the opportunity is ripe for buffers,
> >protocol converters, error correctors, etc.
>
> Agreed.  Suspect that its cost / die space required.  Someone said the 17xx
> external rams needed to be very fast.  This is expensive, in SRAM.  SRAM
> also is somewhat expensive of die real estate.
>


Speaking of die real estate. I've compared the die sizes of the '74 and
'77
JW parts. There is a huge difference in die size, but not such a big
difference in cost (about a buck). Twice the RAM = $1 = worth it.

--
Friendly Regards

Tjaart van der Walt
.....tjaartspamRemoveMEwasp.co.za
_____________________________________________________________
| WASP International http://www.wasp.co.za/~tjaart/index.html |
|       R&D Engineer : GSM peripheral services development    |
|   Vehicle tracking | Telemetry systems | GSM data transfer  |
|    Voice : +27-(0)11-622-8686 | Fax : +27-(0)11-622-8973    |
|              WGS-84 : 26010.52'S 28006.19'E                 |
|_____________________________________________________________|

1997\10\24@113630 by Walter Banks

picon face
>----------
> From: Mike Smith <msmithspam@spam@PASTEUR.DIALIX.COM.AU>
>
> A 5x 'equivalent' that outperforms the only EE chip that MicroChip
produce
> is going to be a handy prototyping tool at any speed.  Lots of ppl use
the
> 84 for the ease of reprogram + the low cost. (comparing with jw's)
Wouldn't
> you see the 84 market being savaged?

The 84 market is strong especially in education where small self contained
applications are developed. Companies like Sirius
http://www.siriusmicro.com
have produced complete 84 development environments aimed at entry level
programmers. (high school students)

The niche the SX fits into is one of much higher execution speed, novel or
complex  I/O devices. In private email there is starting to be quite a bit
of
specualtion on how the SX might be used as logic replacement in some
applications. I am surprised at how little mail or comment the prototyping
aspect of the SX has generated.

> Doesn't it also make higher level languages (c, forth, basic) more
attractive
> to use compared with assembly? (speed factor)

Speed is not much of a factor in high level language tools anymore. Most
of the serious comercial tools are paying a small price in execution time.
(typically a few percent. )

In circuit programing (re-programming) has some interesting uses. In
production line testing the application board can be programed to aquire
calibration information which can be made a part of the the actual
application
code when it is programmed into the part as the last step of manufacturing.


Service diagnostic testing can also be done by re-programming the part.
Each of these reduces the application ROM memory requirements.


Walter Banks

1997\10\24@171030 by Steve Baldwin

flavicon
face
> Speaking of die real estate. I've compared the die sizes of the '74 and
> '77
> JW parts. There is a huge difference in die size, but not such a big
> difference in cost (about a buck). Twice the RAM = $1 = worth it.

It's not quite as simple as that in the semiconductor industry. Nothing is
ever done on a "cost plus" basis. Some companies price high at the start to
recoup development costs, while others price low to gain market share. Some
companies seem to go through a die shrink with every batch, while others
set up for one fab line and leave it alone.

Also, the windowed parts probably sit in stock for a long time, while the
production part goes through die shrinks. What you see, may not be what you
get.

Steve.

======================================================
 Very funny Scotty.  Now beam down my clothes.
======================================================
Steve Baldwin                Electronic Product Design
TLA Microsystems Ltd         Microcontroller Specialists
PO Box 15-680                email: EraseMEstevebRemoveMEspamSTOPspamkcbbs.gen.nz
New Lynn, Auckland           ph  +64 9 820-2221
New Zealand                  fax +64 9 820-1929
======================================================

1997\10\27@194329 by myke predko

flavicon
face
Hey Walt,

I've finally gotten through all these notes and wondering if anybody would
comment on:

>The niche the SX fits into is one of much higher execution speed, novel or
>complex  I/O devices. In private email there is starting to be quite a bit
>of
>specualtion on how the SX might be used as logic replacement in some
>applications. I am surprised at how little mail or comment the prototyping
>aspect of the SX has generated.

I am surprised at this as well; I wish this had been brought up before
because this is the basic (and probably only) reason for choosing the SX
over the PIC is the "Virtual Devices".

When I first saw the SX, my first thought that the Virtual Devices would
take up a significant amount of bandwidth compared to what a hardwired
device could do.  My first thought was that even though the SX runs at about
ten times faster than the PIC, the overhead of the virtual devices would
slow down the application unreasonably.

Now, when I looked at my programmer design (which uses a "virtual" serial
port), I wanted to look at the overhead.  The PIC is interrupted at 3x the
data rate (which was 1200 bps, meaning that the interrupt rate is 3600x per
second).  In the interrupt handler, about 160 cycles are executed.  This
means that about 4,800 cycles are required to send/receive a serial byte
(which is ten bits) in the "virtual" serial port.

To send/receive a byte, in the SX running at 50 MIPs, 52,050 cycles are
available.  This means that there is about a 1% overhead to run the
"virtual" serial port at 1200 bps (and this increases to 9% for 9600 bps,
and 115,200 bps cannot be implemented).

Now, for an I2C multi-mastering application, I would use an interrupt on bit
change to implement both the clock sourcing as well as clock synching.  To
carry out this function (at 400K bps), this means that about 125 cycles are
needed for each bit.  Even with half of this required for each bit, I don't
see a lot of problems implementing this in a system.

So, from this analysis, "reasonable" peripherals can be implemented (I would
be hestitant to say that 115,200 bps is "reasonable" for a microcontroller -
although it would be nice to be able to implement) without a significant hit
to the SX's mainline program execution (although it would be on the order of
a 10 MHz PIC, at best 2x or 3x better).  As well, multiple "reasonable"
peripherals could be implemented but I have concerns (see below) - which is
what I would really want in my application.

While I know that Bytecraft is busy at work creating "virtual peripherals"
for the SX, what is the skill level required for somebody off the street to
create their own peripherals?  For the Serial Interface used in my
programmer, this was not a trivial exercise.

There are three other issues that have to be considered for the virtual
peripherals:

1.  Code space used by them.  Going back to my Serial Interface, it actually
takes up about 225 instructions - this is a much more significant fraction
of the memory resources than bandwidth.

2.  Available Timers.  For most peripheral applications, I can see precise
timing will be required to properly implement them.  As well, what happens
if you have multiple peripherals which require clocks running at different
frequencies (and are at different multiples of each other)?

Another issue with timers is, if you have an effective 16 bit timer (ie an 8
bit timer with an 8 bit prescaler), the largest timing granularity you can
get is:
65,536/50,000,000 Hz which is 1.3 msec, which can be very limiting or result
in a significant bandwidth hit.

3.  Concurrent Interrupts.  This is something that the PIC architecture does
really poorly.  This will be a real hit on multiple peripherals.

Now, there may be features to the SX design or the software development
systems being created that makes these non-issues.  If there are, I'd be
interested in hearing about them.

With all this in mind, the question is, is the SX worth it?  As was pointed
out, the SX will have much higher current/power requirements than an
equivalent PIC as well as much higher emmisions.  Where the SX will be most
useful will be in applications where custom peripherals are required and the
designer doesn't want to pay the NRE for somebody to design the periphrals
into one of their chips - or using the SX to prototype a system before
dropping the NRE on the hardware in another device (which is what I think
you were originally suggesting).  It would also be excellent for something
like a new BASIC Stamp.

But, in general use will it take over the market?  Personally, I doubt it
just from the perspective of the software issues and the hardware issues of
putting in the circuitry for a part running at 50 MHz where a device with
standard interfaces can run at 10 MHz or less.


Sorry for the long missive - I do think the SX is an interesting part and
something worthy of discussion.

myke

Check out "Programming and Customizing the PIC Microcontroller" at:

http://www.myke.com

1997\10\28@002239 by tjaart

flavicon
face
myke predko wrote:
>
> Hey Walt,
>
> I've finally gotten through all these notes and wondering if anybody would
> comment on:
>
> >The niche the SX fits into is one of much higher execution speed, novel or
> >complex  I/O devices. In private email there is starting to be quite a bit
> >of
> >specualtion on how the SX might be used as logic replacement in some
> >applications. I am surprised at how little mail or comment the prototyping
> >aspect of the SX has generated.
>
> I am surprised at this as well; I wish this had been brought up before
> because this is the basic (and probably only) reason for choosing the SX
> over the PIC is the "Virtual Devices".

If scenix can get someone like Walter Banks (Hi Walter!) to write a VHDL
compiler for the Scenix, this can become a really attractive alternative
to
GALs. The only restriction would be pins, but I'm sure there will be
bigger
devices out some time. Logic array's, state machines, FIFO's, clocks,
timers
(smallish) integrate-and-dump's could be real easy, fast, and cheap to
develop.

The RAM is a bit of a restriction that could keep it out of DSP
applications
for now.

>
> When I first saw the SX, my first thought that the Virtual Devices would
> take up a significant amount of bandwidth compared to what a hardwired
> device could do.  My first thought was that even though the SX runs at about
> ten times faster than the PIC, the overhead of the virtual devices would
> slow down the application unreasonably.
I gave some thought to the time taken to get hardware (like I2C) going
on a
chip vs. the time taken to write it in software in a way that makes
sense to
your program style. I wrote a few I2C routines two years ago that I am
still
using without change. I've tried to use the hardware, but have always
come
back to my own stuff.

> Now, when I looked at my programmer design (which uses a "virtual" serial
> port), I wanted to look at the overhead.  The PIC is interrupted at 3x the
> data rate (which was 1200 bps, meaning that the interrupt rate is 3600x per
> second).  In the interrupt handler, about 160 cycles are executed.  This
> means that about 4,800 cycles are required to send/receive a serial byte
> (which is ten bits) in the "virtual" serial port.
Something else - when you lay out you PCB, you can route the lines
directly
to the nearest pin without wondering how you are going away on a single
sided
PCB.

> While I know that Bytecraft is busy at work creating "virtual peripherals"
> for the SX, what is the skill level required for somebody off the street to
> create their own peripherals?  For the Serial Interface used in my
> programmer, this was not a trivial exercise.
This is true, but consider the time spent on 'does this bit clear that
register?' for newcomers. If Walter did his thing OK, a simple C command
should simplify this.

> There are three other issues that have to be considered for the virtual
> peripherals:
>
> 1.  Code space used by them.  Going back to my Serial Interface, it actually
> takes up about 225 instructions - this is a much more significant fraction
> of the memory resources than bandwidth.
Yes. Sadly they haven't increased the code space to make up for this.

> 2.  Available Timers.  For most peripheral applications, I can see precise
> timing will be required to properly implement them.  As well, what happens
> if you have multiple peripherals which require clocks running at different
> frequencies (and are at different multiples of each other)?
Or interrupt vectors for the different timers...

> With all this in mind, the question is, is the SX worth it?  As was pointed
> out, the SX will have much higher current/power requirements than an
> equivalent PIC as well as much higher emmisions.
I wouldn't say that. Running off the internal 4MHz clock, it would
perform the
same as a 16MHz 16F84 (If there was such a PIC). Emissions would surely
be
lower... It uses 1.5mA at 4Mhz, while the 16F84 uses more than that at
10MHz.

>  Where the SX will be most
> useful will be in applications where custom peripherals are required and the
> designer doesn't want to pay the NRE for somebody to design the periphrals
> into one of their chips - or using the SX to prototype a system before
> dropping the NRE on the hardware in another device (which is what I think
> you were originally suggesting).  It would also be excellent for something
> like a new BASIC Stamp.
This raises another issue. It seems to take a few tries before dedicated
hardware peripherals run smoothly. An example would be the BRGH=1 issue
on
the 16C74's (Mchip is not alone here). Silicon fixes require more time
than a
software fix. Once you have your library going, you can use
tried&trusted
code on every new project.

> But, in general use will it take over the market?  Personally, I doubt it
> just from the perspective of the software issues and the hardware issues of
> putting in the circuitry for a part running at 50 MHz where a device with
> standard interfaces can run at 10 MHz or less.
There is a strong emotional following of Microchip (as all other
manufacturers).
It will take some time to change people's perspectives. It will also
take time
to convince developers who have already spent big bucks on development
systems
to even look at anything else. Luckily a complete development suite for
the
Scenix is about $250 for the programmer and ICE, and about a grand for
the
compiler, which makes the ouch not too big. I think this will make a
difference.

One point I've been pondering over - the crystals will be more expensive
than
the dirt-cheap 10Mhz crystals and resonators.

> Sorry for the long missive - I do think the SX is an interesting part and
> something worthy of discussion.
Me too. I hope the nasty turn the previous thread on the Scenix took
won't
be repeated. Now let's see the faces turn red again... :)

--
Friendly Regards

Tjaart van der Walt
RemoveMEtjaartKILLspamspamTakeThisOuTwasp.co.za
_____________________________________________________________
| WASP International http://www.wasp.co.za/~tjaart/index.html |
|       R&D Engineer : GSM peripheral services development    |
|   Vehicle tracking | Telemetry systems | GSM data transfer  |
|    Voice : +27-(0)11-622-8686 | Fax : +27-(0)11-622-8973    |
|              WGS-84 : 26010.52'S 28006.19'E                 |
|_____________________________________________________________|

1997\10\28@020745 by Clyde Smith-Stubbs

flavicon
face
On Mon, Oct 27, 1997 at 07:37:14PM -0500, myke predko wrote:

> port), I wanted to look at the overhead.  The PIC is interrupted at 3x the
> data rate (which was 1200 bps, meaning that the interrupt rate is 3600x per

I'm impressed you can get away with 3x - I found 8x to be required to
maintain reliability.

> second).  In the interrupt handler, about 160 cycles are executed.  This

Is this clock cycles or instruction cycles? My code needs only 30 instruction
cycles per interrupt.

> To send/receive a byte, in the SX running at 50 MIPs, 52,050 cycles are
> available.  This means that there is about a 1% overhead to run the

There's an order of magnitude error here. At 50MHz, 10 bits at 1200bps
is about 8 ms, i.e. 50,000 cycles/ms times 8 is about 400,000 cycles per
byte! So 1200bps uses way less than 1% of the CPU.

Using my code, with 8 interrupts per bit, 10 bits per byte,
we get 2400 cycles/byte, and at 115,200 bps at 50MHz on the SX there
are about 4340 cycles/byte available. So 115,200 is doable with about
60% CPU usage. If the sampling rate (interrupts per bit) can be
reduced, it's even better.

> 1.  Code space used by them.  Going back to my Serial Interface, it actually
> takes up about 225 instructions - this is a much more significant fraction

Seems a lot; my C code uses only 100 words for full-duplex serial - see
the code at http://www.htsoft.com/files/samples/pic/iserial.c (100 words
on a 16C84 - the SX would be a tad less, I think).

> But, in general use will it take over the market?  Personally, I doubt it

Most unlikely. I don't actually see it competing with Microchip directly -
Microchip just don't have anything that does the same job, nor would
the SX be suitable for many things done with PICs right now. It's more
complementary than competitive.

Actually, it would make a lot of sense for Microchip to simply buy Scenix!

Cheers, Clyde

--
Clyde Smith-Stubbs               |            HI-TECH Software
Email: spamBeGoneclydespam@spam@htsoft.com          |          Phone            Fax
WWW:   http://www.htsoft.com/    | USA: (408) 490 2885  (408) 490 2885
PGP:   finger RemoveMEclydespam_OUTspamhtsoft.com   | AUS: +61 7 3354 2411 +61 7 3354 2422
---------------------------------------------------------------------------
ANSI C for the PIC! Now shipping! See http://www.htsoft.com for more info.

1997\10\28@031838 by Walter Banks

picon face
myke predko wrote:
>
> Hey Walt,
>
> I've finally gotten through all these notes and wondering
> if anybody would comment on:
>
> > The niche the SX fits into is one of much higher execution
> > speed, novel or complex  I/O devices. In private email
> > there is starting to be quite a bit of speculation on
> > how the SX might be used as logic replacement in some
> > applications. I am surprised at how little mail or
> > comment the prototyping
> > aspect of the SX has generated.
>
> I am surprised at this as well; I wish this had been brought
> up before because this is the basic (and probably only)
> reason for choosing the SX
> over the PIC is the "Virtual Devices".

Another way of stating this the Microchip PIC should be
chosen when itâs mix of peripherals fits the problem at
hand.  The issue is to match the technology to the problem
and not try to bend the problem to fit a specific
technical solution.  Our job as a software tool company
is to make the underlying hardware work as effectively
as possible.  

> When I first saw the SX, my first thought that the
> Virtual Devices would take up a significant amount
> of bandwidth compared to what a hardwired
> device could do.

It is a trade-off between application code and I/O. On
one hand the I/O can be crafted specifically for the
application reducing available bandwidth but making
the application code less complex. Very little has
been written or seriously studied
about virtual peripheral algothrims.

> While I know that Bytecraft is busy at work creating
> "virtual peripherals" for the SX, what is the skill
> level required for somebody off the street to
> create their own peripherals?  For the Serial
> Interface used in my programmer, this was not a
> trivial exercise.

Somewhere between easy and difficult, it is not trivial.
We have some tools in the SXC compiler that help
application developers create their own virtual
peripherals.

Without specialized development tools the problem
is similar to software UARTs and other bit serial
devices.  The problem is basically one of code
timing and stimulus response time.  Most of the
virtual devices that we seen so far are software
simulations of the hardware. Pure hardware I/O
devices are in general fairly simple devices.
Virtual I/O devices can be a lot more complex.  1

Good software algothrims used in virtual peripherals
can change the way we implement applications. For
example, the resistor tester algothrim I posted
on this list a couple weeks ago is one of a class
of algothrims that is designed specifically to
control error.  The application developer can
control both the measurement range and the
degree of accuracy and can trade predictable
accuracy for execution time.

>
> There are three other issues that have to be
> considered for the virtual peripherals:
> 1.  Code space used by them.
> 2.  Available Timers and resolution.
> 3.  Concurrent Interrupt supports.
>
All of these are real issues in designing systems
using virtual peripherals.

> Now, there may be features to the SX design
> or the software development systems being
> created that makes these non-issues.  If there
> are, I'd be interested in hearing about them.

A lot of what we have been doing is working with
SX developers to create standards for implementing
virtual peripherals so that they can be built
into standardized libraries.

> With all this in mind, the question is, is the SX worth it?
> Where the SX will be most useful will be in applications where
> custom peripherals are required and the designer doesn't want
> to pay the NRE for somebody to design the peripherals
> into one of their chips - or using the SX to prototype a
> system before dropping the NRE on the hardware in another
> device (which is what I think you were originally suggesting).  

Not quite in those terms at least we havenât thought
it through to that point. Most of our focus has been
looking at unique development tools issues for the
SX applications.  The major issue is processor bandwidth
tradeoffs as part of the optimization considerations.


> It would also be excellent for something like a new BASIC Stamp.

This would be a very flexible low volume application platform with
fairly good performance.  The Microchip PIC based BASIC stamp
and Stamp2 solved a lot of the timing problems associated with the
virtual peripherals they implemented. ãIt is a shame that so many
companies have chosen sell reverse engineered derivatives of those
products and discourage many creative developers from promoting
their ideas in hardware and softwareä.(end of soapbox)

>
> But, in general use will it take over the market?  

No, for several reasons. The market is far too diverse
with many current applications very well suited to
existing embedded micros. I have said several times
here that current designs using current technology
are just as valid now as they were before the SX was
announced.  By the same token except for trade show
demonstrations I have not seen any code that was
designed to run on the SX that was easily ported
to run on other processors. I think the SX has an
interesting niche, small wordsize raw computing power
and a software dominated application solution.



Walter Banks


(1)  Complex separate programmable I/O devices have
      been common in computers for many years from
      channel controllers in main frames to programmable
      timers in automotive processors. The SX in many
      ways just combines both processor and I/O device.

1997\10\28@104205 by myke predko

flavicon
face
I'm going to cut and paste a few comments from Clyde's, Tjaart's and Walt's
replies into one note (to try and keep it simple).

Walter Banks wrote:

{Quote hidden}

I agree but... When I was researching the 68HC05 for my new book and I was
talking to Motorola, their design point is to have a customer come to them
with specific peripheral requirements and them to design a custom MCU around
those requirements.  This is the reason why Motorola announces that there
are over 180 part numbers in the 68HC05 family and you can only buy the most
basic (ie "C" and "J" parts even though you've found a part that's "perfect"
for your application).

This flies directly in the face of the philosophy behind the SX and
Motorola's success is hard to argue with.

I'm really playing devil's advocate here.  I would probably argue that the
SX is a better hobbyist part than the Motorola products, but if I was
putting a MCU in car which would I choose?

On this point, Tjaart wrote:

>If scenix can get someone like Walter Banks (Hi Walter!) to write a VHDL
>compiler for the Scenix, this can become a really attractive alternative
>to
>GALs. The only restriction would be pins, but I'm sure there will be
>bigger
>devices out some time. Logic array's, state machines, FIFO's, clocks,
>timers
>(smallish) integrate-and-dump's could be real easy, fast, and cheap to
>develop.

I would be interested to see a working GAL/FPGA application where the SX
could get reasonable pin delays (ie sub 100 nsec which is 5 instruction
cycles) and constant delays throughout the chip.  I initially thought about
this application and then more or less dismissed it because I felt that
provide constant "gate delays" through the application and have them reasonably

>The RAM is a bit of a restriction that could keep it out of DSP
>applications
>for now.

I don't think the SX will ever be a candidate for any DSP applications.

On Virtual Device Bandwidth useage Walter Banks wrote:

>It is a trade-off between application code and I/O. On
>one hand the I/O can be crafted specifically for the
>application reducing available bandwidth but making
>the application code less complex. Very little has
>been written or seriously studied
>about virtual peripheral algothrims.

Well, I'm looking for a Master's project right now...  Actually this would
be very useful for me at work right now because of some projects we are
getting involved with.  I have to think about that.

On the bandwidth issue, Tjaart wrote:

>I gave some thought to the time taken to get hardware (like I2C) going
>on a
>chip vs. the time taken to write it in software in a way that makes
>sense to
>your program style. I wrote a few I2C routines two years ago that I am
>still
>using without change. I've tried to use the hardware, but have always
>come
>back to my own stuff.

I2C is a poor example for the PIC and probably one that is a bit
immflammatory (I, like just about everyone else, would like real I2C
(Multi-)Mastering built into the mid-range PICs).  But, I've written about
three serial interfaces for the PIC and when I compare how much effort they
were to doing it all in hardware (ie on a 16C73A), I would always prefer
doing it in hardware.

As well, I think there's a real style and overall application/device
knowledge needed to write virtual peripherals that requires much more effort.

On my Virtual Serial port used in the Programmer in the book, Clyde wrote:

>Is this clock cycles or instruction cycles? My code needs only 30 instruction
>cycles per interrupt.

This is clock cycles actual code space is about 225 words.

>> To send/receive a byte, in the SX running at 50 MIPs, 52,050 cycles are
>> available.  This means that there is about a 1% overhead to run the
>
>There's an order of magnitude error here. At 50MHz, 10 bits at 1200bps
>is about 8 ms, i.e. 50,000 cycles/ms times 8 is about 400,000 cycles per
>byte! So 1200bps uses way less than 1% of the CPU.

Yes, you're right, 50k cycles is for 9600 bps.  Sorry about that.

>Using my code, with 8 interrupts per bit, 10 bits per byte,
>we get 2400 cycles/byte, and at 115,200 bps at 50MHz on the SX there
>are about 4340 cycles/byte available. So 115,200 is doable with about
>60% CPU usage. If the sampling rate (interrupts per bit) can be
>reduced, it's even better.

About Peripheral Creation, Walter Banks wrote:

{Quote hidden}

That was something I was trying to say when I discussed my Serial Interface.
I guess the question is, does developing virtual peripherals mean that a new
method of software development has to be created/taught?

On this issue, Tjaart wrote:

>Something else - when you lay out you PCB, you can route the lines
>directly
>to the nearest pin without wondering how you are going away on a single
>sided
>PCB.

Agreed and actually the only tangible advantage I can see for the SX.  This
is really a follow up comment on Tjaart's:

>I wouldn't say that. Running off the internal 4MHz clock, it would
>perform the
>same as a 16MHz 16F84 (If there was such a PIC). Emissions would surely
>be
>lower... It uses 1.5mA at 4Mhz, while the 16F84 uses more than that at
>10MHz.

If that's the case, why would I convert over the SX as opposed to a
prototyping with a 16F84 and running a 16C61 at 16 MHz?  The 16C61 requires
about 2.7x the current at that frequency.  What is the compelling reason to
go to the SX (that I, and virtually everybody else has not even seen
running), when I have a solution I'm comfortable with (and know works - this
is exactly what I did with the programmer in the book)?

Another point you raised is:

>This raises another issue. It seems to take a few tries before dedicated
>hardware peripherals run smoothly. An example would be the BRGH=1 issue
>on
>the 16C74's (Mchip is not alone here). Silicon fixes require more time
>than a
>software fix. Once you have your library going, you can use
>tried&trusted
>code on every new project.

I disagree that this is an advantage.  I would prefer working around a
problem that I knew about (such as the BRGH=1) than rely on updating code in
the field.

On Software Development Systems Walter Banks wrote:

>A lot of what we have been doing is working with
>SX developers to create standards for implementing
>virtual peripherals so that they can be built
>into standardized libraries.

Are these standards published anywhere?

For my question asking if the SX would be used before paying a company to
develop a device before Walter Banks replied with:

>Not quite in those terms at least we haven't thought
>it through to that point. Most of our focus has been
>looking at unique development tools issues for the
>SX applications.  The major issue is processor bandwidth
>tradeoffs as part of the optimization considerations.

My comments were based on my thoughts on the 68HC05 (see above).

On the Basic Stamp Clones Walter Banks wrote:

>This would be a very flexible low volume application platform with
>fairly good performance.  The Microchip PIC based BASIC stamp
>and Stamp2 solved a lot of the timing problems associated with the
>virtual peripherals they implemented. "It is a shame that so many
>companies have chosen sell reverse engineered derivatives of those
>products and discourage many creative developers from promoting
>their ideas in hardware and software".(end of soapbox)

I don't agree with you on this - PAX has spent a long time without
significantly improving their products and just raking in the profits.

Actually a number of other companies have done the same thing.  I'm reacting
to a personal attack I've received from just a company that was upset about
a project in my PIC book; the company thought that I was taking away sales
from them on a product they have been marketing for several years and has
been a real cash cow for them.  Their feeling was they came up with the
original idea and I was tresspassing on their intellectual property by
presenting source code in the book.

If somebody comes up with a clone of your product that's better, cheaper and
compatible either you up the ante or get left in the dust.  In the end, it's
the customer that wins.  I've tried to avoid the obvious example of the IBM
PC, but I can't.

>> But, in general use will it take over the market?

Walt Banks wrote:

{Quote hidden}

If the SX's design is around "raw computing power" I would have thought
there were better architectures than the 5x?

Clyde wrote:

>Most unlikely. I don't actually see it competing with Microchip directly -
>Microchip just don't have anything that does the same job, nor would
>the SX be suitable for many things done with PICs right now. It's more
>complementary than competitive.
>
>Actually, it would make a lot of sense for Microchip to simply buy Scenix!

I think that would be unnecessarily cruel to Tjaart  :)

Who wrote:

{Quote hidden}

I personally really like the PIC.  I've just gone through five different
microcontrollers at the same level as the PIC for my new book.  I can
honestly say that Microchip support is superior to the other manufacturers
that I have worked with on it (even though they are as just as enthusiastic
about their products as Microchip is about the PIC - I can give you the
names of five senior executives that all feel that their products are better
than anybody elses and give you reasons why).


I have been playing the devil's advocate a lot in this note and I hope I
haven't offended anybody.  I am really interested in the discussion on
"Virtual Peripherals" because in my day job (as a Test Engineer) it is
something that could really make my life (and a lot of other people's) a lot
better.

myke

Check out "Programming and Customizing the PIC Microcontroller" at:

http://www.myke.com

More... (looser matching)
- Last day of these posts
- In 1997 , 1998 only
- Today
- New search...