Searching \ for '[PIC] 8-Bit PICs with Enhanced Mid-Range Core Arch' 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: '8-Bit PICs with Enhanced Mid-Range Core Arch'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] 8-Bit PICs with Enhanced Mid-Range Core Arch'
2008\11\04@185403 by Steve Rapinchuk

flavicon
face
Anyone had a chance to check out this announcement from Microchip?

www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=2018&mcparam=en538258
http://www.microchip.com/enhanced

I'm curious how the price of a PIC16F1936 will compare to a
PIC18F2321 ($1.96 volume pricing), as the performance enhancements
make the two fairly equal when running on the internal oscillator (32MHz).

-Steve Rapinchuk

2008\11\04@204023 by Xiaofan Chen

face picon face
On Wed, Nov 5, 2008 at 7:53 AM, Steve Rapinchuk <spam_OUTsteveTakeThisOuTspamoakvalley.com> wrote:
> Anyone had a chance to check out this announcement from Microchip?
> http://www.microchip.com/enhanced
>
> I'm curious how the price of a PIC16F1936 will compare to a
> PIC18F2321 ($1.96 volume pricing), as the performance enhancements
> make the two fairly equal when running on the internal oscillator (32MHz).
>

I think it is good that Microchip still invests on the PIC16F family.
The speed bump (8MIPS), 5V operation and memory boost
all help the user. However, banking is still there.

If you do not need 5V operation, you should look at PIC18J
and 18K family. Using the Microchip published volume
pricing as the benchmark:
PIC18F2321: US$1.96 8KB Flash, 512B RAM, 256B EEPROM
PIC18F24J10: US$1.38 16KB Flash, 1K RAM, no EEPROM
PIC18F24K20: US$1.44 16KB Flash, 768B RAM, 256B EEPROM

I tend to believe PIC16F1936 will not be cheaper than
PIC18J and PIC18K because of the 5V feature (-->older
generation of CMOS process).

Xiaofan

2008\11\04@221734 by Matt Luckman

flavicon
face
Xiaofan Chen wrote:
> I think it is good that Microchip still invests on the PIC16F family.
> However, banking is still there.
>  

Yes, but there is now a single instruction to change banks (like PIC18).
There is also a facility to access RAM linearly (indirectly via two
available 16-bit FSRs). We are finding these new PICs are providing many
opportunities for new optimizations.

--
Matt Luckman
Chief Technical Officer
HI-TECH Software Pty Ltd
http://www.htsoft.com


2008\11\04@225418 by Xiaofan Chen

face picon face
On Wed, Nov 5, 2008 at 11:17 AM, Matt Luckman <.....luckyKILLspamspam@spam@htsoft.com> wrote:
> Xiaofan Chen wrote:
>> I think it is good that Microchip still invests on the PIC16F family.
>> However, banking is still there.
>>
>
> Yes, but there is now a single instruction to change banks (like PIC18).
> There is also a facility to access RAM linearly (indirectly via two
> available 16-bit FSRs). We are finding these new PICs are providing many
> opportunities for new optimizations.
>

You are right. But the cost still is the most important factor. IMHO,
a lot of the people should look at PIC18J and PIC18K now.

Xiaofan

2008\11\04@230902 by Harold Hallikainen

face
flavicon
face

> If you do not need 5V operation, you should look at PIC18J
> and 18K family. Using the Microchip published volume
> pricing as the benchmark:
> PIC18F2321: US$1.96 8KB Flash, 512B RAM, 256B EEPROM
> PIC18F24J10: US$1.38 16KB Flash, 1K RAM, no EEPROM
> PIC18F24K20: US$1.44 16KB Flash, 768B RAM, 256B EEPROM
>
> I tend to believe PIC16F1936 will not be cheaper than
> PIC18J and PIC18K because of the 5V feature (-->older
> generation of CMOS process).
>
> Xiaofan

I'm using the 18f25k20 in a project. It's a real nice small qfn with
internal clock running at 64MHz.

Harold


--
FCC Rules Updated Daily at http://www.hallikainen.com - Advertising
opportunities available!

2008\11\05@020135 by William \Chops\ Westfield

face picon face

On Nov 4, 2008, at 5:40 PM, Xiaofan Chen wrote:

> I think it is good that Microchip still invests on the PIC16F family.

I guess.  The new features look useful, but I thought that the 18  
series WAS the "enhanced 8bit cpu", and I'm not sure what niche the  
"enhanced midrange" is supposed to fill (insufficient data, so far, I  
guess.)  I almost smacks of the unfortunate tendency of large  
companies to split their engineering teams into separate groups with  
separate responsibilities, budgets, success criteria, and so on, such  
that it's "best" not to ask whether your new enhanced product  
conflicts with the other groups' products...  Sigh.

