An other Microchip screwup on teh 18F14K22
in [Design]
|
From: John Larkin on 7 May 2010 15:38 On Fri, 07 May 2010 19:25:00 GMT, Jan Panteltje <pNaonStpealmtje(a)yahoo.com> wrote: >On a sunny day (Fri, 07 May 2010 09:27:35 -0700) it happened John Larkin ><jjlarkin(a)highNOTlandTHIStechnologyPART.com> wrote in ><t8f8u5d858e95v5mjqt17m4td3s4b9ia7q(a)4ax.com>: > >>>Looks bit like those old Intel erratas, that got me in the past. >>>Do they not want people to use their chips? >>>Paul Schoen was right 18F14K22 SPI sucks. >> >> >>That's pretty bad. But uPs are getting so complex, so overloaded with >>features, that the designers are sort of shoveling hunks of home-made >>or purchased IP into compilers and hoping for the best. And, >>apparently, not taking much time to simulate and verify. Or document! >>We had to do a bunch of experiments on the SPI interface on our NXP >>ARMs; even high-level support people couldn't answer some fundamental >>timing/framing questions. The SPI and ADC documentation is awful. >> >>We use ARM chips that have 30-character pin names, the pin functions >>are so overloaded. > >I have been thinking 'ARM' quite a few times today, I planned on this feature to work... >I have some more data, for those who run into similar problems: >First in SPI master transmit mode, the least significant bit (bit 0) on SO is does not follow input. >Second SPI SI (input) does nothing and always reads some constant. >Tested at 16 MHz, and at 64 MHz. >The SSPSTAT, BF (transmission complete bit) never gets set, as if that last bit is never transmitted? > >The example from their own dataheet does not work: >LOOP > BTFSS SSPSTAT, BF ;Has data been received (transmit complete)? <------------------- gets never set. > BRA LOOP ;No > MOVF SSPBUF, W ;WREG reg = contents of SSPBUF > MOVWF spi_in ;Save in user RAM, if data is meaningful > MOVF spi_out, W ;W reg = contents of TXDATA > MOVWF SSPBUF ;New data to xmit > >So if you skip the test for SSPSTAT, BF, then it transmits 7 valid bits, and bit 8 always some fixed value, >also if you add huge delays between transmissions, so no collisions can cause this. >The device ID of this chip: 23 4f > > >>What would be nice would be if things like SPI were small RAM-driven >>microengines. Then the functionality would be in loadable code, not >>hard-wired silicon. Sort of like Motorola's TPU blocks. They could be >>repurposed, too. > >I dunno what you mean by RAM driven. I mean that all the sequencing logic is performed by microcode that's stored in a small user-loadable RAM. So the SPI interface becomes a separate programmable state machine, not hardwired logic. It would only become an SPI interface because it's loaded that way. >It is just a simple shift register, plus up to 8 counter, .... I they cannot do that in hardware then they have BIG problems. Well, they do. John
From: John Larkin on 7 May 2010 15:49 On Fri, 07 May 2010 14:16:26 -0400, Spehro Pefhany <speffSNIP(a)interlogDOTyou.knowwhat> wrote: >On Fri, 07 May 2010 09:27:35 -0700, John Larkin ><jjlarkin(a)highNOTlandTHIStechnologyPART.com> wrote: > >> >>That's pretty bad. But uPs are getting so complex, so overloaded with >>features, that the designers are sort of shoveling hunks of home-made >>or purchased IP into compilers and hoping for the best. And, >>apparently, not taking much time to simulate and verify. Or document! >>We had to do a bunch of experiments on the SPI interface on our NXP >>ARMs; even high-level support people couldn't answer some fundamental >>timing/framing questions. The SPI and ADC documentation is awful. >> >>We use ARM chips that have 30-character pin names, the pin functions >>are so overloaded. > >Who's are you using now? We're getting going with the Luminary parts. NXP 80 and 100-pin parts, LPC1758 and LPC1768. We have one 12-channel 4-20 mA thing that has an ARM per floating channel... 13 CPUs on one VME board. What we really want for another project is a faster (500 MHz?) chip with gigabit ethernet. NXP doesn't have anything quite yet. Marvell looks good technically but they sort of discourage sub-megapart customers. Freescale PowerPC looks pretty good. We'll have to decide soon. > >>What would be nice would be if things like SPI were small RAM-driven >>microengines. Then the functionality would be in loadable code, not >>hard-wired silicon. Sort of like Motorola's TPU blocks. They could be >>repurposed, too. >> >>John > >You'd think it would be relatively simple to put a thin FPGA or CPLD >fabric around the core, perhaps preloaded from ROM with some useful >defaults. That's what I had in mind, something preloaded but alterable. A simple microengine would do for most apps. John
From: nospam on 7 May 2010 16:37 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.
From: Nico Coesel on 7 May 2010 18:39 Spehro Pefhany <speffSNIP(a)interlogDOTyou.knowwhat> wrote: >On Fri, 07 May 2010 09:27:35 -0700, John Larkin ><jjlarkin(a)highNOTlandTHIStechnologyPART.com> wrote: > >> >>That's pretty bad. But uPs are getting so complex, so overloaded with >>features, that the designers are sort of shoveling hunks of home-made >>or purchased IP into compilers and hoping for the best. And, >>apparently, not taking much time to simulate and verify. Or document! >>We had to do a bunch of experiments on the SPI interface on our NXP >>ARMs; even high-level support people couldn't answer some fundamental >>timing/framing questions. The SPI and ADC documentation is awful. >> >>We use ARM chips that have 30-character pin names, the pin functions >>are so overloaded. > >Who's are you using now? We're getting going with the Luminary parts. > >>What would be nice would be if things like SPI were small RAM-driven >>microengines. Then the functionality would be in loadable code, not >>hard-wired silicon. Sort of like Motorola's TPU blocks. They could be >>repurposed, too. >> >>John > >You'd think it would be relatively simple to put a thin FPGA or CPLD >fabric around the core, perhaps preloaded from ROM with some useful >defaults. I mentioned something similar in comp.arch.fpga. Tell Xilinx to make such a device. If the price and the tooling (drag & click your microcontroller) are right they have a killer. -- Failure does not prove something is impossible, failure simply indicates you are not using the right tools... nico(a)nctdevpuntnl (punt=.) --------------------------------------------------------------
From: krw on 7 May 2010 18:57
On Fri, 07 May 2010 14:16:26 -0400, Spehro Pefhany <speffSNIP(a)interlogDOTyou.knowwhat> wrote: >On Fri, 07 May 2010 09:27:35 -0700, John Larkin ><jjlarkin(a)highNOTlandTHIStechnologyPART.com> wrote: > >> >>That's pretty bad. But uPs are getting so complex, so overloaded with >>features, that the designers are sort of shoveling hunks of home-made >>or purchased IP into compilers and hoping for the best. And, >>apparently, not taking much time to simulate and verify. Or document! >>We had to do a bunch of experiments on the SPI interface on our NXP >>ARMs; even high-level support people couldn't answer some fundamental >>timing/framing questions. The SPI and ADC documentation is awful. >> >>We use ARM chips that have 30-character pin names, the pin functions >>are so overloaded. > >Who's are you using now? We're getting going with the Luminary parts. > >>What would be nice would be if things like SPI were small RAM-driven >>microengines. Then the functionality would be in loadable code, not >>hard-wired silicon. Sort of like Motorola's TPU blocks. They could be >>repurposed, too. >> >>John > >You'd think it would be relatively simple to put a thin FPGA or CPLD >fabric around the core, perhaps preloaded from ROM with some useful >defaults. That's a lot easier said than done. First, X, A, and A have most of the IP locked up for FPGA sorts of things. Second, the development software for such things is non-trivial. Great idea, but not likely to fly. |