An other Microchip screwup on teh 18F14K22
in [Design]
|
From: krw on 11 May 2010 17:58 On Mon, 10 May 2010 21:31:00 -0700, "JosephKK"<quiettechblue(a)yahoo.com> wrote: >On Mon, 10 May 2010 17:30:21 -0500, "krw(a)att.bizzzzzzzzzzzz" ><krw(a)att.bizzzzzzzzzzzz> wrote: > >>On Mon, 10 May 2010 00:01:26 -0700, "JosephKK"<quiettechblue(a)yahoo.com> wrote: >> >>>On Sun, 09 May 2010 22:37:35 -0500, "krw(a)att.bizzzzzzzzzzzz" >>><krw(a)att.bizzzzzzzzzzzz> wrote: >>> >>>>On Sun, 09 May 2010 16:06:33 -0700, "JosephKK"<quiettechblue(a)yahoo.com> wrote: >>>> >>>>>On Fri, 07 May 2010 17:57:31 -0500, "krw(a)att.bizzzzzzzzzzzz" >>>>><krw(a)att.bizzzzzzzzzzzz> wrote: >>>>> >>>>>>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. >>>>> >>>>>PALs and small FPGAs have been around over 30 years. If you limit to not >>>>>much more tech, all the patents should be expired. >>>> >>>>A lot of the simple stuff, sure. Not sure about all the RAM and other special >>>>functions. >>>> >>>>>Atmel, Freescale, >>>>>Microchip, etc., all have nice multiplexing tech for the multifunction >>>>>pins. >>>> >>>>How does this apply? >>> >>>The underlying idea of using some programmable logic rather than Special >>>Function registers to select or even perform the various pin functions. >>>It could even be in a separate program space. This could really help >>>with all of the various serial busses that are popular now. >> >>I don't see how Muxes are all that big of a deal, particularly after you have >>FPGA fabric connected to the I/O. > >To maintain any analog capability it would have to be at least one >transmission gate (analog switch) remove. So what? Pass gate logic is quite normal. In fact, FPGAs would be impossible without them (that's how routing is done). >>>It may even allow better allocation of ADC/DAC I/O. >> >>Some have routable analogs, most restrict the pins these functions are on very >>tightly. > >The CPLD layer could allow lesser restrictions, which may then allow more >convenient routing of the board. Nonsense. The limitations on analog routing is a matter of noise, cost, and utility. |