L6470 Beta Ported Device Driver
This driver is for use with the ST Electronics L6470 Stepper Driver (dSpin) L6470 - Fully integrated microstepping motor driver with motion engine and SPI - STMicroelectronics
The code is a port of the “STM32F1xx motor control firmware library for the L6470 dSPIN IC”
To execute, create an instance of dSpinDemo, and call the Run() function;
new dSpinDemo().Run();
UPDATE: The code has been tested and it works. Also, the demo program may need a little tweaking to run your motor. The demo is coded to run the stepper at 10% of the input power. My stepper just buzzes at that setting. Upping it to 50% gave stable operation. I’ll prob try running it to 100% someday.
This Device and your driver may fit perfectly into a project i’m starting work on
Thank you
Hi,
I finally got my L6470 going with your library’s help! Thanks much.
One question I had was how to use your library with multiple devices in a daisy chain. I am sorry if this is a basic question, but I do not know much about SPI interfaces.
One more question. It was a bit confusing in the literature, but other stepper controllers I used had a ‘set motor current’ function, and this is a bit more complicated. Is there a simple way to go about this?
It appears that the L6472 chip takes care of this with a more classical approach. I do not see it at distributors yet, though. I wonder if it is not released yet.
Thanks,
Tom
So daisy chain requires sending more than 8 bits in a SPI request, which is currently not supported in .NET MF. The NXP chip itself however supports both 8 and 16 bit SPI modes. The only way to support device chaining is to do bit banging. You would have to override the function in the library that is sending the data to the SPI to implement that. Further there is a place in the code where the power of the stepper is set. I’ll update the driver later, as I had made some changes to make that process simpler.
So all the effort I put in to show you that you can send more that one byte was futile?
@ Errol, actually no. I do believe that you can do daisy chain, however the official documentation suggests otherwise. I can’t tell tommy that it works until I’ve been able to prove otherwise.
I still think the easiest way to do it is to manage the CS line yourself, outside the built-in SPI stuff. Tell SPI there’s no CS line, then send all the data you want before you toggle CS.
@ kurtnelle
Add Errol’s name to spell checker. 
There is no need, whatsoever, to mess with the CS line. We discussed this and proved the point multiple ways in another thread. The CS is toggled after the entire array of bytes are sent which is exactly what you want if you daisy chain these devices. It works perfectly as is!
@ Architect, lol yea it’s added in firefox but not in IE.
@ godefroi, yep there’s that method as well, however I may just go with doing the toggles directly.
In a few months I would have built my prototype Stepper driver boards for the CNC and we’ll be able to prove this once and for all 8)
@ Jeff, Yep the Logic Analysis has proved that. It also seems to be able to do it in the WriteRead method of the code
public byte[] WriteRead(byte[] data)
{
byte[] _receive = new byte[data.Length];
for (int i = 0; i < data.Length; i++)
{
byte[] _txData = new byte[1];
byte[] _rxData = new byte[1];
_txData[0] = data[i];
port.WriteRead(_txData, _rxData);
_receive[i] = _rxData[0];
}
return _receive;
}
in which if you write more than 2 bytes at a time the CS line will toggle only after the 16 bits are sent.
@ tommy, Perhaps you should try it since you have a working self made driver. Did you build 2?
@ kurtnelle
Why do you send one byte at a time? The CS line WILL toggle between each byte. Why not something like this?
public byte[] WriteRead(byte[] data)
{
byte[] _receive = new byte[data.Length];
port.WriteRead(data, _receive );
return _receive;
}
This will take CS active, clock all bytes in/out and then take CS inactive…
I believe that NETMF toggles CS between every byte, regardless of how many bytes you send. The underlying micro I think can do either 8 or 16, but if you want something other than that, you’ll have to manage CS yourself.
@ godefroi, that is the official documentation, however in the experiments that Errol did the CS line did not toggle after every byte, but only after each transaction.
Is that only the case with WriteRead()?
@ godefroi
Yes, the hardware can only do 8 to 16 bits. But CS isn’t controlled by hardware. MF controls CS. Thus MF sets the CS line, then uses the hardware to send multiple bytes, then releases the CS line. There is somewhere a few logic analyser traces that I did to prove this…
Hi,
I do not know how many are still interested in this, but my setup keeps tripping the STEP_LOSS_A and STEP_LOSS_B errors and throwing a flag. Does this just mean my parameters are under-powering, or accelerating the motor too fast? Anyone have experience with this error? Thanks again to Kurt for the great driver port!
Thanks,
Tom
If i remember correctly then the chip looks at motor current, if the current goes above a set limit then it throws a flag.
By default that limit is something like 1.25A.
Also keep in mind that the voltage to the motor is incresed with speed. The amount of increse is set in registers…
