diff --git a/README.md b/README.md index 4052bd8..2085a4a 100644 --- a/README.md +++ b/README.md @@ -1,8 +1,9 @@ # Lemon Pepper Stepper Driver -Small, all in one hybrid stepper + BLDC driver, designed to mount to the back of NEMA 14 size stepper motors. The board supports up to 48V @ 1.5A with a choice of either step-dir or CANbus inputs. -The boards can easily be assembled by JLC and the design has been cost-optimized, coming in at about $20 per board fully assembled. +Small, all in one hybrid stepper + BLDC driver, designed to mount to the back of NEMA 14/17 size stepper motors. The board supports up to 48V @ 1.5A with a choice of either step-dir, CAN bus, I2C, or USB inputs. +The boards can easily be assembled by JLC and the design has been cost-optimized, coming in at about $20 per board fully assembled (minus connectors, which need to be modified to sit flat on motor back). Due to the high pole pair count of stepper motors, a high resolution (21 bit) magnetic encoder is used, supporting both SPI and hardware ABI position encoding. Despite the rather high theoretical performance of this board I think you would need some serious cooling to actually hit the potential 50-70W specs of the parts. - +![Photo of PCB](/many.png) +![PCB on motor](/motor.png) ![Render of PCB](/render.png) diff --git a/firmware/lib/can/can.cpp b/firmware/lib/can/can.cpp index 99509c4..2560e86 100644 --- a/firmware/lib/can/can.cpp +++ b/firmware/lib/can/can.cpp @@ -154,7 +154,7 @@ void HAL_FDCAN_RxFifo0Callback(FDCAN_HandleTypeDef *hfdcan, uint32_t RxFifo0ITs) // Reply globally but put the replying ID in the data packet. TxHeader.Identifier = FDCAN_GlobalID; memset(TxData, 0x00, 8 * sizeof(uint8_t)); - memcpy(&TxData, (sFilterConfig.FilterID1), sizeof(uint16_t)); + //memcpy(&TxData, (sFilterConfig.FilterID1), sizeof(uint16_t)); FDCAN_SendMessage(); } else diff --git a/firmware/src/main.cpp b/firmware/src/main.cpp index b6cc516..fd2e4e9 100644 --- a/firmware/src/main.cpp +++ b/firmware/src/main.cpp @@ -10,7 +10,7 @@ #include "stm32g4xx_hal_conf.h" #include "stm32g4xx_hal_fdcan.h" -// #include "can.h" +#include "can.h" #include "dfu.h" #include "lemon-pepper.h" @@ -52,8 +52,7 @@ uint16_t counter = 0; // Prototypes void configureFOC(void); -// void configureCAN(void); -// void configureEncoder(void); +void configureCAN(void); void setup() { @@ -93,6 +92,7 @@ void loop() // motor.loopFOC(); // motor.move(); // commander.run(); + sensor.update(); delay(10); SerialUSB.printf("%#06x\n", sensor.readRawAngle21()); @@ -117,10 +117,10 @@ void configureFOC(void){ // Encoder initialization. // Ideally configuring the sensor over SPI then use STM32HWEncoder - // sensor.init(&spi1); - // sensor.setABZResolution(ENC_PPR); + sensor.init(&spi1); + sensor.setABZResolution(ENC_PPR); - // enc.init(); + enc.init(); // Driver initialization. driver.pwm_frequency = 32000; @@ -179,8 +179,8 @@ void configureFOC(void){ // } } -// void configureCAN(void){ -// FDCAN_Start(0x000); -// } +void configureCAN(void){ + FDCAN_Start(0x000); +} diff --git a/include/README b/include/README new file mode 100644 index 0000000..194dcd4 --- /dev/null +++ b/include/README @@ -0,0 +1,39 @@ + +This directory is intended for project header files. + +A header file is a file containing C declarations and macro definitions +to be shared between several project source files. You request the use of a +header file in your project source file (C, C++, etc) located in `src` folder +by including it, with the C preprocessing directive `#include'. + +```src/main.c + +#include "header.h" + +int main (void) +{ + ... +} +``` + +Including a header file produces the same results as copying the header file +into each source file that needs it. Such copying would be time-consuming +and error-prone. With a header file, the related declarations appear +in only one place. If they need to be changed, they can be changed in one +place, and programs that include the header file will automatically use the +new version when next recompiled. The header file eliminates the labor of +finding and changing all the copies as well as the risk that a failure to +find one copy will result in inconsistencies within a program. + +In C, the usual convention is to give header files names that end with `.h'. +It is most portable to use only letters, digits, dashes, and underscores in +header file names, and at most one dot. + +Read more about using header files in official GCC documentation: + +* Include Syntax +* Include Operation +* Once-Only Headers +* Computed Includes + +https://gcc.gnu.org/onlinedocs/cpp/Header-Files.html diff --git a/lib/README b/lib/README new file mode 100644 index 0000000..6debab1 --- /dev/null +++ b/lib/README @@ -0,0 +1,46 @@ + +This directory is intended for project specific (private) libraries. +PlatformIO will compile them to static libraries and link into executable file. + +The source code of each library should be placed in a an own separate directory +("lib/your_library_name/[here are source files]"). + +For example, see a structure of the following two libraries `Foo` and `Bar`: + +|--lib +| | +| |--Bar +| | |--docs +| | |--examples +| | |--src +| | |- Bar.c +| | |- Bar.h +| | |- library.json (optional, custom build options, etc) https://docs.platformio.org/page/librarymanager/config.html +| | +| |--Foo +| | |- Foo.c +| | |- Foo.h +| | +| |- README --> THIS FILE +| +|- platformio.ini +|--src + |- main.c + +and a contents of `src/main.c`: +``` +#include +#include + +int main (void) +{ + ... +} + +``` + +PlatformIO Library Dependency Finder will find automatically dependent +libraries scanning project source files. + +More information about PlatformIO Library Dependency Finder +- https://docs.platformio.org/page/librarymanager/ldf.html diff --git a/many.png b/many.png new file mode 100644 index 0000000..65a3403 Binary files /dev/null and b/many.png differ diff --git a/motor.png b/motor.png new file mode 100644 index 0000000..06ee789 Binary files /dev/null and b/motor.png differ diff --git a/test/README b/test/README new file mode 100644 index 0000000..9b1e87b --- /dev/null +++ b/test/README @@ -0,0 +1,11 @@ + +This directory is intended for PlatformIO Test Runner and project tests. + +Unit Testing is a software testing method by which individual units of +source code, sets of one or more MCU program modules together with associated +control data, usage procedures, and operating procedures, are tested to +determine whether they are fit for use. Unit testing finds problems early +in the development cycle. + +More information about PlatformIO Unit Testing: +- https://docs.platformio.org/en/latest/advanced/unit-testing/index.html