added OVERRIDE_MY_MACHINE and N_AXIS=2 got lots of errors about stm32f1xx HOT 51 CLOSED

Adding -D NO_SETTINGS_DESCRIPTIONS= to platformio.ini will reduce flash usage for the C8 USB build:

[env:bluepill_f103c8_128k_USB]
board = bluepill_f103c8_128k
board_build.ldscript = STM32F103C8TX_FLASH.ld
build_flags = ${common.build_flags}
  # See Inc/my_machine.h for options
  -D BOARD_CNC3040=
  -D NO_SETTINGS_DESCRIPTIONS=
  -D USB_SERIAL_CDC=1
lib_deps = ${common.lib_deps}
  eeprom
lib_extra_dirs = ${common.lib_extra_dirs}
upload_protocol = stlink

I'll fix this in the next commit.

BTW there are (or were?) 128K C8 marked chinese clones available, the one I had on a redpill left out the magic smoke...

from stm32f1xx.

The board is also called JL1 and has an STM32103C8 onboard.

With 128K flash?

Would you know of where I would start for creating this new board definition?

Start with a copy of an existing map file, if you have a schematic you may use that or if not perhaps this message may help to sort out the pins.

PA8 is the default PWM output and uses timer 1 as well, but not the same channel. It is possible to add to/modify the code to use PB0. The STM32F4xx driver has a lot more flexible approach for assigning the PWM output - it could be adapted for this driver but is likely an overkill...

from stm32f1xx.

Be aware that there are clones out there, the chip labeling may not tell the truth...

E.g. I have a CNC board that has a GD32F103C8T6 that I just tried to connect to with the ST-Link utility, but no luck...

FYI I have modified driver.c and .h + all map files and will add this in the next commit. If you have success in running grblHAL you may then make a PR for the map file only.

from stm32f1xx.

Minimum config is 3 axes.

from stm32f1xx.

Doh, you posted a link to the code... it's a grblHAL thing. Got it and thanks.
Not such a big deal as I'm down to 87% of prog space used at 3 axis and Os optimization as opposed to 97% with 4 axis and O2 optimization.

from stm32f1xx.

@terjeio the reason I'm here, grblHAL, is because there's a low cost laser engraver($79) on the market called the JL1 and they use custom firmware and software which won't work with standard grbl senders. The board is also called JL1 and has an STM32103C8 onboard. Now that it appears I have grblHAL built and on my bluepill my next step is to create a new board definition so I can map all the pins. Most likely the troublesome one is going to be the PWM/Spindle which is on pin PB0 which can only use timer 1 or timer 3 from what I'm gleaned so far.

Would you know of where I would start for creating this new board definition? I have the STM32CubeIDE up and running on Linux. Thx

from stm32f1xx.

Ah, you linked to LaserSal on the Lightburn forum and he's who I've been consorting with. He's been going for a grbl32 fork while I thought a better starting place would be grblHAL. I've been keeping him abreast of my progress. He has mapped all the GPIO signals of the JL1 board but has not had any luck moving the Spindle/PWM to PB0.

You mention that PA8 is where the PWM/TIM1/spindle is on the STM32F1xx driver but when I look at the ioc file it is unassigned or atleast the picture of the chip/pins/labels does not show it assigned.

from stm32f1xx.

but when I look at the ioc file it is unassigned

Oops, that .ioc file was not for publication, I'll remove it.

I use a lot direct register access instread of using the STM framework as the framework is often bloated, code for setting up PWM is mostly here and here. Search for SPINDLE_PWM_TIMER in driver.c for the remaining locations. The ST32F4xx driver uses preprocessor assignments in driver.h to make PWM pin assignment more flexible - you may consider this for the F103 driver?

from stm32f1xx.

funny you mention the ioc file as I was just over at https://github.com/shaise/GrblCNC and looked at this original driver code and saw his comment about not using ioc... I was thrown for a loop when I saw this image and noticed the PWM was on PA8 but the UART was not on PA9/PA10(which is working in this repo).

I'm not a very good coder but will see what I can do to move the PWM from PA8 to PB0.