BillW

2008\11\05@021518 by Wouter van Ooijen

face picon face
> Anyone had a chance to check out this announcement from Microchip?

Interesting reading. If they did not make any mistakes preemptive
context switching is possible on these new 16F's.

But IMHO it is a bad choice to call these chips 16F's. 16F now covers
12-bit cores, 14-bit cores, and enhanced 14-bit cores.

--

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu

2008\11\05@042713 by Tamas Rudnai

face picon face
> You are right. But the cost still is the most important factor. IMHO,
> a lot of the people should look at PIC18J and PIC18K now.

The problem is that 18F is not available in small packages, while AVR uses a
18F comparable instruction set, therefore they can archive a higher
performance even in the smallest package. With this enhanced core PIC can
compete AFAIK. Also with the new stack operation it is possible to write a
real pre-emptive RTOS on it, so I like it. Not to mention that you can read
the program memory using the FSR. With 14bit you can store 2x7bit ASCII char
on ROM for example comparing with the old RETLW stile tables where you had
only 1 char per word plus a fairly complicated computed goto to read it.

Tamas


On Wed, Nov 5, 2008 at 3:53 AM, Xiaofan Chen <xiaofancspamKILLspamgmail.com> wrote:

{Quote hidden}

> -

2008\11\05@071305 by olin piclist

face picon face
William Chops" Westfield" wrote:
> I guess.  The new features look useful, but I thought that the 18
> series WAS the "enhanced 8bit cpu", and I'm not sure what niche the
> "enhanced midrange" is supposed to fill (insufficient data, so far, I
> guess.)  I almost smacks of the unfortunate tendency of large
> companies to split their engineering teams into separate groups with
> separate responsibilities, budgets, success criteria, and so on, such
> that it's "best" not to ask whether your new enhanced product
> conflicts with the other groups' products.

Well put.  I've been wondering exactly the same thing.  While the enhanced
16F look interesting and have architectural advantages over the regular 16F,
so far to me they seem pointless compared to the 18F.  Perhaps there will be
a price advantage or smaller packages if the core is still significantly
smaller than a PIC 18 core.  I'd like to believe in the enhanced 16F but
until we get some hard data I'll remain skeptical.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2008\11\05@072207 by olin piclist

face picon face
Tamas Rudnai wrote:
> Also with the new stack operation it is
> possible to write a real pre-emptive RTOS on it, so I like it.

And you actually have a real application where this makes any sense?  A
preemptive RTOS on a tiny system sounds downright silly.  Note that this is
possible today on 18F but is very very rarely used (I never have and don't
know of any case personally).  I've used a simple cooperative task switcher
a few times on a 18F, but never had a problem where a preemptive task
switcher would have been a good idea.

Chances are that if the application is complicated enough where a preemptive
RTOS is actually a good solution, the small cost difference between a 18F
and a 16F is going to be irrelevant.  In fact, you'd probably use a dsPIC or
PIC32 in that case anyway.

So the point to a preemptive RTOS on a PIC 16 is...?


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2008\11\05@081915 by apptech

face
flavicon
face
>> Also with the new stack operation it is
>> possible to write a real pre-emptive RTOS on it, so I like it.

> And you actually have a real application where this makes any sense?  A
> preemptive RTOS on a tiny system sounds downright silly.

The sound of one dog barking.
Life is a continuum.
Surely even you can allow that it's possible or even just maybe reasonable
for someone to like something because it has a greater degree of capability
than it might otherwise have had, or than something else?

One may go a lifetime, or several and never implement a pre-emptive RTOS,
but there also may be 2 occasions in Tashritu where you actually find the
capability useful.

The argument that one should use the device with the most possible hair on
its chest / cubic inches / raw horsepower for a given task would see us all
driving hummers to the corner store, and worse. (If it's possible to do
worse than driving a hummer to the corner store).

> Chances are that if the application is complicated enough where a
> preemptive
> RTOS is actually a good solution, the small cost difference between a 18F
> and a 16F is going to be irrelevant.  In fact, you'd probably use a dsPIC
> or
> PIC32 in that case anyway.
>
> So the point to a preemptive RTOS on a PIC 16 is...?

Try and see if you can see it from the other end - if you are using a PIC16
for reasons which are overwhelmingly good or necessary (or both) then having
this extra capability, or others, may be occasionally useful. No?


 Russell

2008\11\05@083345 by Walter Banks

picon face


Steve Rapinchuk wrote:

