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). -- Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net) Available for consulting/temporary embedded and systems. <http://cbfalconer.home.att.net> USE worldnet address!
arm7 atmel vs others
Started by ●February 14, 2004
Reply by ●February 19, 20042004-02-19
Reply by ●February 19, 20042004-02-19
On 2004-02-18, rickman <spamgoeshere4@yahoo.com> wrote:> Yes, the Philips LPC210x parts are very small. But I am not sure why > you need a 32 bit processor if you only need to control some GPIO or SIO > ports. Of course you could say, why not? with the incredibly small > price difference to an 8 bit processor. But the Philips parts are > currently just too limited for my designs.Well, I can run our RTOS with all the services it provides on LPC210x, but I can't do that on PIC or even HC12 (we only support non-banked memory for now and it seems there's little or no reason to change that). Also, I like writing software for a decent 32-bit chip with "lots" of memory much better than working with limited 8-bit chips and optimizing the code using assembly language.>> I was talking about the peripheral features. For example, if you put a >> pin on the LPC210x in CAPture mode, it seems you can't read the pin >> state any longer. We have been using input capture on both edges and >> when an edge arrives, checked the pin state - this works on Motorola >> chips (HC11, HC12, MCore etc.) but not on the Philips chips. Now that >> you know it, it kinda makes sense - if a pin is connected to the CAPture >> logic, it is disconnected from GPIO - but I still think it's pretty dumb. > > Unless you know the input does not change very fast, this could produce > errors. But yes, I agree that it seems odd that you can't read the > pin. I'm not sure how the OKI parts work in this case.The input transients are the reason why we _need_ to be able to read the pin state. If we set the compare logic to detect a rising OR a falling edge and then have an input glitch shorter than our interrupt latency time, we will no longer know what the actual pin state is and we may program the compare logic to wait for the wrong edge. On Motorola chips, we always get an interrupt on both edges and then check for the pin state. If there was a glitch, shorter than our interrupt latency, we will see the pin is still in the "old" state and simply ignore the irq. If we can't poll the input state, we don't know whether this was a "real" edge or a glitch we should ignore.>> Also, the I�C pins of LPC210x seem to be in open drain mode even when >> configured as MAT/CAP pins - despite of the fact that the data sheet >> only mentions "open drain" for I�C mode. Of course, we didn't expect >> this, so our design has no pullup on the MAT output.. nothing like this >> has ever hit us with Motorola parts. > > I'm not familiar with MAT/CAP. How about when it is a GPIO, is it only > open drain?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.>> We are seeing some problems with the SPI, as well - but we don't know >> what's going on for sure. It just seems that SPI doesn't want to start >> up in master mode if we want to use the SS pin as GPIO (we ran out of >> pins, see ;-)I think we know what is going on, now. If we try using the SS pin for GPIO, it might be that the SPI logic has the SS input pin (inside the chip) floating which causes SPI collisions. The Motorola engineers knew better - the SS pin was available as GPIO if it was needed for the SPI operation.>> Umm.. "support from the vendor".. Is there such a thing for the Philips >> chips? :-) > > I belive there is both support from the vendor and there seems to be a > large and growing grassroots user base.Do you know a contact at Philips? I'd like to get a confirmation for the things mentioned above. It seems we'll stop trying to use SPI and do it in software, so we don't have to modify the hardware (which is waiting to be delivered to a client).> Heck, the Philips and OKI parts are already as cheap if not cheaper than > a lot of the PICs that have much less capabilities.And the PICs are _weird_. I hate them. And I still keep designing them into new projects. I am weird. :-) -jm
Reply by ●February 19, 20042004-02-19
"Ulf Samuelsson" <ulf@atmel.nospam.com> writes:> Hmm, I thought it was an 16 x 16 => 32...Which one? AFAIK, ARM UMLAL et al. commands do make a 32x32 => 64. There are some severe register limitations, and shifting the result has to be done bitwise through carry. However, for fixed point fractional arithmetics the commands are just fine (rounding can be made with the accumulate part). The AVR multiplication is 8x8 => 16, but yes, MSP430 may have 16x16 => 32, if that is what you meant. - Ville -- Ville Voipio, Dr.Tech., M.Sc. (EE)
Reply by ●February 19, 20042004-02-19
CBFalconer <cbfalconer@yahoo.com> writes:> 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).Karashiba (or something) algorithm? It should really work with nine multiplications, but IIRC it requires full 8-bit subtractions. This requires some work with the carry bit and absolute values, as otherwise some information is bound to disappear. Unless the processor handles this in hw, some manual branching is required.. With large multiplications the algorithm is far superior to the basic (elementary school) multiplication. If my memory serves, If my memory serves, its complexity goes as O(n^1.6) whereas the basic one is clearly O(n^2). However, with shortish numbers, the overhead may overtake the advange, again depending on the architecture. (No, I did not bother to write the code for any real processor, so this is just theoretical babbling :) It may really be more economical on an AVR/PIC, but the difference is not very big. - Ville -- Ville Voipio, Dr.Tech., M.Sc. (EE)
Reply by ●February 19, 20042004-02-19
Martin Walton wrote:> > Heck, the Philips and OKI parts are already as cheap if not cheaper than > a lot of the PICs that have much less capabilities. > > //------------------- > > As someone who uses PIC/AVR/8051 on a regular basis, the Philips and OKI > parts are really attractive, however getting hold of them easily is a > real issue at present. Most of the projects I work on involve small > quantities (ie. a couple hundred), and as a result, I tend to be pretty > low priority to the distribution companies. Component availability is > therefore a prime consideration when choosing parts.Have you tried to buy any of the OKI parts? I checked the other day and found stock on several versions of both the ML67Q400x and the ML67Q500x. Try Nuhorizons and www.freetradezone.com.> I can buy PICs or 8051 from a large number of sources in the UK in any > quantity, without any hassle. If I can't buy the exact part, chances > are a similar version is available which is pin and code compatible. > AVR is a little more difficult, especially if you want access to the > full range, but if I can't get them locally, then Digikey give me > excellent service.Oh, UK. I don't know anything about how these parts are vended in the UK. But shouldn't Philips have a good distribution chain there?> We have looked at the Philips range and have a dev board which we have > been using to evaluate various tool chains, and from a technical > standpoint, I'm really like it (apart from the lack of code protection). > > I think Philips need to get this range into the catalogue suppliers like > Farnell and Digikey, at which point it should really take off.-- 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
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. -- 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
Jukka Marin wrote:> > > I belive there is both support from the vendor and there seems to be a > > large and growing grassroots user base. > > Do you know a contact at Philips? I'd like to get a confirmation for the > things mentioned above. It seems we'll stop trying to use SPI and do it > in software, so we don't have to modify the hardware (which is waiting to > be delivered to a client).No, my contacts are all in the US. I used to have a friend handling Philips, but they just pulled the line from the independant reps and now have an in-house sales force. I have a contact name here in Maryland, but I don't think that will help you much. -- 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 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. -- Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net) Available for consulting/temporary embedded and systems. <http://cbfalconer.home.att.net> USE worldnet address!
Reply by ●February 19, 20042004-02-19
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. Mark Borgerson
Reply by ●February 19, 20042004-02-19
In article <c127eu$r7e$1$830fa7a5@news.demon.co.uk>, martin_underscore_walton_a@t_flyingpig_full.stop_com says...> > Heck, the Philips and OKI parts are already as cheap if not cheaper than > a lot of the PICs that have much less capabilities. > > //------------------- > > As someone who uses PIC/AVR/8051 on a regular basis, the Philips and OKI > parts are really attractive, however getting hold of them easily is a > real issue at present. Most of the projects I work on involve small > quantities (ie. a couple hundred), and as a result, I tend to be pretty > low priority to the distribution companies. Component availability is > therefore a prime consideration when choosing parts. > > I can buy PICs or 8051 from a large number of sources in the UK in any > quantity, without any hassle. If I can't buy the exact part, chances > are a similar version is available which is pin and code compatible. > AVR is a little more difficult, especially if you want access to the > full range, but if I can't get them locally, then Digikey give me > excellent service. > > We have looked at the Philips range and have a dev board which we have > been using to evaluate various tool chains, and from a technical > standpoint, I'm really like it (apart from the lack of code protection). > > I think Philips need to get this range into the catalogue suppliers like > Farnell and Digikey, at which point it should really take off. >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. I would probably wouldn't have used either the ARM or MSP430 except that I had a customer foot the $4K bill for the IAR ARM compiler and I started investigating the MSP430 about the time ImageCraft came out with an MSP430 C compiler. Now if ImageCraft will just do an ARM compiler---Richard are you listening? ;-) Another possibility is to figure out how to use the ARM compiler in the MetroWerks PalmOS system to generate ARM code for an embedded ARM system. The PalmOS system is only $399, and it has been adapted for some 68K embedded systems. When I get some free time (yeah, right), perhaps I'll get the latest PalmOS system and see whether you have the ability to easily generate ARM binaries. IMHO, a good LPC2104 demo board and fully capable C compiler for under $400 would sell like hotcakes in the Digi-Key catalog. Mark Borgerson
