MICROCHIP to get hand on ATMEL ?

octal · Post by **octal** » Fri Oct 17, 2008 9:19 pm

http://www.thestreet.com/story/10440351 ... uc=_tscrss

http://www.design-reuse.com/news/19226/ ... atmel.html

regards
octal

Doj · Post by **Doj** » Fri Oct 17, 2008 10:26 pm

If this old news impresses you wait till you hear about the new 16F Core!!!

TimB · Post by **TimB** » Fri Oct 17, 2008 11:16 pm

Doj

When are they going to announce it?

octal · Post by **octal** » Sat Oct 18, 2008 8:44 am

Doj wrote:If this old news impresses you wait till you hear about the new 16F Core!!!

It's not that impressive. Just wanted to post in case someone has heard about any details.

As for the 16F serie, I think it's an UGLY architecture, and it will remain ugly!
We cannot enhance an ugly core (my personal opinion of course).
For me, the 18F serie is one of the best series especially for to be used with high level language.
The enhancements to the 16F series will never make it at the same quality of the 18F serie, and the 18F serie now costs about the same as the 16F serie. Personally I'll never go for a 16F for a commercial product unless I cannot find any equivalent in 18F version (12bit core or 14bit low pin devices).
With the enhancement to the 16F serie, Microchip tries to move the 16F serie to the same level as 18F serie. Really a continious fiddling (a lot of limitations will still exists like as banking).
To see and compare them to a clean architecture, try to see the ARM-CORTEX based serie of microcontrollers made by Luminary. They costs less than 1 $US per unit, have a higher speed (50 MHz is a std), and have a lot more peripherals, with a 32 Bit core, and a very clean architecture (No banking, fully flat memory model, very clean assembler, software stack, vectored interrupts, ....)!!!

For users who would be interrested, for reference, here is the new enhancement that we "probably" would have in the new 16F enhanced core (from an unofficial source - Microchip did not communicated about that, just two guys from Micrcohip gave some info on mailing lists)

1) Increase the maximum program memory: can address up to 32K (vs 8K of PIC16)

2) Increase the maximum data memory

3) Increase of hardware stack level to 16.

4) Reduce the penalty for paging/banking
- by introducing new BSR register. Hence the old PR0/PR1 is no more exist.
- by introducing new MOVLP instruction.

5) Automatic ISR context saving for W, STATUS, BSR, FSR0, FSR1, PCLATH.

6) Has 2 indirect RAM accesses through INDF0 and INDF1. Support pre/post increment/decrement.

7) Relative branch (signed and unsigned offset).

Stack over/underflow cause Reset.

9) Stack can be accessed via SPTR and TOS.

10) RESET instruction.

11) Some advanced arithmetic instruction - some already exist in PIC18, some are NOT.

12) Enhanced program memory read. Device ID, user ID and configuration word are now readable by the firmware.

The only good news I can personally see from these enhancement is that we could have (maybe easily) a port of Swordfish Basic for this serie of 16F core

Regards
octal

Doj · Post by **Doj** » Sat Oct 18, 2008 12:26 pm

The data sheets are to be released(officially) at Electronica on Nov11.
As we are showing off I had lunch with the team leader of the new core a couple of weeks ago and he was very happy with the new babies!.

Couple of other bits not mentioned by octal:-
3.6v core with fully tolerant 5v I/O.
6 Timers.
Enhanced PWM with idependent duty cycles and frequency.
13 new instruction in total to increase C compatibility.
Will run at 32MHz at 2v supply.
Up to 32MHz on internal oscilator.
All code is backwards compatible if new instructions not used.
The bank switching is supposed to be far better.
New four part numbering system for easy distinction between cores.

You can not say they do not listen to users wishes, and obviously the new core is on a smaller process which is less costly to produce and allows smaller die size and smaller packaging and greater yield.

The vast majority of parts sold these days are 3v so the old 5v stuff will have to give way soon.

Then there are the new 18K parts.....

Toley · Post by **Toley** » Sat Oct 18, 2008 11:20 pm

Wow those new little 16F seems very impressive.

...I had lunch with the team leader of the new core a couple of weeks ago...

You look very close to those guys Doj, maybe you will have access to pre production samples. Anyway you will see the datasheet on nov 11, and give us your opinion on nov 12

.

At least Atmel's fans will stop saying that AVR are much more powerfull than PICs (cause they always compare ATMega to PIC16F...).

Doj · Post by **Doj** » Sun Oct 19, 2008 1:53 am

Hello Toley, the E versions of all chips are always interesting but are only a part of the process that eventually ends up with the production parts.
Many users are party to these tests.

Atmels(8051) have their charms but comparing direct to PICs is a bit silly as the architecture is quite different, Harvard(PIC) is arguably more efficient as there are separate pipelines for memory allowing faster system operation even though the clock speed is much lower.
There is a BASIC compiler that I have used with ATMEL stuff and other 8051 based chips, BASCOM, very good and perfectly usable.
Not a patch on SF, but SF does stand head and shoulders above others from a usage point of view

One thing that I learned at our meeting was the history of where the PIC micro design first came, it was amazing, Scotland, the original PONG game and many twists and turns!
Best lunch I had in a long time!!!

Had to edit this Toley, I may be in the Burlington area of VT for some time in the next month or so, are you anywhere near the NY/VT border?

Doj · Post by **Doj** » Sun Oct 19, 2008 2:14 am

MMMM, holy s**t, Canada is one big country,what an amazing place!!!!!!!!!!!!!!!!!!!! makes me wonder how we managed to produce so many people who wanted to eliminate all the indigenous peoples in all the world, there has to be a really good reason why some parts were left to the french....

octal · Post by **octal** » Mon Oct 20, 2008 8:27 am

Toley wrote: ...
At least Atmel's fans will stop saying that AVR are much more powerfull than PICs (cause they always compare ATMega to PIC16F...).

I don't want to dive in PIC vs Atmel comparison, but it's a reality. if we compare even first atmels vs first PICs (before the 18F series), atmel AVR architecture is really cleaner than PIC one.
- Vectored interrupts,
- Flat memory model (no banking)
- Software Stack management,
- True indexing and indirect access via 2 (or 3 dont remember - X and Y and maybe Z register .. dont remember very well) specialized registers
- ...
and the instructions are executed in one cycle compared to the 4 cycles for PIC.

I'm not an atmel fan at all!!! but we must say the truth:
as a RISC and Harvard architectured device, ATMEL serie's programmers model is really cleaner! No cheating (no bank switching with the stupid bits to set/clear in a stupid register). There are also some drawback and some strange choices done by atmel for some instructions (as in any chip and any architecture)... but the device architecture is cleaner than PIC one, and is more suitable for compilers writing.

Microchip did a nice job in PIC18 series, but again the result is not that clean. Compare the PIC18 to ATMEGA equivalent devices and you'll see what I mean. (I'm not speaking about integrated devices ... like ports or converters ... I'm speaking about the architecture !!!).

And as last word, do not forgot that most (almost) all comparison I have found on the web were done by peoples with a lot of experience, and most of them were already exposed for more than 5 years to architectures like 8051 one (Intel) or Z80 (Zilog), or X86 architecture (ugly segmented one before protected mode was invented). For these peoples, the chocie of best architecture is definitely biased by their experience, and in that Atmel architecture, despite the fact that it's a harvard one, is closer to what they had in old chips (vectored int and flat memory model) than PIC one, so their preference to Atmel is an obvious decision!!!!

Regards
octal

rmteo · Post by **rmteo** » Mon Oct 20, 2008 2:28 pm

This is the reason (vectored int, flat memory model - and PPS) why I am patiently waiting for SF to support the PIC24F/H and dsPIC. In my opinion, SF is still the best compiler fo rPICs.