arm7 atmel vs others

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 to
Jukka Marin
Loading thread data ...

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 to
Jim Granville

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.

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 to
Ville Voipio

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 to
Jukka Marin

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?

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.

Ooooo!

ABS

Reply to
Alaric B Snell

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 ;-)

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 to
Jukka Marin

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 to
Alaric B Snell

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

Reply to
Jukka Marin

I guess that's why I always like to have a few extra GPIO pins. Just run the same signal to the CAPture pin and a different pin to read the level. Then there's no need to reconfigure the capture pin and you shouldn't miss any events that happen within the capture timing limits.

Mark Borgerson

Reply to
Mark Borgerson

Yep.. we just ran out of pins, although this was a small and simple device. I guess I'm too used to MMC2114 and all its I/O pins.. :-I

-jm

Reply to
Jukka Marin

Been there, done that. Had to add a latch and address decoder to the last project because I ran out of output pins. Luckily, I had a chip select and a lot of spare address space, so it only took a 74LCX32 and a 74LCx574.

I think there's a rule that I/O requirements always equal pins available plus 1. If you add more pins, the customer feels cheated if they don't get used!

Mark Borgerson

Reply to
Mark Borgerson

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.