another bizarre architecture
in [Embedded]
|
From: Paul E. Schoen on 31 Jan 2007 14:45 "John Larkin" <jjlarkin(a)highNOTlandTHIStechnologyPART.com> wrote in message news:vap1s2ttifuhnct6n0101qvn1uhn504jpc(a)4ax.com... > This looks really weird to me... > > http://www.maxim-ic.com/appnotes.cfm/appnote_number/3960 > > Does it resemble anything you've ever seen? It looks truly ghastly to > program. For example, allowing printf() to use floats adds 3500 bytes > to a program binary. > > John > This is a lot different than the PIC code I am used to. However, there must be some advantage to it. I don't see where you get your reference to the printf() function, however. That would be a function of a C compiler. Paul
From: Mike Harrison on 31 Jan 2007 14:47 On 31 Jan 2007 11:06:49 -0800, "larwe" <zwsdotcom(a)gmail.com> wrote: >On Jan 31, 2:03 pm, John Larkin ><jjlar...(a)highNOTlandTHIStechnologyPART.com> wrote: >> This looks really weird to me... >> >> http://www.maxim-ic.com/appnotes.cfm/appnote_number/3960 > >MAXQ is aimed at very low power consumption applications. They have >been trying desperately to sell it to us. Unfortunately for any real >project we've considered, MSP430 is indistinguishable from MAXQ power- >wise. We have a lot of investment in ARM, AVR and MSP430; MAXQ is just >"yet another proprietary microcontroller" with no really compelling >feature. No sale. And it's from Maxim.... usually a distinct disadvantage, availabilitywise
From: Rich Grise on 31 Jan 2007 14:49 On Wed, 31 Jan 2007 11:03:03 -0800, John Larkin wrote: > This looks really weird to me... > > http://www.maxim-ic.com/appnotes.cfm/appnote_number/3960 > > Does it resemble anything you've ever seen? It looks truly ghastly to > program. For example, allowing printf() to use floats adds 3500 bytes > to a program binary. > Yes, it does resemble something I've seen - microcode. ;-) It actually looks like something I'd enjoy playing with. :-) And yes, I'd expect a printf() to use that many bytes - printf() is a freakin' monstrosity in any case. What does puts() compile to? I'd think it wouldn't take a very big loop to turn a float into a string. Cheers! Rich
From: larwe on 31 Jan 2007 15:01 On Jan 31, 2:16 pm, Vladimir Vassilevsky <antispam_bo...(a)hotmail.com> wrote: > John Larkin wrote: > > This looks really weird to me... > > >http://www.maxim-ic.com/appnotes.cfm/appnote_number/3960 > > > Does it resemble anything you've ever seen? > > Just another small 16-bitter. From Maxim, which sounds like never use it. > > It looks truly ghastly to > > > program. > > Coding at low level is a task of compiler. BTW, do they provide decent > tools for MAXQ? Rowley and IAR have C compilers - I've played with the IAR one and it seems to be exactly like their other compilers with no obvious problem. Also Phyton (but I never heard of them before). Maxim supplies a free IDE with assembler. Very standard sort of arrangement. >> For example, allowing printf() to use floats adds 3500 bytes >> to a program binary. > > I'd say this is not unusual for the printf() overhead. Agreed, very standard.
From: Jim Granville on 31 Jan 2007 15:37
John Larkin wrote: > This looks really weird to me... > > http://www.maxim-ic.com/appnotes.cfm/appnote_number/3960 > > Does it resemble anything you've ever seen? It looks truly ghastly to > program. For example, allowing printf() to use floats adds 3500 bytes > to a program binary. They have one of the strangest ways of documenting opcodes I have seen, which I think makes it looks stranger that it really is. It does mean users have a learning curve to climb, unless you want to operate purely, and only, in C - which places its own restrictions on what you can do. They claim low power, but the MAXQ2000 has a very poor mA/MHz offset, - yes, it's OK at 20MHz, but only drops Icc a few %, as the clock drops to 1MHz - so at lower clocks, it quickly looks plain lousy. Hard to believe someone pitching a low power uC, would make that mistake. They seem to be targeting the DataACQ markets, so the core specs matter less than the peripherals - eg there are (very) few uC offering 16 bit ADCs + LCD + 16*16 to 40 bit MAC, so if you really need those features, the core will be a "don't care". As a general mechant uC ?, nope... -jg |