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] Multiple updates to STM32F1 HAL #8733

Merged
merged 19 commits into from
Dec 11, 2017

Conversation

victorpv
Copy link
Contributor

@victorpv victorpv commented Dec 9, 2017

Multiple updates to STM32F1 HAL.
Speeds up timer code, reduces ADC rate to reduce memory access by DMA, adds boards to the corresponding files.
Marlin has been tested so far with all those boards.
STM3R_Mini and BeaST are custom boards I am using for development.
Malyan M200 and Chitu3D are commercial boards in which we have run Marlin successfully.

Includes 1 change to configuration_store to add support for eeprom emulation in MCU flash, since the flash can't be erased byte by byte. We have to erase the whole page.
We use 2 pages, so 2000 updates before they wear out. This is only needed for boards without i2c eeprom. I have successfully tested i2c eeprom with the Chitu3d, Stm3r_Mini, and BeaST

victorpv and others added 16 commits December 9, 2017 13:13
Adding files for STM32F1 HAL based on libmaple/stm32duino core.
Current persistent_store uses cardreader changes to be sent in separate
commit, but could be changed to use i2c eeprom.
There is another persistent_store implementation that uses the MCU flash memory
to emulate eeprom
Adding readme with some information about the stm32 HAL.
On bluepill STM32F103C6 boards, using Timer5 results in a error() vector call. Switch to 4 since these are both general purpose, 16 bit timers.
Some low end machines doe not have EEPROM support. Simulate it using the last two pages of flash. Flash does not allow rewrite between erases, so skip writing the working version if that's enabled.
This is a work in progress to go hand in hand with the STM32 work.
…e pin enumerations in STM boards vs what marlin expects (i.e, try defining PA0 as a temp pin). The hack can be removed with we go to fastio completely. To see this work, set something in adc_pins to a value like PA0 and connect your pullup resistor'd thermistor.
We have an actual ADC init function now.
Remove the pin mode hack that I was using to init PA0.

Updated Readme.md
Faster GPIO, and faster timer functions by accesing registers and
libmaple.
Still more changes pending for the Timer's code to skip using the
HardwareTimer class altogether.

Update README.md

Update README.md

Update README.md

Switch all enums to be within #defines

This change allows a user to have, for instance, TEMP_4 and TEMP_BED definied but nothing else. The enums which are not defined move "out", allowing the first ones to take the slots in the enum, and since the array is sized on ADC_PIN_COUNT, we always have the right size data and in order.
Update Malyan M200 pins with correct fan values.
Some of the pin definitions were from knowlege base/pdfs. Now they've been tested against actual hardware. This should be very close to final.
Add sample configuration for Malyan M200 without bed leveling, and move fan to auto cool E0 since this printer by default has only one fan.
# This is the 1st commit message:

Choose the timer based on MCU defintion. Timer5 is not valid on C8/CB class boards, so use Timer4 for the step timer.

# This is the commit message #2:

Readme.md update

# This is the commit message #3:

Readme.md update

# This is the commit message #4:

Trying to get readme.md updated

# This is the commit message #5:

readme.md update
@Wackerbarth
Copy link
Contributor

Wackerbarth commented Dec 10, 2017

"We use 2 pages, so 2000 updates before they wear out." -- I've wondered about using a different strategy for the configuration store. Rather than rewriting the entire configuration each time anything changes, we could store just the changes in a journal.

Initially, and when the configuration space is full, we would erase everything and store any values which differ from their default value. Then when some value is changed, we would append the new value to the end of the journal. The process of fetching a value from the configuration store would be a little slower, but that is done only on boot-up and when the user explicitly reloads from the configuration rom.

@victorpv
Copy link
Contributor Author

@Wackerbarth feel free to contribute code to improve it. At the moment we are more focused on getting things working, than getting them optimal.
The stm32duino core includes a library to store 16bit values, that uses an index, where the index would be equivalent to the address, is not exactly like I understand journal, but kind of. The information in written down to top, but read top to down. The last entry for a particular index is the only valid one.
In that, each 32bit word is split in 16bit for index, and 16bits for data.
The problem with that one is that storing 8bit values is very inefficient, so someone over the stm32duino forum posted another version that uses 8bits for index and 8 for data, so each 32word can hold 2 byte values. But then the index is limited to 8 bits. I am using it for another project that needs to store a smaller amount if information, and 256 positions is good, and storing bytes is more efficient than 16bits, but Marlin uses more than 256 positions of eeprom.

Another possibility is to take 8bits for index and 8 for data, but subdivide the flash pages in blocks, or use more pages, so we can have a 9th bit or even a 10th bit for index, with those 2 extra bytes not being stored, but rather indicating the code in what block that data is supposed to be.

There are multiple possibilities, if want to try to implement a different one we can give it a shot.

I did one implementation where the config data is saved to the sdcard, similar to what the re-arm does, but the re-arm has an sdcard onboard, not the display one, but the Marlin maintainers didn't like the idea of storing the configuration in an sdcard in the LCD display, that people may take in and out to add new files etc.

@thinkyhead thinkyhead added C: Boards/Pins T: HAL & APIs Topic related to the HAL and internal APIs. labels Dec 11, 2017
@thinkyhead thinkyhead changed the title Bugfix 2.0.x Multiple updates to STM32F1 HAL Dec 11, 2017
@thinkyhead thinkyhead changed the title Multiple updates to STM32F1 HAL [2.0.x] Multiple updates to STM32F1 HAL Dec 11, 2017
@thinkyhead
Copy link
Member

Overall, looks good. I think we can work with it. Will merge soon, and tally ho!

@thinkyhead thinkyhead merged commit a5150c8 into MarlinFirmware:bugfix-2.0.x Dec 11, 2017
@victorpv
Copy link
Contributor Author

Thanks. I am in the meanwhile testing the multi-host from TCM, so when that's ready to merge I will have the STM hal ready and tested for those changes.

@victorpv
Copy link
Contributor Author

I noticed I am making some mess with the readme.md file, and now have 2. I will correct that in my next PR.

@thinkyhead
Copy link
Member

thinkyhead commented Dec 14, 2017

If you want to rename something, giving it a different case, such as readme.md => README.md first rename it _README.md in one commit and then rename it README.md in a separate commit. This will keep git from getting confused when using case-insensitive systems.

@victorpv victorpv deleted the bugfix-2.0.x branch February 8, 2018 04:56
@ellensp
Copy link
Contributor

ellensp commented Jun 1, 2021

"STM3R_Mini and BeaST are custom boards I am using for development."
Where these ever realesed?
If not perhaps we should remove them from marlin?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C: Boards/Pins T: HAL & APIs Topic related to the HAL and internal APIs.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants