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:

>> > 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.

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:

>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.

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:

>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.

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:

>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.

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