regarding your comment about ST32F4xx driver using preprocessor assignments in driver.h, would you like me to fork your driver and attempt to implement that for the ST32F1xx driver? Since I only have the Bluepill on the bench, not in a machine, I really can't test much other than compiling without errors and entering gcode into the terminal.

from stm32f1xx.

ok so I'm starting in the CubeIDE first and I've done the following to get setup for working on this BOARD_JL1 project:

1. copied cnc3040_map.h to laserJL1.h
2. in driver.h added:
   #elif defined(BOARD_JL1)
   #include "laserJL1_map.h"
3. project symbol changed from BOARD_CNC3040 to BOARD_JL1

I think I'll now be working in laserjl1_map.h(getting pins moved) and driver.h(setting up directives to tweak SPINDLE stuff).

from stm32f1xx.

I had to do something in driver.c also but I have it compiling with no errors or warnings. I just verified the original setup does have pwm on PA8 by connecting my Oscope to it and send G0Sx.x commands. Once I finish with lunch I will upload the new firmware still using PA8, test it then change the port,upload and test PB0. If it works I'll send the pull request for you to look at.

from stm32f1xx.

The changes I made to driver.c, driver.h and new laserJL1_map.h look like they continue to work fine for PA8 for the spindle but when I change the port base to PB and in to 0 I do not see spindle pwm on PB0. I will see what's different between 32F4xx and 23F1xx regarding PB0.

from stm32f1xx.

I will see what's different between 32F4xx and 23F1xx regarding PB0.

IIRC the main difference is how the alternate pin function is selected, F1 has only one alternative.

from stm32f1xx.

I looked at the datasheet and it says that timer 3 and ch 3 were its default. I tried those settings in driver.h but still nothing changed. The datasheet says it can be remapped to timer 1 and ch 2 but I don't know how to do that yet.
FYI, my fork is here: https://github.com/dlarue/STM32F1xx

And looking at the code in driver.c I see lots of "#if SPINDLE_PWM_TIMER_N == 1" which doesn't give me a warm fuzzy feeling about the fact the default timer for PB0 is TIM3_CH3

from stm32f1xx.

I looked at the datasheet and it says that timer 3 and ch 3 were its default.

The default for PB0 is "normal" pin I/O, alternate function for F1 is only TIM1_CH2N, for F4 AF1 to AF3 is mapped to timers - AF1 to TIM1_CH2N.
F1 alternate function is set here in the driver, and here for F4. This means that the symbol SPINDLE_PWM_AF has no meaning for the F1 as the (only) alternate function is always to be selected.

Here is how code is greyed out in driver.h when I change to PB0 in your map file (I have removed SPINDLE_PWM_TIMER_AF as it is not needed). Do you get the same?

from stm32f1xx.

ah so that is what AF stands for, Alternate Function. I removed the setting of xxxx_AF for GPIOB but it had no effect on enabling PWM to work on PB0 pin. Yes, when I define SPINDLE_PWM_PORT_BASE GPIOB_BASE the same switching of active code results on my system.

And as you mentioned, removing the setting of xxx_AF from both sections does still work for PA8.

Also, there doesn't seem to be an Alternate member of GPIO_Init structure. I will have to see where that structure is defined to see how the Alternate feature is enabled on the F1

from stm32f1xx.

Here is the magic command that makes PB0 work:

__HAL_AFIO_REMAP_TIM1_PARTIAL();

I've tested with a minimal program that just enables PWM.

My init code:

  SPINDLE_PWM_CLOCK_ENA();
  
  __HAL_AFIO_REMAP_TIM1_PARTIAL();

  GPIO_Init.Pin = 1 << SPINDLE_PWM_PIN;
  GPIO_Init.Mode = GPIO_MODE_AF_PP;
  HAL_GPIO_Init(SPINDLE_PWM_PORT, &GPIO_Init);

The AFIO remapping should be possible to do with a symbol definition...

from stm32f1xx.

I will look up what that function does and give it a try. Maybe add a #define TIMER_REMAP declaration to the PORT_BASE definition section and a check for it in the init section. I have a busy day so won't get to this until this afternoon earliest. Thanks!

