search

terjeio / grblHAL

This repo has moved to a new home https://github.com/grblHAL
232 stars 90 forks source link

Configuration suggestion #70

Closed phil-barrett closed 3 years ago

phil-barrett commented 4 years ago

Add a way to configure the number of Axes via the driver.h file. A more sweeping suggestion is to move the more common config.h items to driver.h.

By the way, I have a grblHAL building guide for my stuff that I would be willing to adapt to more general use if you want.

terjeio commented 4 years ago

A more sweeping suggestion is to move the more common config.h items to driver.h.

I do not want core settings in the driver.h, a better way is to move the options to the makefile - easier to maintain as there will no longer be a need to change any code files. I have started changing some options already (only set if not already set), it makes it easy to set options if having a proper IDE, eg. for the MSP430F5520 I have changed the serial buffer sizes due to limited RAM:

In stream.h:

#ifndef RX_BUFFER_SIZE
#define RX_BUFFER_SIZE 1024 // must be a power of 2
#endif

#ifndef TX_BUFFER_SIZE
#define TX_BUFFER_SIZE 512  // must be a power of 2
#endif

In the IDE:

bilde

Different options selected -> different makefiles.

For the ESP32 driver some options can be set in the CMakeLists.txt file.

It should be possible to create makefiles for the Arduino IDE as well?

terjeio commented 4 years ago

A killer would be a web page where you select processor, board and options - press a button and a compiled binary magically appears for download...

phil-barrett commented 4 years ago

I get the benefit of the core/HAL split and agree with not mixing them. Though, I think it is a fair argument that the number of axes is a HAL thing.

Your makefile based approach makes sense but for "having a proper IDE". Not sure how that works for Arduino based environments.

A web page interface would be awesome! Not sure how easy that is to do across the different environments. It would certainly make grblHAL a lot easy to use by the average joe.

just-jason commented 4 years ago

A web page like that would be paradise. My mind boggles at how that should work with all the different platforms and IDE s ..... I was caught out by the ESP IDE version last time and it did get me thinking adout using something like Docker with the needed build environments and platform requirements. Just a thought.

terjeio commented 4 years ago

Though, I think it is a fair argument that the number of axes is a HAL thing.

It is also referenced extensively in the grbl core so not so as it is now - N_AXIS has 134 matches there.

Your makefile based approach makes sense but for "having a proper IDE". Not sure how that works for Arduino based environments.

The Arduino IDE should be usable with makefiles, but not sure how. A web page would bypass that problem but then

My mind boggles at how that should work with all the different platforms and IDE s .....

For most of the supported processors a/the gcc compiler can be used - it is a matter of creating a makefile that is usable and having the libraries available. A IDE is not needed for this. Platform does not matter either as the output will be a binary, however linux would be my preferred choice as it would be easier to script than Windows. Or did you mean the MCU platform?

So doable but will require quite a bit of work... I do not know Docker, but Jenkins can perhaps be used?

phil-barrett commented 4 years ago

Yeah, I think you could just create simple scripts to run gcc/ld based on the options set. The http form would spit out the compile/link script. I think this requires the concept of release and beta versions. Keeping at this working against a moving code base could be time consuming.

This brings up something that I've been thinking about - kind of a site that promotes grblHAL and acts as a clearing house for various associated things: boards (open source or commercial), videos, tutorials, maybe a forum and now this. Github is good for collaboration but kind of lousy for presentations and such. Right now, someone interested in learning about grblHAL has the source code and not much else.

phil-barrett commented 4 years ago

By the way, grbl.org was available. Guess who owns it now?

terjeio commented 4 years ago

Guess who owns it now?

;-) Are you prepared to create/maintain the content as well? IMO more hands are needed for keeping the enterprise alive.

phil-barrett commented 4 years ago

No question. Not sure what I'll do with it. Hadn't planned on it at all. I could see something expansive though would start small.

terjeio commented 4 years ago

I starting point for a configuration system could be to introduce a separate global configuration file that contains the user preferences. This should have a predefined name and location and not be updated on a fresh download.

A friendly web application could then be made to create such a file, which later on could be used for an automated build system...

phil-barrett commented 4 years ago

THAT is a great idea! Perfection would be a single binary build that is customized by the config file (grbl.ini? showing my old-schoolness) but that's way too much for quite a while. Even baby steps would be welcome.

Would the sender transmit the preferences?

terjeio commented 4 years ago

Would the sender transmit the preferences?

I believe you misunderstood, by download I meant downloading from github. When writing to the MCU that is uploading as I understand it. My idea was to have a global .h that sets configurations and if not provided the defaults are applied. A small problem may be that IIRC, the c preprocessor has no command for #including a file if it exists and ignore it if not.

I do not think creating a fully at runtime configurable binary is desirable, it is likely to add overhead and would be a nightmare to code and maintain. I have moved a lot of #define configurations in the core to $-settings, but only those that makes sense - I left configurations that will affect performance or is rarely changed as is.

I need to read up on how github works, I would like it to work like subversion where I can define "externals" - when I check out a driver all the relevant code (grbl core and plugins) is automatically added.

I can give you read access to my subversion repository if you want access to the bleeding edge code and to see how externals work. If you want to try you can use TortoiseSVN to check out and update drivers.

phil-barrett commented 4 years ago

Ah... I get that fully dynamic settings would be a huge change to the code.

Still a "global settings" include is a good idea. Just have a default globalsettings.h that is empty as part of the project.

After having used more traditional (er, old school?) revision control systems in the past, github seems quite strange to me.

I would like to take a look at your svn repo. Not sure I will modify drivers any time soon, though.

terjeio commented 4 years ago

Just have a default globalsettings.h that is empty as part of the project.

Ideally this file should not be overwritten when the local copy is updated from the github master. I believe easy to do for Eclipse based drivers by using include path priority, not so for the Arduino IDE based ones.

I would like to take a look at your svn repo.

Email with details sent.

phil-barrett commented 3 years ago

This issue is obsolete due to the extensive revamping of the configuration system.