From: John Larkin on 7 May 2010 22:49 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 7 May 2010 22:53 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 8 May 2010 00:34 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 8 May 2010 00:36 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 8 May 2010 07:43
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 |