from stm32f1xx.

Here is what I did, since remapping involves two bits for TIM1 - 3:

#if SPINDLE_PWM_PORT_BASE == GPIOA_BASE
  #if SPINDLE_PWM_PIN == 8 // PA8 - TIM1_CH1
    #define SPINDLE_PWM_TIMER_N     1
    #define SPINDLE_PWM_TIMER_CH    1
    #define SPINDLE_PWM_TIMER_INV   0
    #define SPINDLE_PWM_AF_REMAP    0
  #endif
#elif SPINDLE_PWM_PORT_BASE == GPIOB_BASE
  #if SPINDLE_PWM_PIN == 0 // PB0 - TIM1_CH2N
    #define SPINDLE_PWM_TIMER_N     1
    #define SPINDLE_PWM_TIMER_CH    2
    #define SPINDLE_PWM_TIMER_INV   1
    #define SPINDLE_PWM_AF_REMAP    0b01
  #endif
#endif

#if SPINDLE_PWM_AF_REMAP && SPINDLE_PWM_TIMER_N > 3
#error "Timer 4+ pins cannot be remapped!"
#endif

and in driver.c:

  SPINDLE_PWM_CLOCK_ENA();

#if SPINDLE_PWM_AF_REMAP
  AFIO->MAPR |= (SPINDLE_PWM_AF_REMAP << (4 + 2 * SPINDLE_PWM_TIMER_N));
#endif

  GPIO_Init.Pin = 1 << SPINDLE_PWM_PIN;
  GPIO_Init.Mode = GPIO_MODE_AF_PP;
  HAL_GPIO_Init(SPINDLE_PWM_PORT, &GPIO_Init);

Note that I tested this in a small standalone program.

from stm32f1xx.

It worked! pushed updates to my git repo.

from stm32f1xx.

So how do we trim down the firmware size from 111K?

I used Os and N_AXIS 3 which helped but I see a ton of ~800 byte objects for things like maslow, eth, eeprom, etc which aren't enabled in the my_machine.h file. I also see lots of Trinamic objects being built with many over 5K each even though TRINAMIC_ENABLE = 0

5.5K Oct 1 11:15 ./GRBL Driver STM32F103C8/Release/trinamic/tmc2209.o
2.2K Oct 1 11:15 ./GRBL Driver STM32F103C8/Release/trinamic/common.o
5.4K Oct 1 11:15 ./GRBL Driver STM32F103C8/Release/trinamic/tmc2130.o
1.3K Oct 1 11:15 ./GRBL Driver STM32F103C8/Release/trinamic/tmc_interface.o
9.7K Oct 1 11:15 ./GRBL Driver STM32F103C8/Release/trinamic/tmc5160hal.o
8.9K Oct 1 11:15 ./GRBL Driver STM32F103C8/Release/trinamic/tmc2209hal.o
3.2K Oct 1 11:15 ./GRBL Driver STM32F103C8/Release/trinamic/tmc26x.o
9.6K Oct 1 11:15 ./GRBL Driver STM32F103C8/Release/trinamic/tmc2130hal.o
5.4K Oct 1 11:15 ./GRBL Driver STM32F103C8/Release/trinamic/tmc5160.o
736 Oct 1 11:15 ./GRBL Driver STM32F103C8/Release/motors/trinamic.o

from stm32f1xx.

So how do we trim down the firmware size from 111K?

Good question, I managed to shave off a few KB of superfluous code when USB is disabled...

I used Os and N_AXIS 3 which helped but I see a ton of ~800 byte objects for things like maslow, eth, eeprom, etc which aren't enabled in the my_machine.h file. I also see lots of Trinamic objects being built with many over 5K each even though TRINAMIC_ENABLE = 0

The .o files are output by the compiler, what is of interest is the .map file that is output by the linker - the linker only includes functions and data in the final binary that are referenced in active code. However, since grblHAL is a significantly more complex piece of code than the legacy Grbl I am afraid it will not be easy to get the size reduced enough to fit 64K flash.
You may try to go back to an earlier version, even from the initial repo, as the newer settings subsystem and help text is likely to consume a large chunk of flash. No guarantees though as the orginal repo also states that 128K of flash is required...

