Main Site Documentation

Snippet - dSpin L6470 Device Driver


I just posted dSpin L6470 Device Driver on Codeshare. Feel free to discuss and make suggestions here.



I am most of the way through my modifications to the original driver, but if I’d known of this I would not have bothered! Your code addresses most if not all of my original concerns (and those I discovered later).

I particularly like the abstraction of the registers to get/set properties. This is a complicated chip and the more abstraction, the better. The forums are full of people who’ve tried to work with it and failed; maybe if they’d provided better support code GHI would still be making the board.

BTW when I first looked at your code for things like ThermalWarningAlarm, I thought that a get of this property would report a thermal warning [em]status[/em]. The name and the documentation could be clearer for those properties, I felt.
My code attempts to stop properties like Acceleration etc. from being changed when the motor is moving (throws an exception if invalid). I was also planning to add range checking of the values.

I’d like to understand more about the daisy-chaining approach. This is to support multiple L6470s on a single SPI, right? And the SparkFun AutoDriver supports that but not the GHI board? Driving several L6470s from a single SPI is something I’ll want to do, so I’m interested to see how this works.

If you’re interested in seeing my code so far, I’d be happy to share it (privately for now).



BTW I see you’re aware of the facility to declare the underlying type of an enum; in that case, you don’t need all those ugly casts where you specify the values.


Erm, true. I think I relized I could declare the enum type after I had put in those casts!

Yes, you’re correct, this driver is designed for the daisy chaining approach. This is partially the purpose of the CaptureBytes, GetCapturedBytes and WriteCapturedBytes methods. These allow you to send data to all of the dSpins simultaneously to produce synchronous movement.

I think that I will put in range values and throw the Invalid argument exception when breached however that adds more overhead to the executing code so I’ll have to put in a switch.

The driver has been improved by some of the persons who have tried to use it on the forum as well. I first started this driver 2 years+ ago.


On another note, I think the GHI module is superior to the Spark fun in one way: It can handle more power. While it is not advised it is possible to connect steppers in parallel or serial and drive them on the same chip. GHI’s implementation with the larger package chip makes this more practical.

The 3 concerns I had with their implementation is that
a) Didn’t break out the SW pin, which is mandatory for limit switches.
b) No board level support for daisy chain. You can make a separate board however that plugs into their board to make it daisy chain-able.
c) Flag isn’t broken out. When an error like ThermalShutdown occurs, I would like to have an interrupt notify the uC and not have to wait until I poll the chip.


Yes - I ran into the limitations of the GHI board you list myself. I had to unsolder the SW lead from the PCB - always a nerve-jangling operation.

I hadn’t realized that the SparkFun board used a different package; that’s worth knowing too. The only reason I didn’t buy the boards was because I couldn’t find a supplier in the UK.


Have you tried chaining the stepper boards using the S-plus module?


No, the modification I mentioned requires a custom board. It could be made by hand with a Sharpe though.


Sorry, I guess I didn’t put the question correctly. I understand that for a daisy-chain I’d need a custom board, it’s just that I’m trying to put together a prototype with the minimum of effort.

Do you think it would be possible to use the S-Plus to drive more stepper boards from a single S socket? As I understand it, it just uses another PIO to control the chip selects.


Er, yes the S-Plus should be able to drive more boards :slight_smile:


@ Mr. John Smith - Finally got a chance to play with the GHI Stepper Module and I have to say its pretty good and the choice of the L6470 is sweet as that is one feature complete chip. So maybe someday we can convince GHI to make a v 1.4 module with those couple of changes that you mentioned. Right now I’m wishing I’d bought more then one of the L6470 modules.


Why isn’t the L6470 on ?

Is this compatible?


@ DanW - No, that product is not based on the L6470.


@ Duke Nukem - Yep, I’m loving it. Would have been nice if somebody :whistle: put out a readily daisy chain able device though (I would not like the someone to be me).