I have used the LPC2138, LPC2148 and LPC2292 devices. All of them have problems when enabling more than one interrupt source. When looking at the datasheets they do look nice. When one starts to use them, all sorts of little niggly things start to crop up. The pin mapping for instance seemed to have been thought out by a drunk. If one selects certain pins for a specific peripheral. i.e for UART, or SPI or whatever, one suddenly finds that things like one now can only use half of SPI2 or UART2. So one must be VERY careful when assigning functions to pins. Stupid things like, if one uses the I/O pin which may be used as the "Slave Select" for the SPI, for another function when using the SPI in master mode, it forces the SPI into slave mod when it goes low, even if it has been assigned as a GPIO pin. So one looses the use of this pin when using master SPI mode. For very simple projects where one uses the absolute basic modes of the peripherals, they are OK. If you need too push the hardware a bit, it is going to bite you in the arse.
It's not that bad and it was pushed to the limit in the project: SPI, TWI and SSC are running in parallel at high frequencies, all with PDC (very nice DMA interface, with some simple to use registers) and interrupt signalling. And a graphics co-processor was attached to the SRAM interface and a SDRAM to the SDRAM interface, both operating with high data rates (and a NAND flash, but this is not used very often). So it is OK to show some bugs, if we can find workarounds for it :-)
--
Frank Buss, http://www.frank-buss.de
piano and more: http://www.youtube.com/user/frankbuss
Yes, that's fair enough. Most people don't need parallel or serial ports these days, so they shouldn't have to pay for them on a motherboard. I /do/ need them, and I can buy them at a perfectly reasonable price as add-in cards. The cost for support in the bios is pretty close to zero, so it is still included there (actually, I expect that the OS doesn't need any help from the bios anyway). As long as the situation stays that way, everybody is happy!
MS has been trying to push in this market for years without much success
- and I hope it stays that way. Windows is fine for games, okay for work (it has its good points and its bad points), but a terrible choice if you are looking for reliability, stability, or long lifetimes.
But I fully agree that serial port support is likely to stay in windows for a long time to come - and I agree with your reasoning about costs.
Serial ports do still turn up on a lot of devices, but mainly in more specialised or low volume devices - it's gone from the consumer world. USB ports are not hard either these days - replace your MAX232 with an FTDI232R and change the plug. Your microcontroller, its software, and the matching PC program will never notice the difference.
I knew that brief comment would rub you the wrong way :-)
It is certainly true that old versions of Linux are unsupported by the major vendors, but they are still available and still in use. Whether you think it is worth it or not depends entirely on your usage and your knowledge and experience. But the important thing is that you still have the choice. You are not faced with Microsoft telling you are not /allowed/ to buy XP even if you want to - if you want an older distribution, or to build an older kernel yourself, you are free to do so. I am aware that this may have a substantial cost in time (and therefore money), but you have the choice.
Also note that drivers and hardware support are not removed from Linux without good reason. And when you have a driver for a relatively simple piece of hardware, the maintenance costs are normally negligible, so they remain available in the kernel for those that want to use it. Thus a hot-off-the-press modern distro has built-in support for /far/ more hardware than you get on a Win7 DVD, especially for older hardware. (Support for certain very new hardware may be a different matter, as is support for a few classes of hardware such as the dreaded "winmodems".)
We agree on all above... I agree that wince/xp in embedded is not a good thing but my point was MS was pushing hard with a lot of resouerces
Actually the text on the problems with Linux cam out of a report by Monta-Vista....
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Monta-Vista is a company that makes its living selling Linux distributions and development kits aimed mainly at embedded systems, along with associated support and services. They also provide real-time versions of Linux, which is no simple task. I have had no contact with them or their products or services, so I can't judge in any way, but I have only ever heard good things about them.
But you really should not be surprised if they say that making an embedded Linux system by yourself is hard and costs more than buying the service from a professional company (such as themselves...).
No. The Atmel support is good (I needed it for some other problems, but this was my fault not reading all of the 1000s pages of the datasheet), but as soon as I found the problem with the scope and debug messages, it was a matter of minutes to write the workaround for it, so no need to contact the support.
IIRC it was TXCOMP. Maybe I disabled it too late, so that it was still issued from Linux after programming the mask register, because looks like TXCOMP is issued as soon as you initialize the interface, as some other discovered with JTAG and a sampling scope:
formatting link
The responses at this webpage shows how happy people are in general with the TWI hardware in the SAM7 chips :-)
Maybe time to reimplement it? In theory I2C is really really simple (though not as simple as SPI), but I guess some of the problems arise because of the complexity to try to fit master, slave and multi-master into the same module and register set. Maybe would be better to abandon multi-master functionality at all (I don't know any system which needs it) and split master and slave in two modules (most systems will need a stable master, only).
--
Frank Buss, http://www.frank-buss.de
piano and more: http://www.youtube.com/user/frankbuss
Sounds good, but too late for me, because the system with the SAM9G20 is already in production and I guess it would need some major redesign to use the new chip? But it works, so please don't backport the new TWI block in a new reversion of the SAM9G20, because maybe then my driver or workaround won't work any more :-)
--
Frank Buss, http://www.frank-buss.de
piano and more: http://www.youtube.com/user/frankbuss
I think the SAM9G20 should be considered stable. AFAIK, There will not be any new revs of any existing SAM9s. They are all considered a done deal, and the designers get to focus on the new stuff ;-)
--
Best Regards
Ulf Samuelsson
These are my own personal opinions, which may (or may not)
be shared by my employer Atmel Nordic AB
I actually feel a bit better about my choice of STM32 over LPC after reading this. The STM32F103 that I've been playing with doesn't appear to have any of this silliness. Coincidentally, the SPI bug you mentioned sounds very similar to an SPI bug that I found on a PIC18F4550 several years ago: when the SPI is in master mode, "slave select" should be ignored but if you try to use it as a general purpose input, a slowly rising waveform will actually corrupt outgoing SPI master data. This one took me a long time to tack down.
The same is true for some AVR chips, but with the workaround, that you can at least configure it as output:
formatting link
| If SS' is configured as an output, the pin does not affect the SPI. If SS' | is configured as an input, it must be held high to ensure Master SPI | operation.
Looks like a lot of chip designers think it is a useful feature. Some programmers, like me, don't think so.
--
Frank Buss, http://www.frank-buss.de
piano and more: http://www.youtube.com/user/frankbuss
Well, that might be a problem of the software rather than the chips. Have used all of them and more. The ARM interrupt controller whether with or without VIC is plain poor. Priorities for nested interrupts have to be handled in software. Enough working application notes though. Not nice but common to most ARM7 devices. Exception the AIC from Atmel can handle nested interrupts but lags support from many development tools and RTOS.
When looking at the datasheets they do look nice. When one
There is a bit of information missing here. The STM32 is based on Cortex-M3, so are the LPC1xxx devices. They have a MUCH better interrupt controller that handles nested interrupts nicely, not like the ones on the ARM7. A LPC1700 can compete with any STM32 device, so can the Stellaris 9000 family. Differences are in pricing, integrated (or not) PHY for Ethernet, quality and speed of ADC....
No, it was a hardware problem. Yes the VIC is poor compared to other interrupt controllers. Yes one has to handle nesting etc. in software. My software was sound. The same assembly stubs works 100% on other ARM7 variants. Only on the NXP devices does one get problems.
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.