SPI bus generic driver and ST L6480
03 Dec 2015 22:36 #66329
by kaklik
Replied by kaklik on topic 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...
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...
Please Log in or Create an account to join the conversation.
03 Dec 2015 23:50 #66335
by andypugh
Replied by andypugh on topic SPI bus generic driver and ST L6480
One starting point might be hm2_eth, the interface for the Mesa SPI boards. It has been shown to work with the Odroid.
Please Log in or Create an account to join the conversation.
04 Dec 2015 00:08 #66339
by yeltrow
Replied by yeltrow on topic SPI bus generic driver and ST L6480
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.
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.
Please Log in or Create an account to join the conversation.
04 Dec 2015 00:10 - 04 Dec 2015 00:19 #66340
by kaklik
Replied by kaklik on topic SPI bus generic driver and ST L6480
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?
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?
Last edit: 04 Dec 2015 00:19 by kaklik.
Please Log in or Create an account to join the conversation.
04 Dec 2015 01:02 #66344
by yeltrow
Replied by yeltrow on topic SPI bus generic driver and ST L6480
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!
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!
Please Log in or Create an account to join the conversation.
04 Dec 2015 01:39 #66345
by andypugh
It's not my code, none of code has ever been called "elegant".
Also, I meant hm2_spi, not hm2_eth.
Replied by andypugh on topic SPI bus generic driver and ST L6480
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.
It's not my code, none of code has ever been called "elegant".
Also, I meant hm2_spi, not hm2_eth.
Please Log in or Create an account to join the conversation.
10 Feb 2016 14:12 #69926
by kaklik
Replied by kaklik on topic SPI bus generic driver and ST L6480
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..
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..
Please Log in or Create an account to join the conversation.
10 Feb 2016 20:12 #69957
by yeltrow
Replied by yeltrow on topic SPI bus generic driver and ST L6480
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?
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?
The following user(s) said Thank You: kaklik
Please Log in or Create an account to join the conversation.
10 Feb 2016 21:30 #69961
by kaklik
Replied by kaklik on topic SPI bus generic driver and ST L6480
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..
Tomorrow I try to get halrun spitest.ini working with a new hardware driver..
Please Log in or Create an account to join the conversation.
11 Feb 2016 01:10 #69972
by jepler
Replied by jepler on topic SPI bus generic driver and ST L6480
The previously mentioned hm2_spi has been successfully used on odroid u3 with kernel /dev/spidev, but some kernel patches were also required so that the spidev iocttl did not have unreasonable latencies. See the top 3 or 4 commits at github.com/jepler/odroid-linux where some were spi and spidev specific, and some was spi hardware specific.
Please Log in or Create an account to join the conversation.
Time to create page: 0.085 seconds