ARM uC/uP with MMU and FPU?

Hi Mike,

Check out the EP3902/ EP3901 from Cirrus logic. It might fit your requirements. Link to EP3902

-- rAm

That part looks pretty good - except that it does not have CAN. I guess I can always use a CAN controller like the Microchip MCP2515 - but I would prefer to find a chip with it already integrated.

-Mike

ganti.r wrote:

The only ones I can think of which has FPU is NXP and Freescale iMX31 which both are in BGA, so you are basically screwed. You will get most peripheral things in the AT91SAM9263, except the FPU, again in BGA.

Best non-BGA AT91 is the AT91SAM9260 in TQFP. No FPU, no CAN, no ADC.

Hi Ulf - thanks for the response. Neither of those seems a good fit to me. Right now I'm thinking I'll be going with the Cirrus part - but I really don't like the idea of having to use a separate CAN controller. What a nuisance. I also quite dislike having to switch manufacturers - I expect my AT91SAM-ICE won't work with the Cirrus parts... I hope Atmel has something in the works that could meet my specs - but from what I've heard, you all don't.

Two (unrelated) questions you: Do you know anything about when the ATtiny861 is going to start being available through normal distribution channels? As far as I know - you can only get them in limited quantities from distributors right now.

Also, do you know if there are any other CAN AVRs in the works? The AT90CAN128/64/32 chips are physically too big for me to use on my current boards (even in the QFN package, as you can't route traces beneath the ground pad). I keep on hoping Atmel will release a AT90CAN168 chip (ATMEGA168 with CAN). I think there's a real market for such a device. I know I'd have plenty of uses for such a chip.

Thanks,

-Mike

No, it will detect the manufacturer and refuse, my idea to start with , so blame me ;-)

We got a 1 GFlops Floating Point DSP in Diopsis AT572D740, but this has an ARM7 and not an ARM9.

Next year.

AT89C51CCxx ?

Ohhhhhh - in that case - I have a bone to pick with you. Initially, I was using engineering sample SAM7X256 chips on my boards. Later, I switched to normal production models - but suddenly after making that switch - I could no longer program the boards. I tried and tried - and every time it would tell me that the chip was not made by Atmel.

I thought it was a bad SAMICE so I got a new one. It wasn't. I thought the board might be bad so I resoldered it. That didn't fix it. I thought the chip might be bad so I replaced it. That didn't fix it. I spoke with IAR - and they didn't have a clue what was wrong. I spoke with an Atmel FAE - he also did not know what was wrong. I reinstalled both the Segger drivers and IAR. Still didn't fix it. Finally, I got a hold of somebody at Segger, who immediately told me what was wrong. I guess each run of chips or something has a unique id placed in it - and then the sam-ice drivers have a list of ids that work. Apparently engineering sample and production run chips have different ids - and my drivers were old enough (installed when I started working on the SAM7X

- so maybe 4 months old) that they only had engineering sample ids. The fix was to copy some drivers from the Segger folder to the IAR folder. I lost about a week due to that nonsense. I don't know what the purpose of that feature was - but let's just say I'm not a fan.

BGA :(

I've looked at those parts - but I'd really like to stick with AVRs as I am quite fond of AVR-GCC.

-Mike

Atmel can sell low price H/W and Segger should be able to get some money if you upgrade to a driver which unlocks the part. Obviously, your FAE contact should have known this, and your problem would have gone away quickly. I always tell customers about this limitation when I present the SAM-ICE:

That problem will go away Q2 next year (I hope).

No luck at this point then.