TimeLine not always working in my GCSTUDIO environment

[Fabrice Engel]

Good Day Community,

I worked a lot these last days on my project, and I noticed an issue I have with the timeline functionality of GCSTUDIO. Not always every .gcb source file have an active save timeline.

I have that situation mostly with my large .gcb files. For example the case that Anobium processed yesterday for the I2C issue, the test .gcb file have multiple entries in the timeline, but my project various source files (incremented by version in the file name) have no single entry in the timeline.

GCSTUDIO tell me that "No timeline information was provided"

Does someone of you had already that issue ? I would really appreciate to fix that, because it is a big help, and I cannot use it right now for my project.

Thank for advice

[Anobium]

@angel-spartan I have not seen this issue. Is this project related?

[Fabrice Engel]

Maybe I should reinstall fully GCSTUDIO from scratch.
What is the best way to cleanly remove the installed environment ? Does some registry entries must be manually cleaned ?
Thank

[Fabrice Engel]

Hi Community,

to let you know my latest status. I have a computer with pretty fresh Windows installation and where GCBASIC was never installed on. So, I installed latest one (2.019) and made my tests.
I have the same situation as explaned before.
My project code is near 6000 lines long and build for PIC18F16Q41. It uses 75% of Prog memory actually, and I am still not complete with the functionnality I want to build in.

Now another question, can I split the code im multiple files and use includes ?
Would that work for compilation ? That would also help me to navigate in different sections like pushbuttons management, rotary encoder management, Led management, etc...

Thank

[Thomas Henry]

Hi,

Yes, GCBASIC does support spliting a large project into multiple source files, and it works pretty well for what your describing (pushbuttons, rotary encoder, leds etc each in there own file).

The directive you want to try is #insert, not #include. They do diffrent things:

#include <file.h> is for library/header files, resolved against the compiler's library search path (lib folder). Thats what you'd use for things like glcd.h or other GCBASIC library headers.</file.h>

#insert "file.gcb" textually inserts the contents of another .gcb file at that exact point in your source, at compile time. This is the one for breaking up your own code into topic files. The file just needs to sit in your project directory (or you give a full path), and it gets pulled in as if you'd pasted it there.

A practical exemple, from a project of mine on the same line (PIC18F16Q41-class part, large single codebase originaly):

#insert "_SerialSupport.gcb"
#insert "_pwm_setup.gcb"
#insert "_Motion_Handler.gcb"

Each of those is a seperate .gcb file containing one functionnal block (serial/debug output, PWM hardware setup, and the motion state machine). Main file stays short and readable, and each module can be opened/edited on it's own.

Couple things worth knowing before you split your 6000 lines up:

1. Order matters. #insert is a straight textual paste, not a real linker, there's no forward resolution of symbols across files. So a file that uses Ser1Print or a PWM macro needs to be inserted after the file that defines it. Put base/setup modules first, logic that depends on them later.
2. No hidden namespacing. Everything ends up in one flat compile unit, same as if you'd written it all in one file. Watch out for duplicate #define accross your split files, the compiler will warn you. Variable names.. just check that you have them defined.
3. Compile size doesnt change. Spliting files is purely organizational, it doesn't reduce your Prog memory usage. Since your already at 75%, thats still something you'll need to manage seperately (eg trimming debug code, in my project I gate serial logging behind a DEBUG_MOTION flag I can flip off for production builds to shrink the hex).
4. Double check spelling/paths, if #insert cant find the file it just errors out, and the message isnt always the most obvious pointer back to the filename typo.
5. Error handling. The line number will explain where in the inserted file any error is.

So yeah, go ahead and split by function, pushbuttons.gcb, encoder.gcb, leds.gcb etc, and #insert them in dependancy order from your main file. Should make navigation alot easier at your project's size.

Or, use #include. All very similar but the code is NOT inserted and logically the code is optimised and the running order/layout is controlled by the compiler.

Hope that helpsfix it

[Fabrice Engel]

Thank a lot for your good explanation, I will try later, I assume some time needed to do it, as the point with the right position (I am using some sub procedure in multiple blocks, need to learn how to handle it).

[Anobium]

And, use GCODE code folding. You can fold all the subs ( but I would put all the subs into an include file.

[Fabrice Engel]

Hi Community,

To keep you informed about my first issue. Angel bring me the solution today, thank to him, btw, pretty simple.

GCSTUDIO have a max file size limitation per default to 256KB, but my source file is much bigger, near to 600KB (have a lots of comments/explanations inside).

So, to get timeline working again, just needed to increase the parameter from 256 to 1024 (I assume I will not reach source file size of 1MB for my GCBASIC projects).

"workbench.localHistory.maxFileSize": 1024