Hi
I wrote a program for 8266, it has hundreds of lines. I would like to improve it for ESP 32.
Is there any method for efficient management of large programs?
It is difficult to navigate through the code if it is in a single tab. Multiple tabs, file inclusion. Some suggestions would be nice.
Managing large programs
- cicciocb
- Site Admin
- Posts: 2354
- Joined: Mon Feb 03, 2020 1:15 pm
- Location: Toulouse
- Has thanked: 492 times
- Been thanked: 1657 times
- Contact:
Re: Managing large programs
Hi f1test,
welcome to the forum.
In the current version it is not possible to import external libraries so all the code must be in a single .bas file.
This is something that might be included in the future
welcome to the forum.
In the current version it is not possible to import external libraries so all the code must be in a single .bas file.
This is something that might be included in the future
- Electroguard
- Posts: 1004
- Joined: Mon Feb 08, 2021 6:22 pm
- Has thanked: 332 times
- Been thanked: 371 times
Re: Managing large programs
Hi, my head space cannot cope with hundreds (sometimes over a thousand) lines, so I use some techniques to help a bit.
If the devices are connected via router with different IP addresses, several devices can be connected at the same time, so several different Editor pages open in browser tabs, some looking at copies of the same script.
This allows editing code on a device, while having other editor windows open on other devices showing relevant areas of the same code for reference and copying and pasting from.
Instead of tabs you could have two different device Editors showing the same script in different browser windows side by side, for quick comparison.
I use a different browser for connecting to my annex devices than for internet access.
Over time I have developed a script methodology which helps me to cope a bit better.
I declare all variables at the top of the script before the WAIT (for interrupt events), so I know where to find them and their default values.
I tend not to use unnecessary spaces, eliminating as much unwanted white space as possible, eg: a=a+1 rather than a = a + 1.
This makes it easier to notice deliberately inserted white space in a big mass of code.
When editing a line of code deep in the script that I may need to come back to, I often insert blanks lines before and after it, and insert blank spaces before and after the edit.
This makes it stick out from the rest, and therefore easier to find when scrolling through later.
I leave 2 blank lines after the WAIT, followed by whatever is the latest subroutine I am working on.
When starting another new subroutine it pushes the previous down deeper ... but they are still in ascending order of most recent for quick reference.
I leave 1 blank line between subroutines, but no blank lines inside subroutines, except where I deliberately insert a few blank lines as white space above and below whatever I'm currently working on - it's easier for my brain to pick out white space from a mass of content, making it easier to quickly return to.
Any subroutines I'm not working on but may need to refer to, I put down at the bottom of the script, where I can quickly reach whenever needed.
Unless it is a complicated existing old subroutines which I have decided to redo again from scratch, in which case I keep the renamed old subroutine (which is no longer referenced by the script) underneath its new replacement - not just for referring to, but in case I may need to rename it to reuse it again for some reason. No need to delete the old renamed subroutine until I am confident I will no longer need.
Any subroutines that are finished and not expected to be referred to, I can bury in the middle of the script and forget about them.
I plainly mark the last line of the script to make it obvious if the script has somehow become truncated and corrupted
'--------- END --------
After the END line I sometimes put other code not referenced in the script but which I may need to refer to, which I will delete when done.
This might be commented out code from other scripts, or commented notes such as a list of all the scripts subroutine names or other reminders.
Good luck.
If the devices are connected via router with different IP addresses, several devices can be connected at the same time, so several different Editor pages open in browser tabs, some looking at copies of the same script.
This allows editing code on a device, while having other editor windows open on other devices showing relevant areas of the same code for reference and copying and pasting from.
Instead of tabs you could have two different device Editors showing the same script in different browser windows side by side, for quick comparison.
I use a different browser for connecting to my annex devices than for internet access.
Over time I have developed a script methodology which helps me to cope a bit better.
I declare all variables at the top of the script before the WAIT (for interrupt events), so I know where to find them and their default values.
I tend not to use unnecessary spaces, eliminating as much unwanted white space as possible, eg: a=a+1 rather than a = a + 1.
This makes it easier to notice deliberately inserted white space in a big mass of code.
When editing a line of code deep in the script that I may need to come back to, I often insert blanks lines before and after it, and insert blank spaces before and after the edit.
This makes it stick out from the rest, and therefore easier to find when scrolling through later.
I leave 2 blank lines after the WAIT, followed by whatever is the latest subroutine I am working on.
When starting another new subroutine it pushes the previous down deeper ... but they are still in ascending order of most recent for quick reference.
I leave 1 blank line between subroutines, but no blank lines inside subroutines, except where I deliberately insert a few blank lines as white space above and below whatever I'm currently working on - it's easier for my brain to pick out white space from a mass of content, making it easier to quickly return to.
Any subroutines I'm not working on but may need to refer to, I put down at the bottom of the script, where I can quickly reach whenever needed.
Unless it is a complicated existing old subroutines which I have decided to redo again from scratch, in which case I keep the renamed old subroutine (which is no longer referenced by the script) underneath its new replacement - not just for referring to, but in case I may need to rename it to reuse it again for some reason. No need to delete the old renamed subroutine until I am confident I will no longer need.
Any subroutines that are finished and not expected to be referred to, I can bury in the middle of the script and forget about them.
I plainly mark the last line of the script to make it obvious if the script has somehow become truncated and corrupted
'--------- END --------
After the END line I sometimes put other code not referenced in the script but which I may need to refer to, which I will delete when done.
This might be commented out code from other scripts, or commented notes such as a list of all the scripts subroutine names or other reminders.
Good luck.
You do not have the required permissions to view the files attached to this post.
Re: Managing large programs
Interesting idea, to use several devices to generate a single code.
Thank you for the advice
Thank you for the advice
- Electroguard
- Posts: 1004
- Joined: Mon Feb 08, 2021 6:22 pm
- Has thanked: 332 times
- Been thanked: 371 times
Re: Managing large programs
It's not so much using multiple devices to generate code, more a matter of having an original source device (your esp8266) to reference for copying from as you generate your newer version on the esp32 device.
In my case, rather than starting new projects from scratch, I keep available any of the existing projects which I may need to collate code snippets from.
In my case, rather than starting new projects from scratch, I keep available any of the existing projects which I may need to collate code snippets from.
Re: Managing large programs
I tend not to used the built in editor except for small edits, I have found in the past I have got myself into trouble keeping my original code files up to date, so i have generally used an external editor and cut and past to upload code to the ESP device.
However since the introduction of the Local Save and Load buttons in the latest Annex versions, I have stumbled across a very satisfactory method for updating and loading code.
Being also a MMBasic coder for many years I have used the excellent MMEdit (written by Tassy Jim (Jim Hiley) of the Back Shed) as my main editor, Jim now has a Multi Window version of MMEdit which also works well as an editor for Annex RDS. MMEdit has many great features but one of its really welcome functions is its ability to "insert" code files , so making the addition of routines, code snippets or complete libraries quite easy, the included files may also have a ".inc" file extension. https://www.c-com.com.au/MMedit.htm
So to make the operation relatively seamless you will need to set the option in your browser regarding where you save downloads, to "Ask", this way you can nominate the folder you are currently using for your code. I use Firefox but I think all browsers will allow this, I also use windows but I assume Linux has a similar arrangement? So now you edit your code in MMEdit, save it locally then from the ESP editor you click the "Load a file from local computer" button, select your code file , load and save the file in the ESP. Simple edits can ofcourse be made directly on line and then the original file on your computer can be updated using the "Save a file to the local computer" button, you will need to reload your local copy of course.
There may be some tricks to this method but so far for me I think it is a very satisfactory arrangement.
Mike
However since the introduction of the Local Save and Load buttons in the latest Annex versions, I have stumbled across a very satisfactory method for updating and loading code.
Being also a MMBasic coder for many years I have used the excellent MMEdit (written by Tassy Jim (Jim Hiley) of the Back Shed) as my main editor, Jim now has a Multi Window version of MMEdit which also works well as an editor for Annex RDS. MMEdit has many great features but one of its really welcome functions is its ability to "insert" code files , so making the addition of routines, code snippets or complete libraries quite easy, the included files may also have a ".inc" file extension. https://www.c-com.com.au/MMedit.htm
So to make the operation relatively seamless you will need to set the option in your browser regarding where you save downloads, to "Ask", this way you can nominate the folder you are currently using for your code. I use Firefox but I think all browsers will allow this, I also use windows but I assume Linux has a similar arrangement? So now you edit your code in MMEdit, save it locally then from the ESP editor you click the "Load a file from local computer" button, select your code file , load and save the file in the ESP. Simple edits can ofcourse be made directly on line and then the original file on your computer can be updated using the "Save a file to the local computer" button, you will need to reload your local copy of course.
There may be some tricks to this method but so far for me I think it is a very satisfactory arrangement.
Mike
Re: Managing large programs
The other thing that I do that could save your sanity is to use Dropbox.
I too edit offline (except for minor fixes) and maintain all my files in a Dropbox folder that is automatically updated. I then copy and paste into Annex. I may copy and paste back if I have updated the working copy for some reason.
Using Dropbox means that I can go back to a previous edit when I have done something silly. Though it may take a bit of a hunt through many versions if you do a lot of edits. My Dropbox account keeps every saved copy for a month (I think, not having searched for anything more than a day or two old).
Every time I want to make a substantial change from a working version I save with an updated name, so I always have the undamaged most recent working version. Therefore I have every version ever saved kept offline and protected.
All very simple but good to have some discipline and a safety net.
I too edit offline (except for minor fixes) and maintain all my files in a Dropbox folder that is automatically updated. I then copy and paste into Annex. I may copy and paste back if I have updated the working copy for some reason.
Using Dropbox means that I can go back to a previous edit when I have done something silly. Though it may take a bit of a hunt through many versions if you do a lot of edits. My Dropbox account keeps every saved copy for a month (I think, not having searched for anything more than a day or two old).
Every time I want to make a substantial change from a working version I save with an updated name, so I always have the undamaged most recent working version. Therefore I have every version ever saved kept offline and protected.
All very simple but good to have some discipline and a safety net.
- cicciocb
- Site Admin
- Posts: 2354
- Joined: Mon Feb 03, 2020 1:15 pm
- Location: Toulouse
- Has thanked: 492 times
- Been thanked: 1657 times
- Contact:
Re: Managing large programs
Yes, I included this feature in the todo list.[Local Link Removed for Guests] wrote: [Local Link Removed for Guests]Sun Jun 30, 2024 6:27 am Bumping this thread.
I find it more and more important to have ability to break up large programs into smaller libraries.
S3 modules are now readily available with MegaB of Ram and Flash.
Annex32 Basic is now well mature and stable with many, many features.
I personally, would like to see priority given to looking at options of implementing importation of libraries and functions, to break up management of large programs and functions/subs.
At the moment I am still attracted to Micropython and Arduino C++, mostly for the flexibility of being able to import libraries and functions.
I accept that this would require a major effort by Francesco.
Although, I can assist with modest financial contribution. Would be interesting how many other users of Annex32 Basic would like to see this feature?
An annoying point is that this will require a modification of the partition scheme so, on the modules already flashed, the existing files will be lost. Usefuf for 8+ Mb of flash as the 4MB is already full