> Anyone had a chance to check out this announcement from Microchip?
>
> www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=2018&mcparam=en538258
> http://www.microchip.com/enhanced
>
> I'm curious how the price of a PIC16F1936 will compare to a
> PIC18F2321 ($1.96 volume pricing), as the performance enhancements
> make the two fairly equal when running on the internal oscillator (32MHz).

These are interesting parts for many applications. The instruction set
enhancements have dramatically improved performance and application
flexibility.

Our C support for the Enhanced Mid Range parts includes
18037 fixed point data types and fixed point transcendential libraries.

The additional data flow and memory management alternatives have
suddenly made the mid range parts viable for much larger applications.

Contact me off-line if you have plans to consider using these parts.

Regards

--
Walter Banks
Byte Craft Limited
http://www.bytecraft.com


2008\11\05@084321 by Ruben Jönsson

flavicon
face
> Tamas Rudnai wrote:
> > Also with the new stack operation it is
> > possible to write a real pre-emptive RTOS on it, so I like it.
>
> And you actually have a real application where this makes any sense?  A
> preemptive RTOS on a tiny system sounds downright silly.  Note that this is
> possible today on 18F but is very very rarely used (I never have and don't know
> of any case personally).  I've used a simple cooperative task switcher a few
> times on a 18F, but never had a problem where a preemptive task switcher would
> have been a good idea.
>
> Chances are that if the application is complicated enough where a preemptive
> RTOS is actually a good solution, the small cost difference between a 18F and a
> 16F is going to be irrelevant.  In fact, you'd probably use a dsPIC or PIC32 in
> that case anyway.
>
> So the point to a preemptive RTOS on a PIC 16 is...?
>

Perhaps for a high level language compiler or interpreter used in projects
where you don't need the full horse power of a streamlined asm program but
instead quick development times. Something like a BASIC stamp but with rtos
capabilities which is directed towards industrial automation applications
instead of hobby applications.

Actually, the new features looks pretty much like improvements to better fit
high level languages and compilers.

This only makes sense if the new enhanced PIC 16 is much cheaper than its big
brothers though and where you buy them by the thousands.

/Ruben
==============================
Ruben Jönsson
AB Liros Electronic
Box 9124, 200 39 Malmö, Sweden
TEL INT +46 40142078
FAX INT +46 40947388
EraseMErubenspam_OUTspamTakeThisOuTpp.sbbs.se
==============================

2008\11\05@090505 by Walter Banks

picon face


apptech wrote:

> >> Also with the new stack operation it is
> >> possible to write a real pre-emptive RTOS on it, so I like it.
>
> > And you actually have a real application where this makes any sense?  A
> > preemptive RTOS on a tiny system sounds downright silly.
>
> The sound of one dog barking.
> Life is a continuum.

The enhanced mid range could support a small RTOS. We have
been looking at the whole solution space real time support for
embedded processors and have added event driven execution
in our support for the enhanced mid range parts.

In event driven execution, execution can start when some logical
set of conditions are met. The set of conditions can be some combination
of global variable values and/or interrupt conditions. Event driven
execution in our benchmarks reduce RAM, stack size and average
execution time requirements and increase the standard deviation
of  response time.

Event driven programming simplifies a lot of real time application
programming. It significantly simplifies exception handling.

There is an internal white paper on this at Byte Craft that I will
arrange to have posted on the web site.


Regards

--
Walter Banks
Byte Craft Limited
http://www.bytecraft.com



2008\11\05@091224 by olin piclist

face picon face
Ruben Jönsson wrote:
> Perhaps for a high level language compiler or interpreter used in
> projects
> where you don't need the full horse power of a streamlined asm
> program but
> instead quick development times. Something like a BASIC stamp but
> with rtos
> capabilities which is directed towards industrial automation
> applications
> instead of hobby applications.

Yes you can concoct ways to use it, but note that you can already do all
this with the existing 18F.  Everything you mentioned above is not
price-critical.

> This only makes sense if the new enhanced PIC 16 is much cheaper than
> its big
> brothers though and where you buy them by the thousands.

Exactly.  Unless there is a relevant price advantage, or maybe in some cases
physical space or power advantage, I'm having a hard time understanding the
point of the enhanced 16F line.  And those applications where physical size
is important are probably not being held back by the current 16F line.  The
18F "nano-watt" parts are also very low power, so that leaves price at
higher processor perfomance as the only advantage of the enhanced 16F line.

We'll have to wait and see if a significant price advantage materializes.
If not, then this will have been a stupid idea.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2008\11\05@091437 by Walter Banks

picon face


Ruben Jönsson wrote:

> Perhaps for a high level language compiler or interpreter used in projects
> where you don't need the full horse power of a streamlined asm program but
> instead quick development times. Something like a BASIC stamp but with rtos
> capabilities which is directed towards industrial automation applications
> instead of hobby applications.
>
> Actually, the new features looks pretty much like improvements to better fit
> high level languages and compilers.

I think that this is part of the changes. Compiling for the 14 bit code is
well understood. The enhanced core changed some of the code
generation dynamics in two important ways. The architecture changes
for the most part added instruction selection and memory
management options. The added choices opened many code generation
alternatives that map applications on to the silicon.

ISO61131 based process control applications for example are likely to
map on the enhanced mid range cores quite well.

Regards

--
Walter Banks
Byte Craft Limited
http://www.bytecraft.com


2008\11\05@093140 by Xiaofan Chen

face picon face
On Wed, Nov 5, 2008 at 10:13 PM, Walter Banks <walterspamspam_OUTbytecraft.com> wrote:
> ISO61131 based process control applications for example are likely to
> map on the enhanced mid range cores quite well.

I am working for a PLC company. But sorry I have no idea
what do you mean by this sentence.

Xiaofan

2008\11\05@103422 by Walter Banks

picon face


Xiaofan Chen wrote:

> On Wed, Nov 5, 2008 at 10:13 PM, Walter Banks <@spam@walterKILLspamspambytecraft.com> wrote:
> > ISO61131 based process control applications for example are likely to
> > map on the enhanced mid range cores quite well.
>
> I am working for a PLC company. But sorry I have no idea
> what do you mean by this sentence.

ISO61131 formally  defines IL (Instruction language) ST (structure language)
and LD (Ladder) it ties them together and defines the relationship between them.
Sequential Function Chart (SFC) and Function Block Diagram (FBD)
define how the pieces are assembled in an application.

Two very interesting points. Function  Block Diagrams are an approach to build
a large programming system that is processor element independent. From
a programmers point of view FBD's can be implemented in a single or multiple
processors and the controlled system doesn't care.

My second point is the implementation can be (probably should be) event driven
and that maps well on the enhanced mid range parts.

FBD's have been extended and enhanced in some other ISO documents. FDB's
are a reasonably well defined way to accomplish parallel programming
independent of the number of underlying processors.


The enhanced mid range parts could well become a FDB or third party
supplied FDB to be incorporated into a larger system.

Regards

--
Walter Banks
Byte Craft Limited
http://www.bytecraft.com




2008\11\05@103449 by Rolf

face picon face
Olin Lathrop wrote:
> ... this will have been a stupid idea.
>
>  
One of the great things about technology is the way it moves on. One of
the really great things about technology moving on is that the
no-longer-cutting-edge tools and facilities become available for people
on the market for a bargain.

There could be something as simple as a relatively cheap fabrication
plant that has come available on the market and Microchip bought it up.
Or, they have moved one line of production to a new cheaper facility,
leaving the older line available for different purposes.

It would not surprise me if there is some fab line out there that MC has
acquired that supports the faster (perhaps physically smaller) chips and
it makes sense to take advantage of both the available fab facilities as
well as the available chip functionality on the new fab line.

This probably provides MC the option of slowing down production at the
low end of the 18F line and ramping up the new high end of the 16F line.
Sure there's a decreasing gap between the functionality of the two, but,
that's progress.

There are all sorts of reasons why MC would choose to do these things.
Progress is a good thing. Also, it is safe to assume that their research
departments have identified a market for these new chips long before
they planned the production of them. Just because you are not the
intended market does not make it a stupid idea.

Rolf


2008\11\05@110722 by olin piclist

face picon face
Rolf wrote:
> Also, it is safe to assume that their
> research departments have identified a market for these new chips
> long before they planned the production of them.

I'm sure they did, but that doesn't mean they got it right.  Remember the
PIC 17 and the 8 bit PIC 18s?


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2008\11\05@113654 by William \Chops\ Westfield

face picon face

On Nov 5, 2008, at 7:32 AM, Walter Banks wrote:

>>> ISO61131 based process control applications for example are likely  
>>> to
>>> map on the enhanced mid range cores quite well.
>>
>> I am working for a PLC company. But sorry I have no idea
>> what do you mean by this sentence.
>
> My second point is the implementation can be (probably should be)  
> event driven
> and that maps well on the enhanced mid range parts.

I read this as "While there have been C compilers for some time now  
that support the midrange PICS, there are certain constructs that are  
common in some application areas (eg ISO61131) that were NOT easily  
implemented by those C compilers that are much more easily implemented  
using the enhanced midrange architecture."