from stm32f1xx.

Yes, setting USB_SERIAL_CDC 0 did save a bunch of K and so did the Os optimization.
I will look at the map file but I'd thought that if it's generating an object files having any size they were being included in the output. Like I mentioned, lots of trinamic stuff getting built even when Trinamic_enable was 0

I know of a guy who took grbl32 6 axis from which grblHAL was loosely based on and got things working but I thought if I were to do the effort I might as well get onboard a firmware which was being actively developed. I know the old grbl would be 'good enough', I just always think of the community at large on stuff like this.

I just grep'ed the map file for trinamic and sure enough it's in there and lots of functions listed. text.xxx though so maybe it's a bunch of strings.

NO_SETTINGS_DESCRIPTIONS in the build symbols list also reduced the target size a bunch.

from stm32f1xx.

Gotta be something about the build setup since there's an 800 byte odometer.o file being included as seen in the map file.
Stuff like that shouldn't be there when the feature is disabled. Maslow stuff, Trinamic stuff etc all adding up to probably 50K or more.

from stm32f1xx.

Gotta be something about the build setup since there's an 800 byte odometer.o file being included as seen in the map file.

The linker needs to load all .o files to do its job.

E.g. there are no references to the odometer_init function in my map file - do you see that?
FYI the addresses and sizes of functions included in the binary starts after the .isr_vector symbol way down in the file.
Just delete the files/folders with the stuff you do not want to check...

from stm32f1xx.

I verified what you'd stated and it makes sense that the linker would only link code used into the output file.
What I found out from someone who's purchased 2 of the JL1 laser engravers is that one if his has the F103 with 128K of flash and the other has 64K of flash. What this means is if I intend to support the most users it would have to at least fit in 64K of flash.

I will open my JL1 up and determine if it's one of the 128K versions or 64K versions. If it's the 64K I'm SOL moving grblHAL to it. If 128K I'll likely install grblHAL and then start working with the 6-axis usbgrbl which the other guy said he's trimmed down to 50K and has working except for the remapping of PA8 to PB0.

Seems like my next step is to see what machine I have(128K or 64K) and go from there. If 128K then I start remapping GPIO in laserJL1_map.h

from stm32f1xx.

I connected up the ST-Link and it's read-protected but the STMCubeProgrammer claims it's a 128K version so grblHAL will fit on it.

The USB interface does not power the MCU but got DFU mode happening over USB by using the 3.3V from the STLink. The Boot0 pin is pulled low with SMD resistor(R19) and I pulled it to 3.3V from the STLINK with a 'frog poker' but it's just not going to be easy for the average Joe to do this. Too fiddly. Both ST-Link and DFU modes complain about being read-only but a click of a button can fix that.

FYI, it comes programmed with a bootloader and firmware with read-only fuse set so using ST-Link to read would clear all flash. Existing bootloader does decryption on firmware file when uploaded so another PIA to deal with if not doing full ST-Link program.

from stm32f1xx.

I have it mostly working with motion and laser PWM but I'm having a problem with the limit switches since this is a laser with only 2 axis and 2 limit switches but I have to define 3 axes and 3 limit switches so I can not home the machine with $H. $HX and $HY work fine. Since I have to assign a pin to Z_limit it's floating(pulled up) by default and I've not been able to do anything to invert that or atleast the logic that Z limit high is not triggered.

$14 says it's a limit mask but it doesn't seem to work that way or I can't figure out the mask.
$18 controls just the internal pull-up and I have no way to pull down a floating pin.

What am I missing? Oh and I did change DEFAULT_HOMING_ENABLE to 1 and have cycle 0 and cycle 2 = 0 with cycle 1 equal to X_AXIS_BIT|Y_AXIS_BIT

from stm32f1xx.

$14 says it's a limit mask but it doesn't seem to work that way or I can't figure out the mask.

Use $$=14 for info - it is for inverting the control inputs (cycle start, feed hold etc.), not limit inputs.

