Mark Borgerson <m-a-r-k@oes.to> writes:> 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 second this opinion. I do also design measurement instrument, and very often some rather complex analysis or calculations are required even though the data set is relatively small. Also, the bit banging requirements may be rather fast, which justifies the faster clock. In some applications multithreading is very useful, and doing that with a small 8-bit piece is usually not so simple.> I guess the FPGA would be nice,Unless you are short of power. Some CPLDs (Xilinx CR2, Lattice Mach 4000Z) consume little power, but FPGAs tend to need a lot even at a low clock frequency. In this sense the modern MCUs behave better, their current consumption is almost proportional to the clock frequency. - Ville -- Ville Voipio, Dr.Tech., M.Sc. (EE)
arm7 atmel vs others
Started by ●February 14, 2004
Reply by ●February 20, 20042004-02-20
Reply by ●February 20, 20042004-02-20
Ville Voipio wrote:> > Mark Borgerson <m-a-r-k@oes.to> writes: > > > 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 second this opinion. I do also design measurement instrument, and > very often some rather complex analysis or calculations are required > even though the data set is relatively small. Also, the bit banging > requirements may be rather fast, which justifies the faster clock. > In some applications multithreading is very useful, and doing that > with a small 8-bit piece is usually not so simple. > > > I guess the FPGA would be nice, > > Unless you are short of power. Some CPLDs (Xilinx CR2, Lattice > Mach 4000Z) consume little power, but FPGAs tend to need a > lot even at a low clock frequency. In this sense the modern > MCUs behave better, their current consumption is almost proportional > to the clock frequency.Is a minimum of 5 to 10 mA (depending on temp range) low enough? The Altera ACEX (EP1K) parts are rated for this. If you are trying to get much below this, you are really looking at a speciallized application (or you can just cut off the power to the FPGA). -- 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 20, 20042004-02-20
On 2004-02-19, Jim Granville <no.spam@designtools.co.nz> wrote:>> 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 ?If the pins are used for I�C, then they should be open drain, yes. But if I configure the pins for GPIO or match/capture, then I can't see why not use normal output buffers. This is how all other chips I know behave. I think this is a bug in the LPC210x or the data sheet - IMHO, in the chip ;-) -jm
Reply by ●February 20, 20042004-02-20
Jukka Marin wrote:> On 2004-02-19, Jim Granville <no.spam@designtools.co.nz> wrote: > >>>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 ? > > > If the pins are used for I�C, then they should be open drain, yes. But if > I configure the pins for GPIO or match/capture, then I can't see why not > use normal output buffers. This is how all other chips I know behave. > I think this is a bug in the LPC210x or the data sheet - IMHO, in the chip > ;-)Because normal output buffers have a clamp diode in the P-FET, which needs more design work to avoid. It is possible, but designers from this end are not used to thinking of every pin as important..... Not so much a bug, as an oversight, or 'could have done better', but almost all chips have those... -jg
Reply by ●February 20, 20042004-02-20
rickman <spamgoeshere4@yahoo.com> writes:> Is a minimum of 5 to 10 mA (depending on temp range) low enough?A maximum of 5 to 10 mA would be low enough :) I am more geared towards slowish (certainly below 100 MHz, often below 10 MHz) applications. In this regime there are applications which would be rather simple to do in hardware and quite difficult in software.> much below this, you are really looking at a speciallized application > (or you can just cut off the power to the FPGA).There are two reasons why I am looking for low max values instead of low average values: - some communication/power buses require constant current devices (such as the process industry H1) - intrinsically safe (explosive hazard areas) requirements limit the maximum current and energy storage So, usually the first problem with the configurable devices is the amount of start-up current they draw. (I do admit that with battery powered devices the start-up energy is usually insignificant.) There are some very nice low-power CPLDs already, so maybe the same trend will be seen in the FPGA's as well. Even though, it seems that Altera is not so much into low-power as Xilinx and Lattice. OTOH, at the moment a low-end ARM costs as much as a 128-cell CPLD. This means some ridiculously stupid tasks are more economically made with a MPU. - Ville -- Ville Voipio, Dr.Tech., M.Sc. (EE)
Reply by ●February 20, 20042004-02-20
On 2004-02-20, Jim Granville <no.spam@designtools.co.nz> wrote:>> If the pins are used for I�C, then they should be open drain, yes. But if >> I configure the pins for GPIO or match/capture, then I can't see why not >> use normal output buffers. This is how all other chips I know behave. >> I think this is a bug in the LPC210x or the data sheet - IMHO, in the chip >> ;-) > > Because normal output buffers have a clamp diode in the P-FET, which > needs more design work to avoid. It is possible, but designers from > this end are not used to thinking of every pin as important..... > Not so much a bug, as an oversight, or 'could have done better', but > almost all chips have those...Well, why does the data sheet mention "open drain" in the I�C description only, then.. Even Microchip documents these things and their datasheets are about the worst I've ever seen ;-) "This instruction clears a bit.. did I tell you about the UART already? This one sets a bit (did you notice we have _three_ timers?!) in memory.." -jm
Reply by ●February 20, 20042004-02-20
rickman wrote:>>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.Can one not use the pin select registers to switch the pin from CAPture to GPIO before sampling? Should only take a single extra VPB write cycle, if you have the direction register already set up in advance?>>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 seem to remember that you need a pullup or pulldown or something on SS when in master mode - because in multi-master situations, the device can only be master when it's not being told it's slave, or something. No, I have no idea how multi-master SPI is done, perhaps with all the SS lines running to a central arbitrator or something? Not sure how prospective masters would 'claim' mastership... Anyway.> > Check with OKI in a few more months. I have been told Ethernet is the > next one out of the shoot! >Ooooo! ABS
Reply by ●February 20, 20042004-02-20
On 2004-02-20, Alaric B Snell <alaric@alaric-snell.com> wrote:>> 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. > > Can one not use the pin select registers to switch the pin from CAPture > to GPIO before sampling? Should only take a single extra VPB write > cycle, if you have the direction register already set up in advance?If we change the pin from CAPture to GPIO, read the pin state, an edge occurs, and we change back to CAPture, we have lost an edge again.. The margin is very small, but as long as it's there, the edges WILL occur during that time ;) Plus, I think the CAPture logic will not work reliably if we switch the input to GPIO which (I believe) floats the internal CAPture logic input. Plus, it's more overhead ;-)> I seem to remember that you need a pullup or pulldown or something on SS > when in master mode - because in multi-master situations, the device can > only be master when it's not being told it's slave, or something. No, I > have no idea how multi-master SPI is done, perhaps with all the SS lines > running to a central arbitrator or something? Not sure how prospective > masters would 'claim' mastership... Anyway.Well, if you configure SS as GPIO, there's no way of pulling up the internal SPI SS signal.. they should have pulled it up internally when the pin is configure as GPIO. Actually, the SS is an output in master mode, so there should be no problem using it for GPIO while SPI is running. It just seemed that we couldn't get SPI working at all because it first comes up in slave mode and the SS pin was an input (which was floating). Sometimes, on some chips, the SPI would start working and when we were able to config it as a master, it then worked until the next reboot. (This is how I remember it, I haven't worked on this myself..) The reason we wanted to have SS as GPIO is that we are using a FLASH chip which terminates an operation when /CS goes high (and SS goes high after every single byte). Anyway, we "fixed" the problem in this design by using a software SPI implementation and having all the pins as GPIO.. Well, enough of this... ;-) Back to studying LCD's and LCD controllers.. -jm
Reply by ●February 20, 20042004-02-20
Chris Hills wrote:> 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 >Yep, and it's working fine for me (thanks Chris). Brief scary moment when my 2 year old godson picked it up when I was taking it to show his father (who works for the family firm, who currently use a lot of Keil 8051 stuff) but it survived intact :-) Anyway, it comes with a ready set up GNU compiler chain with a nice IDE on top, with the only restriction being that the debugger is an evaluation version and can only deal with up to 16KB of code and isn't to be used for commercial gain - but the actual compiler chain is unencumbered. ABS
Reply by ●February 20, 20042004-02-20
On 2004-02-20, Jukka Marin <jmarin@pyy.embedtronics.fi> wrote:> Actually, the SS is an output in master mode, so there should be no problem > using it for GPIO while SPI is running.This is garbage. On Motorola parts (like HC12), SS is an output in master mode and goes low during SPI operations. On LPC210x, SSEL is always an input - even in master mode. If it goes low, LPC thinks there was an SPI collision. If you config the SSEL pin as GPIO (to be able to use it as an SPI chip select), the SPI logic sees the input floating and will not work properly. -jm
