We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
I was wondering if it is possible to have two [or more] ULINK devices running on the same PC ?
I 'expect' [hope] to be able to launch two Keil IDE's and run two Target Boards using two ULINK devices.
Is that possible?
Ref: http://www.keil.com/forum/docs/thread6385.asp (Noting that it went un-answered, and it is really old)
--Cpt. Vince Foster 2nd Cannon Place Fort Marcy Park, VA
Thanks guys!
product(s) are almost done...!
Tamir, let me 'almost' congratulate you then ;-). It is indeed a good feeling to get something done after tons of work go into it... and I'm sure you've put many man-hours into those product(s).
In the future, we'll probably mainly use Cortex based chips, but first NXP have to release the Cortex M3
I too prefer the Cortex M-3 chips. I've stuck with STMicro's line so far, but NXP might be next on the hit-list.
I'm running SPI to multiple processors and using the SMT32 series as the master.
The [current] problem is that the NSS signal is not hardware controlled (no matter how much the data-sheets and emails to/from STMicro say otherwise). So I have to bit-twiddle the NSS line. I might be looking for a different Cortex M-3 variant.
[Note: I just put in a requisition for a new STM3210-EVAL board, and maybe a 'new' board will control the NSS signal in hardware].
Captain,
You posted
The [current] problem is that the NSS signal is not hardware controlled (no matter how much the data-sheets and emails to/from STMicro say otherwise)
Just for your information, this is also required on a LPC2468/78. Here is a question I posted several months ago to NXP, and the reply. As far as I could see it is not indicated in the user manual, but I might have missed it. This behavior makes a lot of sense, actually... I hope this can help you too:
Dear Madam/Sir,
We are reading the measurements of an external ADC connected to a SPI bus. We have noted that even though the LPC2478 is configured as having P0.16 with the role "SSEL (SPI), the chip select is not generated upon data transmission (we act as the bus master, of course). We are forced to manually clear and set P0.16 to correctly address the ADC. Is this a know issue? What can be the cause of this?
Kind regards,
Tamir Michael --------------------------------------------------------------------------- NXP Semiconductors answer: Hello Tamir,
Yes, this is the way it works. SSEL is only used in slave mode. As a master you need to control the slave's select pin in software using a GPIO pin.
Regards, Paul
I have discussed this before. It isn't so easy to have generic hw-acceleration for driving SSEL signals.
1 - one master may have multiple slaves, and hence a need for driving multiple SSEL lines in random combinations.
2 - some protocols sends one byte/word at a time, with SSEL toggled in between. Some protocols sends large messages (possibly several reloads of the FIFO or significant DMA bursts) between each SSEL change.
3 - some slaves have very specific requirements for settle and hold times for SSEL, potentially requiring a number of bit times between each transfer.
So it is quite complex to create a programmable solution for hw-driven master-side SSEL.
The NXP LPC23xx (and I'm pretty sure the LPC17xx) requires the master to drive the SSEL manually. This is very common behaviour even for very advanced SPI implementations with FIFO, DMA etc.
Tamir & Per: Thanks for the good info about NSS/SSEL lines.
Per, I do realize those issues, but when the data-sheets say Hardware Controlled, then I'd expect it to be just that at least on a per-byte basis.
They shouldn't advertize Hardware Control if it doesn't do that.
And like PWM A/B signals, dead-time controls could be put into the fabric (ref#3).
In cases of #2, I would expect it to be software controlled.
Case #1 is simply some glue logic to chip-select which slave to address, and NSS/SSEL the enable (or AND gates) for each slave. ...which is what I had expected to do.
I'm not shooting holes in your logic, its just that your conclusion might be valid (So it is quite complex), but it is definately possible and fairly easy to do in an FPGA/VHDL to address my "counter-points."
At this point, we are most likely going to move the SPI bus into the FPGA to handle everything as we would like it, and simply memory map the data I/O. (We need speed).
Again, thanks for the information. I'll definately keep your points in mind when we do move it into the FPGA.