$18 controls just the internal pull-up and I have no way to pull down a floating pin.

You can invert the individual inputs with $5. Some drivers enables pulldown when pullup is disabled (when the option is available in the MCU).

What am I missing? Oh and I did change DEFAULT_HOMING_ENABLE to 1 and have cycle 0 and cycle 2 = 0 with cycle 1 equal to X_AXIS_BIT|Y_AXIS_BIT

Did you perform a reset of settings with $RST=* after changing the defaults?
BTW most configurations can now be set at run time, set cycle 0 to XY by $44=3 and cycle 1 off by $45=0 - normally there is no need to change the defaults.

If you are using a Windows computer you may use ioSender for configuring the controller.

from stm32f1xx.

Thanks! I had forgot about the homing cycles listed in https://github.com/terjeio/grblHAL/blob/master/doc/markdown/settings.md
as I was building my spreadsheet of defaults($RST=*) settings vs ones I have been modifying. I'd seen it, didn't know what they were and only after digging into code and includes figured out what homing cycles were.
I removed my file customizations and went and tweaked $44 and $45 as you pointed out. Oh, and I tricked the machine by assigning the Z limit to the same pin as X limit so that Z limit would not be always triggered and I don't think it matters if it's triggered when X limit is triggered.

Homing now seems to work fine. And thanks for the help on finding help( ie $$=14 type help ).

from stm32f1xx.

This homes to the corner end stops but all movement is negative from that while my K40 laser all motion is positive from home.
I used G10 L2 P1 X-220 Y-290 to move 0,0 to the Right Front corner and all is well.

from stm32f1xx.

from stm32f1xx.

Is that $22=9?
Also, what app is that showing those settings in that format?

from stm32f1xx.

Is that $22=9?

Yes.

Also, what app is that showing those settings in that format?

ioSender.

from stm32f1xx.

hmm, I guess this desc through me off "$22 - Homing cycle, boolean".

let me guess, ioSender is way better than minicom. LOL
And woo, it's a real sender. Nice except .Net and C# based. Looks good though.

from stm32f1xx.

Is the way to customize the default grbl settings for a particular machine to do something like this in my_machine.h?

// JL1 defaults
#ifdef BOARD_JL1
#define DEFAULT_X_STEPS_PER_MM 80.0f
#define DEFAULT_Y_STEPS_PER_MM 80.0f
#define DEFAULT_Z_STEPS_PER_MM 80.0f
#define DEFAULT_X_MAX_RATE 5000.0f
#define DEFAULT_Y_MAX_RATE 5000.0f
#define DEFAULT_Z_MAX_RATE 5000.0f

#define DEFAULT_X_ACCELERATION 1000.0f
#define DEFAULT_Y_ACCELERATION 1000.0f
#define DEFAULT_Z_ACCELERATION 1000.0f
#define DEFAULT_X_MAX_TRAVEL 220.0f
#define DEFAULT_Y_MAX_TRAVEL 290.0f
#define DEFAULT_Z_MAX_TRAVEL 1.0f

#define DEFAULT_SPINDLE_PWM_FREQ 5000
#define DEFAULT_SOFT_LIMIT_ENABLE 1
#define DEFAULT_HARD_LIMIT_ENABLE 1
#define DEFAULT_HOMING_ENABLE 1
#define HOMING_FORCE_SET_ORIGIN 1
#define DEFAULT_HOMING_FEED_RATE 1000.0f
#define DEFAULT_HOMING_SEEK_RATE 3000.0f
#define DEFAULT_HOMING_PULLOFF 1.0f
#define HOMING_CYCLE_0 (X_AXIS_BIT|Y_AXIS_BIT)
#define HOMING_CYCLE_1 0
#define HOMING_CYCLE_2 0
#endif

from stm32f1xx.

Is the way to customize the default grbl settings for a particular machine to do something like this in my_machine.h?

Short answer: no.

What is possible is to define the symbols on the command line with -D arguments, in Eclipse by creating a board specific build configuration and adding the symbols to Properties > C/C++General > Paths and Symbols > Symbols dialog. Platformio builds also allows defining symbols in the platformio.ini file.

Another option is to make a backup of the settings to a file and publish that - this can be then loaded by the end user. ioSender has support for that.

from stm32f1xx.

I'd like to not require users to do this and there are so many sender interfaces who knows which ones will import and in what format. Since it's a couple of dozen entries it'd be a bit of a pain managing it in the IDE so I think I'll try keeping them in my_machine.h and copy the customized version as my_machine.h-JL1 since I'll soon be working on my_machine.h-JL2

I like keeping the base system as general purpose as possible and still keep it approachable by devs or even non-devs for building. I should work on the PlatformIO build system since that is a quite nice build system and doesn't require a subscription like the STM32Cube tools do.

FWIW, the JL1 laser was recently mentioned on HackaDay because it's inexpensive but also because instead of uploading new firmware, someone re-brained the machine(overkill IMO). The JL2 is on Amazon for $60.

from stm32f1xx.

... and in what format.

The format is just $ commands so it should be supported by all senders if they allow $ commands in gcode files.

What has been on the todo list for a long time is to create a web interface for setting up parameters for a build and generate a binary from that. The interface should allow saving and loading of user defined board profiles as well as using preset profiles per board stored in the github repo alongside the map file. I (and others?) may start work on this soon.

The guy in the Hackaday story had a controller in the spares bin so easy for him to just replace it?

from stm32f1xx.

... and in what format.

The format is just $ commands so it should be supported by all senders if they allow $ commands in gcode files.
I was considering some would export the config as JSON or other XML format and not just a string of $ commands

What has been on the todo list for a long time is to create a web interface for setting up parameters for a build and generate a binary from that. The interface should allow saving and loading of user defined board profiles as well as using preset profiles per board stored in the github repo alongside the map file. I (and others?) may start work on this soon.

That'd be nice. Today, just having my_machine.h loaded as my_machine_$MACHINE_NAME.h would be pretty flexible.
There's already the required _map.h file for a board which could be named $BOARD_MACHINE_NAME_map.h
or something long those lines so that machine configurations can be stored along with various configurations of a board for the different machines. For example, I've used an MKS Sbase v1.3 in a Creality Ender 3 3D printer and also in a K40 laser cutter and it can easily be added to an original cnc3040 which currently is just 8bit grbl on an Arduino Nano.

The guy in the Hackaday story had a controller in the spares bin so easy for him to just replace it?

He's a skilled maker so making cables and knowing how to setup the firmware was likely easy for him.
Most don't have those skills. The JL1 has onboard USB which, with DFU software only requires a momentary jumper between an empty STLink header( V+ ) pin hole and the side of a resistor nearby in order to upload grblHAL firmware.

from stm32f1xx.

the $22=9 worked great! Nice upgrade from std grbl!
And I uploaded grblHAL to the JL2 and I don't know what I was thinking, it's wired exactly the same since it literally uses the same JL1 controller board. I only had to change the homing direction and the working area size compared to what I had setup for the JL1 machine.

Oh and LightBurn exports their grbl config in XML format.

from stm32f1xx.

Just to let you know, I made a small change to Inc/driver.h which just extended the ending of the #ifdef SPINDLE_PWM_PORT_BASE block to include the little bits of SPINDLE setup after the previous #endif location.

from stm32f1xx.

So what I did was export the symbols from the IDE and edited them adding the 2 dozen or so items I needed for the JL1 and JL2 machines. I now have 2 symbols.xml files which I load depending on which machine I'm making the firmware for and that seems to work.

I'm now relooking at the firmware size of 112KB and looking at the map file, removing all before the isr_vector section and I see tons of stuff about usb even though I commented out both:
//#define USB_SERIAL_CDC 1 // Serial communication via native USB.
//#define USB_SERIAL_CDC 0 // Comment out for UART communication.

I also see coolant_control stuff even though it's not enabled: //#define LASER_COOLANT_ENABLE 1
although I doubt that code load is anywhere near the size of the USB stuff. When Sal removed the USB stuff from grbl32 6-axis code base he said the final image size decreased a very large amount.

