Mark Borgerson wrote:> In article <c127eu$r7e$1$830fa7a5@news.demon.co.uk>, > martin_underscore_walton_a@t_flyingpig_full.stop_com says... >--- clip clip ---> I don't know if they'll really take off until there is a good Windows- > based C compiler for under $500. Not all embedded engineers have the > time to set up a Linux system and get a GNU toolchain running.The GNU toolchain works prefectly well under Cygwin in a Windows environment. I built my first ARM7TDMI toolchain from GNU sources in Cygwin (in a NT4 computer). The tools should also work with Mingw (minimal GNU for Windows). I have not tried it, however. Tauno Voipio tauno voipio @ iki fi
arm7 atmel vs others
Started by ●February 14, 2004
Reply by ●February 19, 20042004-02-19
Reply by ●February 19, 20042004-02-19
CBFalconer wrote:> > rickman wrote: > > CBFalconer wrote: > > > Ville Voipio wrote: > > > > rickman <spamgoeshere4@yahoo.com> writes: > > > > > > > > > Are you saying that the ARM7 chips have floating point? > > > > > > > > In ARM7TDMI the "M" stands for multiply. It is a 32x32->64 > > > > multiplication, takes only a few machine cycles. Making such a beast > > > > with a 8x8->16 multiplication (as in MSP430/AVR/PIC) would take > > > > 16 multiplications and a big bunch of 8-bit additions. Slooooooow. > > > > > > No, it takes 9 with a few adds and at least one subtraction. I > > > forget the details, but it is in Knuth. It involves a suitable > > > factoring of (a + b) * (c + d). > > > > Does the ARM7TDMI have a 64 bit barrel shifter? If not, the slow part > > of a floating point operation is the normalization. > > Only for addition and subtraction. The results of multiplication > and division normally require at most 2 shifts to normalize.Yes, but the lack of a barrel shifter is still more significant than the lack of a 32x32 multiply. Shifting by one bit is very time consuming. It is not relevant whether it is in the adds or the multiplies. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAX
Reply by ●February 19, 20042004-02-19
Mark Borgerson wrote:> > In article <403440B8.306EE54B@yahoo.com>, spamgoeshere4@yahoo.com > says... > > Mark Borgerson wrote: > > > > > > They seem to be a nice fit for some ideas I have for sensors with > > > reasonably complex data processing. My last ARM project collected > > > a lot of data from various sensors, and did a bunch of statistics, > > > (medians, percentiles, std. deviations, even some FFT-related > > > calculations) before storing the data in serial flash memory. I need > > > FP calculation speed and RAM size that I couldn't find in an MSP430 or > > > most 8-bit processors. The hardware-assisted serial ports on the > > > AT91R40807 were also quite handy, but I could probably do without them > > > if I switched to one of the LPC210X chips. > > > > Are you saying that the ARM7 chips have floating point? I was not aware > > of that. Or are you saying that they will emulate floating point much > > better than the 8 bitters? I believe some of the 8 bit chips have > > hardware multiply, 8x8 in the MSP430, IIRC. > > No, they don't have an FPU. (at least the ones I used) The advantage in > doing standard 32-bit loating point calculations comes from the internal > 32-bit egisters. The ARM DM versions also have 32x32 multiplies and > the ability to do efficient shifts and rotates on 32-bit words. That > all adds up to running software FP quite a bit faster than 8 or > 16-bit processors---even those with hardware multiply instructions. > > Some VERY rough benchmarks I ran showed that an ARM 7 at 10Mhz had > about twice the FP performance of a 68332 at 16Mhz. Of course, the > ARM was running from internal 32-bit RAM and the 68332 used external > 16-bit RAM. > > > > I am not saying there are NO applications that would benifit from the > > LPC20xx chips. But it just seems like everyone is facinated with them > > when they only fit a niche really. Are these 32 pin MCUs really that > > much more versitile than any other device? > > > > I would describe the MSP430 as more versatile, but the ARM7 as more > powerful for complex data processing. That is particularly true > if you want to work with more than 2KBytes of data at a time.Yes, that is true. But there are few apps that need complex data processing, but not much ram. I am not saying there are not *any*, just not very many. In the same way, i would love to see an FPGA in a small package, like a 48 pin TQFP. But there are few apps for this sort of part and so they don't make them. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAX
Reply by ●February 19, 20042004-02-19
rickman <spamgoeshere4@yahoo.com> writes:> Does the ARM7TDMI have a 64 bit barrel shifter? If not, the slow part > of a floating point operation is the normalization.No such thing. However, as long as the floating point is single precision fp, there is no real need for a 64-bit barrel shifter. Multiplications require very little shifting (two positions at max), so even the clumsy carry shifting works. Adding and subtracting requires more shifting, but still there is only 24 bits of data, so everything fits in the 32 bits. With longer numbers the barrel shifter can be used piecewise, even though then a temporary register is required. The following pseudo- code shifts a double word (32+32=64 bits) r16:r15 by n bits using the barrel shifter r0 = r15 shr (32 - n) r15 = r15 shl n r16 = r16 shl n r16 = r16 or r15 I guess it is more difficult to find out how much to shift (especially in subtractions which lose a lot of bits). Of course, this is not as elegant as a real 64-bit barrel shifter, but bot very slow, either. - Ville -- Ville Voipio, Dr.Tech., M.Sc. (EE)
Reply by ●February 19, 20042004-02-19
Ville Voipio <vvoipio@kosh.hut.fi> writes:> With longer numbers the barrel shifter can be used piecewise, > even though then a temporary register is required. The following pseudo- > code shifts a double word (32+32=64 bits) r16:r15 by n bits using the > barrel shifter > > r0 = r15 shr (32 - n) > r15 = r15 shl n > r16 = r16 shl n > r16 = r16 or r15Ooops. The last row must be: r16 = r16 or r0 Maybe it's now better. - Ville -- Ville Voipio, Dr.Tech., M.Sc. (EE)
Reply by ●February 19, 20042004-02-19
On Thu, 19 Feb 2004 13:24:30 -0500, rickman <spamgoeshere4@yahoo.com> wrote:>Yes, but the lack of a barrel shifter is still more significant than the >lack of a 32x32 multiply. Shifting by one bit is very time consuming. >It is not relevant whether it is in the adds or the multiplies.In achitecture v5 use the CLZ (count leading zeros) instruction, which reduces most normalisation to two instructions. No help for v4, but if you need FP, you probably a need a fast CPU, and there are many v5 CPUs around. Stephen -- Stephen Pelc, stephenXXX@INVALID.mpeltd.demon.co.uk MicroProcessor Engineering Ltd - More Real, Less Time 133 Hill Lane, Southampton SO15 5AF, England tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691 web: http://www.mpeltd.demon.co.uk - free VFX Forth downloads
Reply by ●February 19, 20042004-02-19
Jukka Marin wrote: <snip>> Yes, it seems the pin is always an open drain output. :-I English is not > my native language, so I may be misreading the datasheet, but to me it > looks like the pin should be open drain in I�C mode only.One feature of i2c, is that (ideally) off devices should not clamp the BUS, so it may be that is a deliberate feature ? -jg
Reply by ●February 19, 20042004-02-19
"Mark Borgerson" <m-a-r-k@oes.to> escribi� en el mensaje news:MPG.1a9e9c5cda134fa3989da6@Netnews.Comcast.net...> I don't know if they'll really take off until there is a good Windows- > based C compiler for under $500. Not all embedded engineers have the > time to set up a Linux system and get a GNU toolchain running.http://gnuarm.com For much less than US$500, in a comfortable installer ;^) Regards.
Reply by ●February 19, 20042004-02-19
In article <MPG.1a9e9c5cda134fa3989da6@Netnews.Comcast.net>, Mark> >IMHO, a good LPC2104 demo board and fully capable C compiler for >under $400 would sell like hotcakes in the Digi-Key catalog.The Keil LPC2100 board is around 150 USD /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\ /\/\/ chris@phaedsys.org www.phaedsys.org \/\/ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Reply by ●February 19, 20042004-02-19
In article <4034FFFE.E47E4D0A@yahoo.com>, spamgoeshere4@yahoo.com says...> Mark Borgerson wrote: > > > > In article <403440B8.306EE54B@yahoo.com>, spamgoeshere4@yahoo.com > > says... > > > Mark Borgerson wrote: > > > > > > > > They seem to be a nice fit for some ideas I have for sensors with > > > > reasonably complex data processing. My last ARM project collected > > > > a lot of data from various sensors, and did a bunch of statistics, > > > > (medians, percentiles, std. deviations, even some FFT-related > > > > calculations) before storing the data in serial flash memory. I need > > > > FP calculation speed and RAM size that I couldn't find in an MSP430 or > > > > most 8-bit processors. The hardware-assisted serial ports on the > > > > AT91R40807 were also quite handy, but I could probably do without them > > > > if I switched to one of the LPC210X chips. > > > > > > Are you saying that the ARM7 chips have floating point? I was not aware > > > of that. Or are you saying that they will emulate floating point much > > > better than the 8 bitters? I believe some of the 8 bit chips have > > > hardware multiply, 8x8 in the MSP430, IIRC. > > > > No, they don't have an FPU. (at least the ones I used) The advantage in > > doing standard 32-bit loating point calculations comes from the internal > > 32-bit egisters. The ARM DM versions also have 32x32 multiplies and > > the ability to do efficient shifts and rotates on 32-bit words. That > > all adds up to running software FP quite a bit faster than 8 or > > 16-bit processors---even those with hardware multiply instructions. > > > > Some VERY rough benchmarks I ran showed that an ARM 7 at 10Mhz had > > about twice the FP performance of a 68332 at 16Mhz. Of course, the > > ARM was running from internal 32-bit RAM and the 68332 used external > > 16-bit RAM. > > > > > > I am not saying there are NO applications that would benifit from the > > > LPC20xx chips. But it just seems like everyone is facinated with them > > > when they only fit a niche really. Are these 32 pin MCUs really that > > > much more versitile than any other device? > > > > > > > I would describe the MSP430 as more versatile, but the ARM7 as more > > powerful for complex data processing. That is particularly true > > if you want to work with more than 2KBytes of data at a time. > > Yes, that is true. But there are few apps that need complex data > processing, but not much ram. I am not saying there are not *any*, just > not very many. In the same way, i would love to see an FPGA in a small > package, like a 48 pin TQFP. But there are few apps for this sort of > part and so they don't make them.I do a lot of designs for scientific instruments where some data processing is done before storage, so I guess I see more need for floating point and large data arrays than does the guy designing the controller for a toaster oven. ;-) I guess the FPGA would be nice, but I'm still working on 64-register CPLDs! One of those in a 44-pin QFP sure does beat a handful of LCX chips both in flexibility of design and ease of PCB layout and assembly. At my product quantities (100's per year), an extra 50 cents in part cost is less important that saving some design time, adding flexibility, and simplifying assembly. Mark Borgerson> >
