An other Microchip screwup on teh 18F14K22

an ENC28J60 Ethernet cotroller,

SPI.

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.

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

Who's are you using now? We're getting going with the Luminary parts.

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.

On a sunny day (Fri, 07 May 2010 09:27:35 -0700) it happened John Larkin wrote in :

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)? What would be nice would be if things like SPI were small RAM-driven

I dunno what you mean by RAM driven. It is just a simple shift register, plus up to 8 counter, .... I they cannot do that in hardware then they have BIG problems.

On a sunny day (Fri, 07 May 2010 14:16:26 -0400) it happened Spehro Pefhany wrote in :

Oh, yes, like the Xilinx shift registers.... patents, patents, patents.

to work...

does not follow input.

is never transmitted?

BRA LOOP ;No

bit 8 always some fixed value,

this.

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.

that in hardware then they have BIG problems.

Well, they do.

John

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.

That's what I had in mind, something preloaded but alterable. A simple microengine would do for most apps.

John

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.

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@nctdevpuntnl (punt=.)
--------------------------------------------------------------

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.

to an ENC28J60 Ethernet cotroller,

SPI.

asm...

The problem is that SPI is so poorly defined that there have to be a gazillion options to get it to do anything. Verification of every combination of register settings gets to be a problem, quickly.

When I build the library parts I reduce the pin names to the function I'm actually using.

Would be nice, but while I like SPI (I2C is a PITA), it's not likely to happen.

an ENC28J60 Ethernet cotroller,

SPI.

If you think that's bad, don't go anywhere near the TI 5509 DSP. The DMA controller usually works but sometimes skips an operation, causing the I/O controllers to get out of sync. Since I2S multiplexes data on the serial link, data ends up a channel off and there is no way to know that it even happened. We had to take a codec output and wrap it back to an input, and put a tone on it as an expected result to figure out when the DMA controller got out of sync.

We won't even discuss the "McBSP". They've told us the 5504/5/15 actually works. We'll see.

A Spartan fpga with a (or several) hard ARM cores on board would be great. Except that decent ARMs cost $4, and little ones cost under $1.

The soft cores are too expensive in FPGA resources and tend to be slow.

John

Actel has a hard ARM core in their new SpartFusion line. Analogs too. IIRC the prices start in the mid single digits for 5K/year sorts of quantities.

Depends on what you want to do. About 1k LUTs gets a pretty decent controller. No FP, of course.

Just had found a bug in the 18f4420, depending upon which sfr you load from to the MSSP buffer, it will either not initiate a SPI transfer or it will. But the default code generation of the MC18 compiler causes no transfer if you use a passed variable. Copy it to a local variable in the function, then write the sspbuff and it generates the correct movf sspbuff, w Yet the documentation offers little insight, other than the sample asm code.

Cheers

Keith,

Do you know if TI ever officially documented this somewhere?

We're using 5507s, and to date we haven't run into that particular problem. (Heck, we were even lucky in that TI sent us an errata sheet detailing how the ADC of theirs we're using could get into a weird configuration and completely lock up and die until power was cycled... but it turned out we weren't using it in a mode that could provoke the bug.)

---Joel

Not that problem, to my knowledge. They admit to the DMA dropping data if it gets too busy (they originally blamed it on the way we were using the McBSP); "don't do that". It's a lot more insidious than what they claimed, though. Sure, you'll see it more when the DMA controller is heavily loaded, because it's doing more DMA, but it does it anyway. It wouldn't have been a major issue for us if there was some way of knowing that the thing was out of sync, but there isn't. I can almost understand DMA dropping a cycle here or there (1 in 1E11, perhaps) but to have no way to tell that the whole I/O subsystem is out of sync is incredible.

They promise that they'll be better partners now. They keep showing up (the whole staff, I think) telling us how good it'll be next time. We got a couple of 5504/5/15 development kits out of them, though.

Xilinx have just announced a hard ARM core (800MHz dual core Cortex M9, roughly Intel Atom class) with what I imagine will be a metric cr*pload of FPGA in 28nm for some time next year or so. Eventually it will filter down to the microcontrollers, but I agree with what you say, in general. Your first point is likely why it's coming from an FPGA company that licensed an ARM core and fiddled the bus to work rather than a traditional microprocessor/microcontroller supplier. And, come to think of it, the second point as well, since gcc takes care of much of the compiler development.

Best regards, Spehro Pefhany

--
"it's the network..."                          "The Journey is the reward"
speff@interlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com

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.

Best regards, Spehro Pefhany

--
"it's the network..."                          "The Journey is the reward"
speff@interlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com

How so? The name reflects its purpose _in_the_design_. He doesn't care what the pin is able to do.