from stm32f1xx.

I see tons of stuff about usb even though I commented out both:

This is due to the USB interrupt handler still beeing compiled in, fixed in the latest commit.

I also see coolant_control stuff even though it's not enabled

Laser coolant is an addition to the basic coolant handling. The laser coolant plugin is not included in the default source tree so there cannot be any references to the code in that unless you have added it.

from stm32f1xx.

Without USB:

from stm32f1xx.

I see tons of stuff about usb even though I commented out both:

This is due to the USB interrupt handler still beeing compiled in, fixed in the latest commit.

Nice, that dropped off about 5KB

I also see coolant_control stuff even though it's not enabled

Laser coolant is an addition to the basic coolant handling. The laser coolant plugin is not included in the default source tree so there cannot be any references to the code in that unless you have added it.

I definitely did not add any coolant code and I did not define LASER_COOLANT_ENABLE in my_machine.h although I had defined COOLANT BASE and PIN in laserJL1_map.h. Wrapping those definitions with #if LASER_COOLANT_ENABLE leads to a can of worms in driver.c with coolant data structures getting used all over the place. Sometimes wrapped with spindle direction elements and others floating alone between spindle direction elements and other coolant structure elements.

In the my_machine.h that coolant plugin is defined like this:
//#define LASER_COOLANT_ENABLE 1 // Laser coolant plugin. To be completed.

from stm32f1xx.

Wrapping those definitions with #if LASER_COOLANT_ENABLE leads to a can of worms in driver.c with coolant data structures getting used all over the place.

The laser coolant plugin is not part of the default source tree for the F1xx so I there must be some mixup for this to happen.

If you really want to reduce the executable size then there are some bits that can be easily removed and some that could be sinplified.

Can be removed with few code changes:

ngc_params.c
tool_change.c

Can be simplified, or rather replaced with simpler code:

settings.c
report.c
system.c

If these are replaced with code that do not support settings commands and fewer system commands you may reduce the size significantly. If enough to get the size below 64K I do not know...

from stm32f1xx.

Wrapping those definitions with #if LASER_COOLANT_ENABLE leads to a can of worms in driver.c with coolant data structures getting used all over the place.

The laser coolant plugin is not part of the default source tree for the F1xx so I there must be some mixup for this to happen.

I cloned it from git as instructions stated: git clone --recurse-submodules https://github.com/grblHAL/STM32F1xx

I tried it again and both F1xx and F4xx showed lots of COOLANT stuff when I grepped with:
find . -name "*.h" -exec grep -i coolant {} ;

My process was based on the instructions in the grblHAL Wiki since that seems to be where the docs are.
https://github.com/grblHAL/core/wiki/Compiling-GrblHAL

from stm32f1xx.

Ok so I tried it another way which was to get the driver and then get core.

git clone https://github.com/grblHAL/STM32F1xx
cd STM32F1xx
git clone https://github.com/grblHAL/core grbl

I then pulled over drive.c, drive.h, my_machine.h, laserJL1_map.h, fixed up platformio.ini a little bit and built it in PlatformIO to 108k

I built and upload it to a bluePill and it looks good. I'll next try on the JL1 controller/machine and see if it runs as it did using STM32CubeIDE. It's not 64K but it is a slimmed down source tree and better to start here.

from stm32f1xx.

I added a bunch of #ifdef TOOL_CHANGE_ENABLE to ./grbl/grbllib.c ./grbl/motion_control.c ./grbl/settings.c ./grbl/machine_limits.c ./grbl/system.c and saved 3K of flash space.

from stm32f1xx.

I finally got to try the platformIO build on my machine and movement all works as expected but the laser control is INOP.

My bad, I was trying to test the laser with $rst=*; $h; g0x-50; m3 s20; and it was not working.
I found out that if I use g1 f1000; m3 s20; the laser will take m3/m5/sxxx commands repeatedly.

FYI, I tried the same toolchain CubeIDE is running 10.3( platform_packages = [email protected] ) instead of the default of 7.2.1 and it built a larger firmware(111K) while 7.2.1 builds 108K.

from stm32f1xx.