Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[2.0.x] L6470 - add powerSTEP01 support #13053

Closed

Conversation

Bob-the-Kuhn
Copy link
Contributor

This PR includes all the changes/corrections of PR #13011. The PR can be killed if this PR is implemented.

This PR adds support for the powerSTEP01 family of steppers from STmicro. The L6480 is a subset of the powerSTEP01.

The code changes are a result of the following differences between the L6470 and the powerSTEP01/L6480:

  • Additional registers
  • Register address changes
  • Changes to bit locations and definitions

Selection between the two families is done via the POWER_STEP flag in configuration_adv.h. This flag is used to select the appropriate code and the correct Arduino_L6470 library header.

See PR #12 for my proposed changes to the Arduino_L6470 library. The changes that were made are:

  • Added additional definitions and #if statements to select the appropriate definitions.
  • Changed the Overcurrent Detection threshold and Stall threshold commands to allow for variable numbers of bits and variable "mA per count" constants.
  • Created a header/CPP file set for each family. The only differences between the two sets are several defines.

@thinkyhead
Copy link
Member

thinkyhead commented Feb 2, 2019

Squashed, rebased, and added a change to use L64XX::chain. See comments on ameyer/Arduino-L6470#12.

@Bob-the-Kuhn
Copy link
Contributor Author

Changed to using subclasses to differentiate the stepper drivers and added the ability to select the slew rate used by the drivers..

Also fixed a bug in the pins_debug for DUE.

TO DO:

  • @thinkyhead - please enlighten me on the desired method of keeping the linker from throwing an error when the external SPI routines are not present. I can't find your message on the proper method of configuring the L6470 library to do this.
  • Update the configuration files.

@Bob-the-Kuhn
Copy link
Contributor Author

I must have a subconscious hatred of L64XX::chain because, once again, I've undone L64XX_chain => L64XX::chain

Say the word & I'll implement L64XX::chain..

@Bob-the-Kuhn
Copy link
Contributor Author

I think Travis is sick. I see another PR that filed the STM32F1 test.

I just dropped the "STM32F1R EEPROM_SETTINGS EEPROM_CHITCHAT REPRAP_DISCOUNT_SMART_CONTROLLER SDSUPPORT PAREN_COMMENTS GCODE_MOTION_MODES" options into a fresh copy of 2.0 and it compiled without errors on PlatformIO. Lots of warnings but no errors.

I didn't find a compatible board listing in Arduino. Always got the "Oops! Select an STM32F1 board in 'Tools > Board.'" message.

@thinkyhead
Copy link
Member

thinkyhead commented Feb 26, 2019

I think Travis is sick.

We'll just have to disable the STM32F1 test for now.

@thinkyhead thinkyhead force-pushed the powerSTEP01-PR branch 5 times, most recently from 6b041f1 to 1c00782 Compare February 27, 2019 03:33
@Bob-the-Kuhn
Copy link
Contributor Author

  1. Found another area that didn't get the macros changes

  2. Added a second status read during the init which turns off the powerup/reset undervoltage lockout flags which turns off the ERROR LED on the STMicro eval board.

@thinkyhead thinkyhead force-pushed the powerSTEP01-PR branch 4 times, most recently from eebcea1 to 25b6a41 Compare February 27, 2019 11:19
@thinkyhead
Copy link
Member

Rebased, squashed, cleaned up…. Almost there……

Change the way the array axis_mon is defined and how it's passed to the get_user_input function.
@Bob-the-Kuhn
Copy link
Contributor Author

Just in case it's of any use ...

Here's the L6470.h file, using the method I stumbled across, made all nice & pretty. If nothing else it could be a convenient source of nicely formatted lines for the final version.

L6470 pretty.zip


