I am using IRremote Arduino library for some time and have found that it did not compile on STM32F103 board because of different timers. I was looking for some port for STM32F1xx and found only one guy who tried to port it, but it was not working for him..
..tried to fix his code with no success..
..so i forked IRremote Arduino library repo and ported it myself 😎
I have plans to use most of these ICs @ 12MHz SPI so i made proper shield instead of breadboard because some guy found it too noisy to work properly that way(link at bottom).
The shield is drilled a bit off axis as i did make it fast with 550W handheld drill 😛
First tests with built in libraries reach sort of low speeds, probably due to latency growing with bus speed, getting ~20kB/s with byte transfer for both writing and reading @ 12MHz and ~50kB/s for 4MHz SPI 🙄
23LCV512-I/P 64kx8bit SRAM 20MHz SPI – TESTED WORKING up to 12MHz
IP12B256I-TU 32kx8bit SRAM 20MHz SPI
IP12B512C-TU 64kx8bit SRAM 20MHz SPI
todo: # do some more tests..speed!!!
# find fastest library or make own, this guy juiced off ~120kB/s
i did lol on whole thread how the guys grew up the code and made it far more complex
with weird function names for motor movement as well 😀
they forgot that Arduinos have only 2KB SRAM(most of units sold) for whole project
so we cannot spent huge part of it to make work single part 😀
the idea of the original code is far better than the complex mess from the coolguys..
its not generally wrong to use digitalWrite and its not necessary to use direct port manipulation like tha guys recommended because of the sequential type of the movement..
main problem of the original code is that there is attempt to be correct and make steps somewhat aligned to time with 4x digitalWrite in a row so it delays the desired change of state by variable but repeating amount of time 😀
correct is that there is just one change per the substep and make timing between these same way as datasheet says..
to be fine we must also introduce possibility to add sort of delay between the steps with all coils off as the original code makes stepper pretty hot after a while of high speed..
we should also care of full step and wave drive techniques so we can reach higher speeds than with halfsteps in the original code.. meh..
also i did get from 190 bytes of precious SRAM usage(serialPrint and so on) of the original code(not to mention the coolguys memory bombz lol) to 9 bytes (!) least for working code and 11 bytes in my „light“ version with no precise timing, just the steps and sort of „speed“ (aka delay) 😀
with timing mem usage is somewhat higher because of storing time variables as float type..
this can be partially lowered as we can fiddle with memory storing.. 😀
here is version 0.9.0 beta for testing.. eats 11Bytes of SRAM 😀
+ half steps both directions
+++ wave drive!!!
+ ability to set speed
+ full torque for testing
* be cautious with the testing full torque halfstep function, theres need to use stepper_sleep() func after >ending< sequence of these or even single step to turn coils off -> less heat.. its not used in demo code in loop() section. you have to add call to that func to test.. also its good to call stepper_sleep() before to ensure that all OUTs are LOW..