I have used LPC arm micros in my student project. Now for my next project ( Model Rail )i want to use TMS750LS20216 TI micro. I need suggestions from you peoples.
First one is support from vendor. I mean how much the vendor assist for their product i.e example code, tutorials, technical support team etc.
Second one, is hardware support of the selected device. Is there enough support for these devices form third party vendors? like debuggers/compilers etc.
You may say i should use google??? Yes used it and searched many things but in addition i need your experience about this device and its support.
Thanks in Advance! Have a nice day!
If the goal isn't to learn to develop for real human-safety standards, then I would consider using processors that are much used by lots of developers. NXP LPC23xx are much more common processors, which means you can get much more help from other people.
It's possible to implement code based on human-safety standards, even with chips that doesn't have any special hw support. Having two independent oscillators for example may not be needed for your model railroad. Or it could be solved with an external watchdog chip that requires you to drive a GPIO pin (with pulse or maybe even pattern) to acknowledge the program is running.
Special processors are best used when you have special needs. It isn't uncommon, when using chips that not too many uses, that there may be very troublesome errata for the chip, but the manufacturer don't have any reason to fix them as long as the general functionality can be accessed with more or less strange workarounds.
Right now, we have a project where we need to use two SPI controllers for a single link - the manufacturer of the chip have (oops) forgotten to add two DMA channels (receive and transmit concurrently) and same thing with FIFO. So one SPI device is master while the other SPI device is slave and listens to the answers from the other side. Strange workarounds needed because we needed a processor with some specific features that very few processors could supply. And the chip manufacturer for some reason didn't realize that SPI is duplex...
I second what Per says: the TMS750LS20216 is a specialist chip. By its very nature, that means that there will be a nuch smaller "community" than with any general purpose chip - so your chances of getting help & support will be much smaller.
Did you have some particular reason(s) not to continue using NXP's LPCxxxx chips?
Are there any particular chips that are "favourites" with the model rail "community"?
Is there any particular reason to do this on a microcontroller at all? Might it not be easier to do the application on a PC - possibly controlling a simple microcontroller just for IO interfacing?
Using a PC would certainly make the user interface nuch easier - and mimic diagrams, etc...
Should, of course, be: "a much smaller 'community'"
Per,
You posted
Right now, we have a project where we need to use two SPI controllers for a single link - the manufacturer of the chip have (oops) forgotten to add two DMA channels (receive and transmit concurrently) and same thing with FIFO. So one SPI device is master while the other SPI device is slave and listens to the answers from the other side.
I did something similar with two LPC2478s, but it was my choice - the SPI bus is used to deliver massive amounts of data, and we don't want the master to have to generate the clock cycles for the slave - therefore, we have opted for a half-duplex channel where only the MOSI line is used (DMA did not seem to help a lot to boost performance, alas). It does not matter really, as the protocol is rather simple - the sender packs the data (up to 1024 bytes) and the receiver only replies with a short ACK in between.
In our case, one side really is a duplex SPI. It's the other side that needs one master to send and one slave to receive because of a seriously broken silicon implementation.
A good SPI implementation should get hurt by having to generate the clock when data is only received. A simple solution is to run 16-bit words and have 0xffff reserved as NULL data. Then the receiving end can quickly scan FIFO or DMA data and ignore the NULL data with hardly any CPU load at all.
One trick to let the master rest when nothing needs to be sent in either direction is to have the slave side drive a signal (similar to a slave select) in reverse direction to an interrupt pin on the master. It activates this signal when it's in need of clocking to push data in the reverse direction.
Which processor are you referring to?
It activates this signal when it's in need of clocking to push data in the reverse direction.
Yes, we have 2 GPIO pins to arbitrate whose the master of the bus! It's actually a nice system, that I was able to build into a bootloader (one bootloader has a USB interface and sends binary images to another LPC2478, the other is only the client) and into the application, where the entire system is mirrored to accommodate data transfers to the other side as well. Pretty neat, but a little expensive in terms of computational power needed (hardware buffer is only 8 bytes long).
Sorry, but I'm not sure if the NDA is still in effect. The chip is now officially documented on the manufacturers web site, but it get's extra touchy since we are talking about chip problems not - at least yet - mentioned in any official documents.
My previous post, on the other hand, was just standard SPI use between a "normal" SPI master/SPI slave, where the slave uses an attention line to turn on/off the communication when needing to send data while the master is idle.
I wasn't talking about switching who is master or slave. But the slave having the potential to tell the master to start sending null data if the master haven't anything meaningful to send. This allows the chips to enter sleep while any side may reactivate the SPI communication. The previous processor we used on the master side had the slave select input sharing pins with the second ethernet controller, making it impossible for it to be an SPI slave. But the system still needed either side to be able to activate full duplex communication. So A may stream data or commands to B and receive acknowledges back while B may stream data or commands to A while receiving acknowledges. So the master may say "activate output x" and get an acknowledge on that while at the same time the slave may say "here is the measurements from the analog inputs" and get an acknowledge on that. Or maybe a huge stream of incomming or outgoing CAN data.