From: John Larkin on
On Fri, 07 May 2010 21:41:21 -0500, "krw(a)att.bizzzzzzzzzzzz"
<krw(a)att.bizzzzzzzzzzzz> wrote:

>On Fri, 07 May 2010 22:01:45 -0400, Spehro Pefhany
><speffSNIP(a)interlogDOTyou.knowwhat> wrote:
>
>>On Fri, 07 May 2010 18:01:11 -0500, the renowned
>>"krw(a)att.bizzzzzzzzzzzz" <krw(a)att.bizzzzzzzzzzzz> wrote:
>>
>>>
>>>When I build the library parts I reduce the pin names to the function I'm
>>>actually using.
>>
>>Makes things harder than necessary for the firmware developers when
>>they are reading the schematic. Maybe not as important if one person
>>is doing both jobs and repurposing of pins etc. isn't likely.
>
>How so? The name reflects its purpose _in_the_design_. He doesn't care what
>the pin is able to do.

If you reuse the chip in another design, do you change the pin names?
In the library?

John


From: Spehro Pefhany on
On Fri, 07 May 2010 21:41:21 -0500, the renowned
"krw(a)att.bizzzzzzzzzzzz" <krw(a)att.bizzzzzzzzzzzz> wrote:

>On Fri, 07 May 2010 22:01:45 -0400, Spehro Pefhany
><speffSNIP(a)interlogDOTyou.knowwhat> wrote:
>
>>On Fri, 07 May 2010 18:01:11 -0500, the renowned
>>"krw(a)att.bizzzzzzzzzzzz" <krw(a)att.bizzzzzzzzzzzz> wrote:
>>
>>>
>>>When I build the library parts I reduce the pin names to the function I'm
>>>actually using.
>>
>>Makes things harder than necessary for the firmware developers when
>>they are reading the schematic. Maybe not as important if one person
>>is doing both jobs and repurposing of pins etc. isn't likely.
>
>How so? The name reflects its purpose _in_the_design_. He doesn't care what
>the pin is able to do.

She may decide to use a given pin as an interrupt rather than an
ordinary input pin, or to bit-bang communication rather than using
internal hardware to meet an oddball break requirement etc. etc.


Best regards,
Spehro Pefhany
--
"it's the network..." "The Journey is the reward"
speff(a)interlog.com Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog Info for designers: http://www.speff.com
From: krw on
On Fri, 07 May 2010 19:49:50 -0700, John Larkin
<jjlarkin(a)highNOTlandTHIStechnologyPART.com> wrote:

>On Fri, 07 May 2010 21:41:21 -0500, "krw(a)att.bizzzzzzzzzzzz"
><krw(a)att.bizzzzzzzzzzzz> wrote:
>
>>On Fri, 07 May 2010 22:01:45 -0400, Spehro Pefhany
>><speffSNIP(a)interlogDOTyou.knowwhat> wrote:
>>
>>>On Fri, 07 May 2010 18:01:11 -0500, the renowned
>>>"krw(a)att.bizzzzzzzzzzzz" <krw(a)att.bizzzzzzzzzzzz> wrote:
>>>
>>>>
>>>>When I build the library parts I reduce the pin names to the function I'm
>>>>actually using.
>>>
>>>Makes things harder than necessary for the firmware developers when
>>>they are reading the schematic. Maybe not as important if one person
>>>is doing both jobs and repurposing of pins etc. isn't likely.
>>
>>How so? The name reflects its purpose _in_the_design_. He doesn't care what
>>the pin is able to do.
>
>If you reuse the chip in another design, do you change the pin names?

Yes.

>In the library?

Yes. I hate big meaningless blocks for high density logic. I use homogeneous
blocks and separate functions and power. This almost always changes from
design to design so the library changes with it. It's *not* that hard to do.
From: krw on
On Fri, 07 May 2010 22:53:50 -0400, Spehro Pefhany
<speffSNIP(a)interlogDOTyou.knowwhat> wrote:

>On Fri, 07 May 2010 21:41:21 -0500, the renowned
>"krw(a)att.bizzzzzzzzzzzz" <krw(a)att.bizzzzzzzzzzzz> wrote:
>
>>On Fri, 07 May 2010 22:01:45 -0400, Spehro Pefhany
>><speffSNIP(a)interlogDOTyou.knowwhat> wrote:
>>
>>>On Fri, 07 May 2010 18:01:11 -0500, the renowned
>>>"krw(a)att.bizzzzzzzzzzzz" <krw(a)att.bizzzzzzzzzzzz> wrote:
>>>
>>>>
>>>>When I build the library parts I reduce the pin names to the function I'm
>>>>actually using.
>>>
>>>Makes things harder than necessary for the firmware developers when
>>>they are reading the schematic. Maybe not as important if one person
>>>is doing both jobs and repurposing of pins etc. isn't likely.
>>
>>How so? The name reflects its purpose _in_the_design_. He doesn't care what
>>the pin is able to do.
>
>She may decide to use a given pin as an interrupt rather than an
>ordinary input pin, or to bit-bang communication rather than using
>internal hardware to meet an oddball break requirement etc. etc.

The library part reflects its function. If the function changes then the
library part changes along with it. If it changes from hardware based
communication to bit-banged the function didn't change.
From: Jan Panteltje on
On a sunny day (Fri, 07 May 2010 21:37:22 +0100) it happened nospam
<nospam(a)please.invalid> wrote in <8kt8u55a21v709856fi48o570np4dns79r(a)4ax.com>:

>Jan Panteltje <pNaonStpealmtje(a)yahoo.com> wrote:
>
>>Do they not want people to use their chips?
>
>It is a relatively new chip, the issues you are complaining about have been
>documented in freely available errata for about a year (the errata is even
>linked from digikey product pages).
>
>The A8 silicon revision is supposed to have fixed these issues.
>
>A reasonable complaint would be about difficulty knowing what silicon
>revision you can buy.

Do you not think it is strange that it took 8 revisions for it to work (IF it works in A8)?
In my view Microflip should focus a bit more on quality and not so much
on putting out yet an other 'market segmented' version of the same thing.
What does a new mask cost these days? Must be very expensive, especially
if after 7 silicon versions with the same problem not a single customer will buy these chips.
No return on investment.

When I bought the Z80, in the 19 eighties, a chip that has a much
more complicated instruction set, but much easier to use, it worked on all advertised issues.
Indeed hardware like this is becoming like Microsoft software,
to actually use it you need the next service pack, and that then breaks some things usually.
If John L gets his way, and we get RAM (say FPGA) on chip to for the microcode,
then next thing is 'live updates' for your embedded system.
I am out of here :-)
LOL