SPI bus generic driver and ST L6480

Hello,

Is there some progress in this project?
I am prepared to help with development by some way. I have ODROID-C1 running LinuxCNC and MLAB's prototyping module with L6470 driver www.mlab.cz/Modules/H_Bridge/HBSTEP01B/SCH_PCB/HBSTEP01B.pdf
Therefore I could continue in the work at SPI controlled stepper driver. But I need a starting point...

Good timing. I stopped work on the project for the nice summer months and was just about to go back out to the shop!
Latest Status: I have demonstrated running with 2 physical axes of coordinated motion. I haven't made up the cables for the third axis and tested it, but there isn't any reason it shouldn't work. It detects a lack of communication with the boards fine. It detects an estop condition and can recover gracefully. There is a little code in it right now to detect a single dropped bit (from interference) in the SPI responses that I need to back out -- It watches for a single reported byte back with a large following error and repeats the last answer instead of giving a clearly erroneous one. I have closed control loops around the driver and can treat them like servos. On my setup, I am limited to about 60ipm (200 steps/rev, 5 revs/inch) before the following error due to command delays exceeds my 0.0015" max. The driver is still a hack, because it still passes pointers via a couple of hal pins, but it works--I have done some work on a ring buffer component to get rid of that, but the kernel pukes when I try to use it. Getting the ring buffer component working would be a HUGE step to making it usable by others. I will fire the box up and post the code for both the ringbuffer stuff AND the L6480 driver.

Thanks for reply andypugh
But hm2_eth seems to be completely different task... I am thinking about SPI interface driver for L6470 chip, but I do not know where is up to date code for the L6480 which I could expand by another control chip.

yeltrow:
It is great plan! Have you a code repository which I could fork and start to make improvements?

Andy's hd2_eth has some very elegant code that would be a great template for a new SPI driver. I have found it challenging to adapt because of my skill level and understanding--Once I get things ready to clean up and publish I would like to re-template things to match Andy's work.

I have scraped all of my miscellaneous development folders together and zipped them up. They were all working -- I just haven't been back into them in about 7 months, so I need to refamiliarize myself with my own code again. I SHOULD put my code back up on github. Anyway--Here it is!

Hello yeltrow,

Firstly thanks for your code!
I am digging in it. But I have not a progress.. It seems to be too much complicated for me to understand the code.

What part of the code I should get running at first if I want to start a testing? Assuming I have a stepper driver correctly connected to the ODROID-C1 SPI interface.

There seems to be several testing codes floating around, but I do not know how can I use it..

You are very welcome for the code. I think the first thing you should know about the code, is that it is meant to talk to the bitbanged SPI driver that I wrote over a somewhat dangerous passing of some pointers. I will try to walk you through testing it incrementally to get the whole thing up and running. Most of my testing has been done using the halrun (no gui) and the various ini files that I included in the zip files. I will have to refresh myself a little on building the components and which order you should test them in.
The general process was first making sure I could load each of the modules without hanging up the machine. Then I think I used the spitest.ini (i.e. halrun spitest.ini) to bring up something that would just shoot data out the lines. I tested it using halscope to make sure I could send some serial data and that the pins were actually doing what I wanted.
After that I verfied that I could read and write registers to the buffer component from a driver (like the LED display driver) to the buffer, to the spi interface. Once I did that, I moved on to trying the L6480 driver and seeing that it could read and write the configuration parameters. You'll need to compute all of the values for them, but I think with the 6470, life is lot easier than doing the computations for the L6480. The 6480 is a voltage mode driver chip, so one has to compensate for inductance and rotational velocity to come up with the right duty cycle. I have a spreadsheet that I used to do that. It may be somewhat useful to you because it does the conversion from steps/sec to rpm and a few other things. I am beginning the migration of my "benchtop test" to running on the mill, so we can proabably work through these items together. The driver code is a little crazy -- It uses a "stack driven state machine" which allows the code to drop through after it gets the buffers tended to without hanging, but still be able to keep track of where it left off and call "subroutines" of code as needed, which are really just special states. Are you familiar with state machines?

Therefore the first thing which I should do is rewriting the SPI driver code. It is necessary because I could not use bitbanging on ODROID-C1 computer due to lack of proper libraries and it will be probably too slow. Instead I have directly accessible the SPI hardware trough kernel driver: github.com/mlinuxguy/odroid-c1-kernel-3....tion/spi/spi-summary
Tomorrow I try to get halrun spitest.ini working with a new hardware driver..