start on firmware

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.
+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. 
+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)

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

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 configureCAN(void);
-// void configureEncoder(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.init(&spi1);
-	// sensor.setABZResolution(ENC_PPR);
+	sensor.setABZResolution(ENC_PPR);
 
-	// enc.init();
+	enc.init();
 
 	// Driver initialization.
 	driver.pwm_frequency = 32000;
@@ -179,8 +179,8 @@ void configureFOC(void){
 	// }
 }
 
-// void configureCAN(void){
+void configureCAN(void){
-// 	FDCAN_Start(0x000);
+	FDCAN_Start(0x000);
-// }
+}
 
 

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

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 <Foo.h>
+#include <Bar.h>
+
+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

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