(I'm not sure how how function pointers were handled before, but it  
sure looks like it's a lot easier to do now!  For that matter, while  
it may not be a big deal to ASM programmers, the whole "registers,  
SFRs, RAM, and Flash now share a single address space" is probably  
REALLY nice for C compiler writers...)

(It's a nice sign that the compiler vendors were involved with this so  
early on in the games...)

BillW

2008\11\05@113946 by Martin K

face
flavicon
face
Xiaofan Chen wrote:
> I think it is good that Microchip still invests on the PIC16F family.
> The speed bump (8MIPS), 5V operation and memory boost
> all help the user. However, banking is still there.
>
> If you do not need 5V operation, you should look at PIC18J
> and 18K family. Using the Microchip published volume
> pricing as the benchmark:
> PIC18F2321: US$1.96 8KB Flash, 512B RAM, 256B EEPROM
> PIC18F24J10: US$1.38 16KB Flash, 1K RAM, no EEPROM
> PIC18F24K20: US$1.44 16KB Flash, 768B RAM, 256B EEPROM
>
> I tend to believe PIC16F1936 will not be cheaper than
> PIC18J and PIC18K because of the 5V feature (-->older
> generation of CMOS process).
>
> Xiaofan
>  
A little more dramatic is the:
18F4321: 8KB program, 512B RAM $2.19
18F45K20: 32KB, 1536B RAM, $1.87

It's 3.3v but if you're going to 'upgrade' to a cheaper chip it might be
worth it to figure out how to migrate to 3.3v
-
Martin

2008\11\05@114330 by Martin K

face
flavicon
face
apptech wrote:
> The argument that one should use the device with the most possible hair on
> its chest / cubic inches / raw horsepower for a given task would see us all
> driving hummers to the corner store, and worse. (If it's possible to do
> worse than driving a hummer to the corner store).
>  

PIC16:walking
PIC32:hummer ?

-
Martin

2008\11\05@114911 by Martin K

face
flavicon
face
On one hand I agree - but from the point of view of most of us on the
PIClist who mostly deal in quantities <1000, we don't worry about
pennies quite as much as the white-goods manufacturers who order PICs by
the 100k. Design time for something that will sell 1000 a year should be
first place ahead of saving $1 on the MCU.
-
Martin

Olin Lathrop wrote:
{Quote hidden}

2008\11\05@124338 by Walter Banks

picon face


William \"Chops\" Westfield wrote:

{Quote hidden}

Our code generator is using both the new pointers and earlier
code for pointers in the generated code.  There are trade-offs, but
now we have a code generation choices that increases the
opportunities to map application to the silicon cleanly.  For what
it is worth our code generator was implemented as a separate
unique core. There are core level choices that make this a good
design decision.

Regards

--
Walter Banks
Byte Craft Limited
http://www.bytecraft.com



2008\11\05@124754 by Rolf

face picon face
Olin Lathrop wrote:
> Rolf wrote:
>  
>> Also, it is safe to assume that their
>> research departments have identified a market for these new chips
>> long before they planned the production of them.
>>    
>
> I'm sure they did, but that doesn't mean they got it right.  Remember the
> PIC 17 and the 8 bit PIC 18s?
>
>
> ********************************************************************
> Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
> (978) 742-9014.  Gold level PIC consultants since 2000.
>  
While they have made mistakes, it would be somewhat presumptuous to
believe that your are more in touch with all their customers than they are.

Microchip says there is a market for enhanced PIC16's. Olin says it's a
stupid idea.

I know who my money would be on.

Then again, this will just require patience to resolve. It won't be long
until there are real numbers out.

Rolf

2008\11\05@131206 by olin piclist

face picon face
Martin K wrote:
> On one hand I agree - but from the point of view of most of us on the
> PIClist who mostly deal in quantities <1000, we don't worry about
> pennies quite as much as the white-goods manufacturers who order PICs
> by
> the 100k. Design time for something that will sell 1000 a year should
> be first place ahead of saving $1 on the MCU.

Right, so what's the point in this context of a enhanced 16F that's slightly
cheaper than a 18F?


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2008\11\05@131419 by olin piclist

face picon face
Rolf wrote:
> Microchip says there is a market for enhanced PIC16's. Olin says it's
> a stupid idea.

No, I said that it may be depending on data that is not yet available.

********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2008\11\05@142811 by Martin K

face
flavicon
face

Olin Lathrop wrote:
> Martin K wrote:
>  
>> On one hand I agree - but from the point of view of most of us on the
>> PIClist who mostly deal in quantities <1000, we don't worry about
>> pennies quite as much as the white-goods manufacturers who order PICs
>> by
>> the 100k. Design time for something that will sell 1000 a year should
>> be first place ahead of saving $1 on the MCU.
>>    
>
> Right, so what's the point in this context of a enhanced 16F that's slightly
> cheaper than a 18F?
>
>
> ********************************************************************
> Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
> (978) 742-9014.  Gold level PIC consultants since 2000.
>  

"slightly cheaper" is the point.

2008\11\05@160614 by Rolf

face picon face
Olin Lathrop wrote:
> Rolf wrote:
>  
>> Microchip says there is a market for enhanced PIC16's. Olin says it's
>> a stupid idea.
>>    
>
> No, I said that it may be depending on data that is not yet available.
>  
True, you said it depended on unknown data (to us, but available to
Microchip).

I am not sure how that changes your previous posts in any way. It just
reinforces that Microchip knows their market better than you do.

As for me, I am just pleased that Microchip is still willing to innovate
at a time when it must be tempting to hunker down. It's a credit to the
company that is willing to take a (calculated) risk. Bring it on.

Rolf

2008\11\06@084215 by Xiaofan Chen

face picon face
On Wed, Nov 5, 2008 at 11:32 PM, Walter Banks <KILLspamwalterKILLspamspambytecraft.com> wrote:
> Two very interesting points. Function  Block Diagrams are an approach to build
> a large programming system that is processor element independent. From
> a programmers point of view FBD's can be implemented in a single or multiple
> processors and the controlled system doesn't care.
>
> My second point is the implementation can be (probably should be) event driven
> and that maps well on the enhanced mid range parts.
>
> FBD's have been extended and enhanced in some other ISO documents. FDB's
> are a reasonably well defined way to accomplish parallel programming
> independent of the number of underlying processors.
>
> The enhanced mid range parts could well become a FDB or third party
> supplied FDB to be incorporated into a larger system.

Two things:
1) Are you saying you want to use FBD to programing PICs?
Even though this might be possible but I highly doubt it will be
popular anytime soon. Last time there was a ladder compiler
for PIC but I never really know if the product comes out or not.

2) Are you saying you want to use mid-range as a part for
the distributed control unit? Something like those mentioned
in IEC61499.

I used to see 8-bit MCUs like 8051 used in small PLCs.
Now even the cheapest US$100 pico/nano PLC uses 32bit
MCU.

And even if you are right, the ability of the enhanced PIC16F
has already been available in PIC18F for years. And none of
the things come close to what you think have come into reality.

Xiaofan

2008\11\06@100458 by Walter Banks

picon face


Xiaofan Chen wrote:

> Two things:
> 1) Are you saying you want to use FBD to programing PICs?
> Even though this might be possible but I highly doubt it will be
> popular anytime soon. Last time there was a ladder compiler
> for PIC but I never really know if the product comes out or not.

I doubt that you will see a ladder compiler used with PIC to
build a FBD but ST or possibly IL might be a a reasonable
way to program PIC's

> 2) Are you saying you want to use mid-range as a part for
> the distributed control unit? Something like those mentioned
> in IEC61499.

The is the approach that I see as a possibility. Small functional
blocks either distributed or in one place. For example a sensor
that deals with its calibration data and signal processing having
a FBD interface to the rest of the system. Well defined standard
interfaces.

> I used to see 8-bit MCUs like 8051 used in small PLCs.
> Now even the cheapest US$100 pico/nano PLC uses 32bit
> MCU.

A system now is a pico PLC with external links to IEC61499
type FBD's or other pico PLC

> And even if you are right, the ability of the enhanced PIC16F
> has already been available in PIC18F for years. And none of
> the things come close to what you think have come into reality.

True but there is a lot of work now on distributed processing and
on the ISO61131 and ISO61499 standards. As an alternative to
RTOS's in small embedded systems event driven programming
works well.

I have done a lot of work in tools support for automotive engine
controllers. Most of them use a multiprocessor based event
system consisting of a powerPC sized host CPU and two
I/O event driven processors. The operation is surprisingly similar to
ISO/IEC 61499. There is no RTOS in the host CPU.

Regards

--
Walter Banks
Byte Craft Limited
http://www.bytecraft.com








2008\11\06@183535 by Xiaofan Chen

face picon face
On Thu, Nov 6, 2008 at 11:03 PM, Walter Banks <RemoveMEwalterTakeThisOuTspambytecraft.com> wrote:
>> And even if you are right, the ability of the enhanced PIC16F
>> has already been available in PIC18F for years. And none of
>> the things come close to what you think have come into reality.
>
> True but there is a lot of work now on distributed processing and
> on the ISO61131 and ISO61499 standards. As an alternative to
> RTOS's in small embedded systems event driven programming
> works well.

Depending on what you do, this distributed unit will still often
require more processing power than an enhanced PIC16F or
lower end PIC18F. In fact, I've seen this kind of distributed
unit (support limited function blocks) mostly using lower-end
32bit MCU like ARM7 level. But if you only want to use
a dedicated function, it should be feasible.

> I have done a lot of work in tools support for automotive engine
> controllers. Most of them use a multiprocessor based event
> system consisting of a powerPC sized host CPU and two
> I/O event driven processors. The operation is surprisingly similar to
> ISO/IEC 61499. There is no RTOS in the host CPU.

Interesting. I always think Automotive has a lot similarity
with Automation. For example, CAN is widely used in
both. If FlexRay becomes cheaper, it will find good use
in the factory automation market as well due to the
advantages over Ethernet based protocol (deterministic).
The biggest disadvantages about CAN are as following.
1) Speed: 1M can limit the bandwidth
2) Packet size and fragmentation : can be a bigger disadvantage
than the speed issue
3) Non-deterministic.

TTP/ByteFlight/FlexRay seem to be trying to solve the
problem of CAN.

Xiaofan

2008\11\06@213833 by Steve Rapinchuk

flavicon
face
Interesting info from one of the architects of the enhanced mid-range core:

http://forum.microchip.com/fb.aspx?m=380688

-Steve Rapinchuk

2008\11\07@230935 by Xiaofan Chen

face picon face
On Thu, Nov 6, 2008 at 3:27 AM, Martin K <spamBeGonemartinspamBeGonespamnnytech.net> wrote:
>
>> Right, so what's the point in this context of a enhanced 16F that's slightly
>> cheaper than a 18F?
>
> "slightly cheaper" is the point.

Microchip agrees with you. ;-)

Steve Rapinchuk mentioned about this thread and it has great info from
the designers.
http://forum.microchip.com/tm.aspx?m=378667

Still my assertion holds. The cost of the new enhanced PIC16F will not
be cheaper than the current PIC18J/PIC18K device. If you are ok with
3.3V operation and are doing new design, you should seriously look
at PIC18J/PIC18K instead of PIC16F or the enhanced PIC16F if all
of them meet your requirement.

Xiaofan

2008\11\08@032315 by Ruben Jönsson

flavicon
face
> On Thu, Nov 6, 2008 at 3:27 AM, Martin K <TakeThisOuTmartinEraseMEspamspam_OUTnnytech.net> wrote:
> >
> >> Right, so what's the point in this context of a enhanced 16F that's
> slightly
> >> cheaper than a 18F?
> >
> > "slightly cheaper" is the point.
>
> Microchip agrees with you. ;-)
>

Another thing that this is good for is that you might be able to reuse an old
design for something else. Whenever I need to do this it seems that I almost
always need more code space than the original design. If it already has a
standard 16F, you can just pop in an enhanced 16F which has more code and ram
memory. This way you have a proven design and may even be able to use the old
test reports for safety and EMC. "Just" change the code.

/Ruben
==============================
Ruben Jönsson
AB Liros Electronic
Box 9124, 200 39 Malmö, Sweden
TEL INT +46 40142078
FAX INT +46 40947388
RemoveMErubenspamTakeThisOuTpp.sbbs.se
==============================

2008\11\17@042929 by Xiaofan Chen

face picon face
On Fri, Nov 7, 2008 at 7:35 AM, Xiaofan Chen <xiaofancEraseMEspam.....gmail.com> wrote:
> On Thu, Nov 6, 2008 at 11:03 PM, Walter Banks <EraseMEwalterspambytecraft.com> wrote:
>> True but there is a lot of work now on distributed processing and
>> on the ISO61131 and ISO61499 standards. As an alternative to
>> RTOS's in small embedded systems event driven programming
>> works well.
>
> Depending on what you do, this distributed unit will still often
> require more processing power than an enhanced PIC16F or
> lower end PIC18F. In fact, I've seen this kind of distributed
> unit (support limited function blocks) mostly using lower-end
> 32bit MCU like ARM7 level. But if you only want to use
> a dedicated function, it should be feasible.
>
>> I have done a lot of work in tools support for automotive engine
>> controllers. Most of them use a multiprocessor based event
>> system consisting of a powerPC sized host CPU and two
>> I/O event driven processors. The operation is surprisingly similar to
>> ISO/IEC 61499. There is no RTOS in the host CPU.

Just read this one.
http://groups.google.com/group/fbdk/browse_thread/thread/375eff1ec8d80613

It seems the author or Muvium (JVM for PIC18) are trying
to do IEC61499 with PIC18 (albeit a bigger one).

Xiaofan

2008\11\17@100944 by Walter Banks

picon face


Xiaofan Chen wrote:

{Quote hidden}

Thanks for the link. There is a lot of interest in 61499 right now
because it is one of the few standards that deals with parallel
real time issues. There may be better solutions found but
this is a good starting point.

Walter Banks

2008\11\27@062002 by Mauricio Giovagnini

flavicon
face
Ruben Jönsson escribió:
>> On Thu, Nov 6, 2008 at 3:27 AM, Martin K <RemoveMEmartinTakeThisOuTspamspamnnytech.net> wrote:
>>>> Right, so what's the point in this context of a enhanced 16F that's
>> slightly
>>>> cheaper than a 18F?
>>> "slightly cheaper" is the point.
>> Microchip agrees with you. ;-)
>>
>
> Another thing that this is good for is that you might be able to reuse an old
> design for something else. Whenever I need to do this it seems that I almost
> always need more code space than the original design. If it already has a
> standard 16F, you can just pop in an enhanced 16F which has more code and ram
> memory. This way you have a proven design and may even be able to use the old
> test reports for safety and EMC. "Just" change the code.
>

I agree with you Ruben,

I read the hole thread and the microchip website about the
new enhanced architecture and at first glance I thought the
same than most of you probably: why? isn't it the same or a
mid-step between the 16F standard and the 18F ? and my
answer was "yet, it is but..."

And is the what follows the *but* of the sentence what
solves the dilemma... for some new developers may be this
will confused them more (I would start with a 18F if price
is not the main problem), but what about those more than 1
billion uC that are sold every year? Most of them are 8bit,
this is a well known information (even Mchip CEO admits that
one of their strategies is that one unit can support
economically other one until it is profitable or just
because is strategically important for them).
Well, many of those 'big customers' that buy almost 16F
parts could be interested in some enhancement in their 16F.
 May be redesigning an old project to fit a 18F part could
cost more than what we see by just comparing
microcontrollers costs...

I'm a small developer compared with huge companies, even
thou I have an application running on a 16F876 then I moved
it to a 16F876A (reducing costs very easily) and then to a
16F886 (reducing some u$s cents again).  The application
occupies almost 7.95K words; the fact is that I have added
some new priority features and deleted some old ones  (or
commented them in the cost) just because the code didn't
fit.  It is important to say that the code is fully written
in assembler with no tables... it is all code.

That application is very well tested, it's been in the
market for about 4 years and the best of all is that I trust
on it.  Changing to a 18F part, could be easily done but...
but I should test the application for every case and
condition, that could demand me (or to the tester) hours,
days, months.  Adding a new feature to a 16F part, would
demand only testing the new feature and the most common code
flow.  The enhanced architecture (and only for the reason of
having more program memory and more Mips) seems to be the
solution to my problem.  Even if costing some cents more
than the 16F886 , the equation is favorable.

Big companies have more strict development processes (using
CMMI for example), migrating a working code from a 16F to a
18F could impact in many other areas (documenting, project
planning, configuration management, testing, inspections,
and many more).  This costs money... tons of it.  Adding a
new feature to an existing 16F project will impact less
more...  the difference of some cents between the 16F to the
18F wouldn't matter here, the bigger impact would be the
engineers hours costs (as is the case in my small self
example).  And consider if the application is a medical
device or an engine injection controller ...

The application I'm talking about takes less than 1K 16F
parts a year but the applications of the big companies
probably will impact in thousands or millions of parts a
year.  Then if only a few big customers demand something
like this, may be that by itself will solve the equation.

Probably for new applications a 18F or a 16-bit part (dspic,
pic24, pic30) *are* the choice (even more considering that
most development are not mass production ones) A difference
in 1 u$s in a device is not much if we think the time that
takes making a design full-filling  constraints like fitting
in a small memory footprint, or dealing with intensive
calculation with a slow core (20MHz for example).  Those
constraints could demand more development days, that cost
big bucks that could be saved if using a bigger
microcontroller with a faster core... If we consider a
simple number like a 1K u$s per week per engineer (US,
Europe) , every week the development takes will require that
the marketing area would have to increase the selling by 1K
pieces per engineer/week involved in the development.

Going back to the 16-bit architecture, what about the
already existing designs? This new arch could be the answer
to those *big*, *huge* customers, those that are the reason
of why Microchip is growing each year...

Those companies probably have hundreds, or thousands of
lines of code in libraries, macros, code-snippets, in
assembler fully written for the 16F parts.




--
------------------------------
Mauricio Giovagnini (Maunix)
http://www.maunix.com.ar
Cordoba, Arg.
LinkedIn Profile: http://www.linkedin.com/in/mgiovagnini

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