I tried using the L6470 stepperX(stepperZ3(L6470_CHAIN_SS_PIN, L64helper_pointer) to get the helper linkage but couldn't get past the compiler errors.

I tried that method because, if I remember correctly, the L64XX::set_helper(this) in L6470_Marlin.h has to be of the form stepperX.set_helper(this) to execute during run time.

FULLY FUNCTIONAL using optional external SPI linked via  code within Marlin classes.

1) Went back to the handler/pointer method
2) removed helper class from L6470.h
3) renamed L6470_Marlin class to L64XX_MARLIN
4) removed all helper code and renamed anything that had "helper" in it.
@Bob-the-Kuhn
Copy link
Contributor Author

Bob-the-Kuhn commented Mar 12, 2019

For your consideration...

This code is fully functional. The only thing I want to do is rebase the code.

I reverted back to your handler/pointer code and got it working. I then removed the helper class from L6470.h and renamed the helper class in L6470_Marlin.h.

Here are the Arduino-L6470 files that go with this code.
L6470 pointers.zip


  • 90% of the changes are in L6470.h & L6470_Marlin.h
  • 9% of the changes are in L6470.cpp & L6470_Marlin.cpp
  • Added set_handlers function to L6470_init_chip routine in stepper_indirection.cpp
  • All other files just have name changes.

Bob-the-Kuhn and others added 10 commits March 12, 2019 05:26
Need to clear the powerup/reset error bits before can set slew rate on L6480/powerSTEP01
Change the way the array axis_mon is defined and how it's passed to the get_user_input function.
FULLY FUNCTIONAL using optional external SPI linked via  code within Marlin classes.

1) Went back to the handler/pointer method
2) removed helper class from L6470.h
3) renamed L6470_Marlin class to L64XX_MARLIN
4) removed all helper code and renamed anything that had "helper" in it.
@Bob-the-Kuhn
Copy link
Contributor Author

Bob-the-Kuhn commented Mar 12, 2019

Just rebased the code and now the Y & Z step pulses are gone when using L64xx drivers and when using A4988 drivers.

I'll look into it later today.

UPDATE

Turns out I was running into software endstops. Looks like they are now always on except if you enable them in configuration.h and then issue a M211 S0 command.

@Bob-the-Kuhn
Copy link
Contributor Author

The Travis test is failing do to the error: 'class L64XX' has no member named 'set_handlers'.

I'm pretty sure the reason is Travis is using a different Arduino-L6470 library than required by this PR.

FYI - G26_MESH_EDITING is enabled on multiple tests within megaatmega2560-tests. It has been replaced by G26_MESH_VALIDATION.

@thinkyhead
Copy link
Member

I will be offering courses on git usage here in Austin for anyone interested.

@Bob-the-Kuhn
Copy link
Contributor Author

😉 What?!?! You think that a little education might stop me from writing over your work?

Others have tried to educate me but I've foiled them all!


Yes, I'd like to participate. I'm retired with only Dr. visits on the calendar so I'm pretty open.

Thanks for being so patient.

Your 3 line set of instructions on how to suck the latest PR code back into my local branch has been very useful.

Mostly fixing incomplete conversions and upper/lower case issues
@Bob-the-Kuhn
Copy link
Contributor Author

I just grabbed the changes since my commit a week ago, fixed the bugs that were introduced and tested the code. It looks to be 100% functional.

There are two items of note:

  • drivers.h - I removed the qualifiers on the X2, Y2, Z2 & Z3 macros. They caused the macros to always evaluate to false no matter what driver was specified for the axis.
  • index_to_axis[][] - I was getting compiler errors until I simplified the declarations in L6470_Marlin.h and L6470_Marlin.cpp. I just couldn't find a mod to L6470_Marlin.cpp. that resulted in a match to the declaration in the following error message; " error: 'L64XX_Marlin::index_to_axis' has a previous declaration as 'const char* const L64XX_Marlin::index_to_axis [13][3]'"

@thinkyhead
Copy link
Member

Thanks for slogging through my different theoretical approaches to the L6470 code. If the helper method works, that is fine, and is probably the best approach for Arduino-style libraries.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants