The tasks I programmed to run aren't running

[SamRuben123]

Well, I almost did it - multitasking is possible, making apps is possible and some others are possible as well. Please check out the link to the code which I posted in my last reply to jimLee.

[pert]

I'm glad to see you making some nice progress on your project @SamRuben123!

I have a question: what is your reason for putting all the code in .h files, rather than using .cpp files as is the more usual approach?

It is sometimes necessary to put code in .h files, but in general you should avoid it if at all possible, using .h files exclusively for declarations.

[SamRuben123]

I believe that it must have been out of my hurrying up .... I didn't think of that. Will it (usage of .cpp files) make things easier for the users (like editing the functions)? If yes, I shall try to find some time and work things out.

I am mostly accustomed to Python (I haven't done that on an RPi) and the usage of .h files to define classes and their functions at the same time seemed to be good for me. That helped me keep track of variables without having to refer another file (as long as the variables/objects were not imported from that file) ; but if you do suggest that I add .cpp files instead of dumping all the code into the header file, certainly I'll get things done as long as my school doesn't reopen.

Also, thanks for your first commit into my repo, sir!

[SamRuben123]

My initial understanding that code can be dumped into the header as well came from Arduios in which the owner of the repo decided to code the sketches to be used in different use cases as header files. Then on I felt that I just dump all code into a single file instead of keeping them separate.

[SamRuben123]

Also, I have renewed the folder tree. Please check it out on Github

[pert]

The problem with having definitions in header files is that when you #include a file, it essentially just copy pastes the contents of that file in place of the #include directive. So if you #include a file with definitions multiple places in your code then you can end up with confusing multiple definition errors.

That can be avoided to some extent through the use of include guards, but that only helps for multiple #include directives within a single translation unit.

As I said, there are cases where there are very good reasons for creating a header-only library. There are some very prominent examples of this, including:

• The official AVR EEPROM library
• Encoder

But it's something you should do when there is good reason for it, not something to default to.

@SamRuben123

like editing the functions

I'm not sure what you mean by that. I'll admit that I haven't taken a close look at your project. If you're asking whether it will make it easier for the users to edit the library's functions, then the answer is no. But it also won't make it harder to do so. A well designed library shouldn't require the user to make any edits, though of course we should always feel free to experiment with code in the spirit of learning and open source when we feel the urge to do so.

A header-only library can offer configurability via the C++ preprocessor, as is the case with the Encoder library. However, the use of preprocessor directives as a user interface should be avoided if at all possible because it makes the code far less user friendly and troubleshooting far more difficult.

@SamRuben123

if you do suggest that I add .cpp files instead of dumping all the code into the header file

I do suggest it, but only because you seem to have expressed some interest in feedback. It may well be that the current approach is perfectly serviceable.

@SamRuben123

My initial understanding that code can be dumped into the header as well came from Arduios in which the owner of the repo decided to code the sketches to be used in different use cases as header files.

Even though the documentation suggests using header files in the sketch, the Arduios library itself uses .cpp files for the definitions. The library's .h files only contain the declarations.

I'm not sure why they recommend the use of .h in the sketch. Here on the forum, some people recommend that because they don't like the Arduino sketch preprocessing. Sketch preprocessing is only done to the .ino files of a sketch so code you put in a .h file is passed directly to the C++ compiler without any changes. In the case of sketches, you're not likely to end up with multiple definition errors because with this approach you'll only be using the .h file in a single translation unit. So putting everything in the .h file avoids the inconvenience you mentioned of managing declarations in one file and definitions in the other.

@SamRuben123

Also, I have renewed the folder tree. Please check it out on Github

I think that's a better project structure. Since you're using a nested folder structure for your source code, if you do decide to start using .cpp files, be sure to change your library to the "1.5" format to enable the Arduino build system to do recursive compilation. This is accomplished by:

• Move the remaining. .h files out of the library's root folder and under the src subfolder
• Add a library.properties metadata file to the library's root folder.

Adding a library.properties metadata file will also be required if you ever decide you want to add your library to the Arduino Library Manager.

[SamRuben123]

@pert

So if you #include a file with definitions multiple places in your code then you can end up with confusing multiple definition errors.

Yeah, I had once encountered that, but luckily I realised the error source later one.

@pert

Adding a library.properties metadata file will also be required if you ever decide you want to add your library to the Arduino Library Manager.

Thanks for that advice too! I had also wanted to have my library up in the Library Manager

@pert

If you're asking whether it will make it easier for the users to edit the library's functions, then the answer is no. But it also won't make it harder to do so.

Well then, that isn't such a necessity in my library, right? I tried to avoid the multiple definition error to my utmost and finally got the simulator working. Also, I understood that I can import a library to any number of headers, but the header into which those headers are included shouldn't include the main header that we import into the previous headers. Also, I have added a bit more of commenting so that reviewers can read through and understand the code.

Thanks for all help (current and upcoming)!

Sam

[SamRuben123]

I have added the library.properties file in the repo.

[SamRuben123]

@pert , I might need a small help: does putting a Python script in the root directory of an Arduino library disable its working? I asked you because I had added a new branch (configurable) to my main repo and then added a Python script to set up the library for the user; and when I tested it (the file got downloaded as MCUOS-configurable), the setup script went well while the RunOS.ino sketch failed to complie.

This is the screenshot of the error

Proof that the library was added.

[pert]

@SamRuben123

does putting a Python script in the root directory of an Arduino library disable its working?

No. It will have no effect on the library.

@SamRuben123

I asked you because I had added a new branch (configurable) to my main repo and then added a Python script to set up the library for the user; and when I tested it (the file got downloaded as MCUOS-configurable), the setup script went well while the RunOS.ino sketch failed to complie.

It was unrelated to the addition of the Python script. You'll find you have the same problem if you use the library from your main branch. Instead, it was caused by this change:

Add files via upload

That changed your library to the "1.5 format", meaning you must use a different structure for the files, as described here:
https://arduino.github.io/arduino-cli/latest/library-specification/#source-code

[SamRuben123]

Which means I'll have to put the MCUOS.h file in src ?

[pert]

That's correct. You'll also need to adjust the paths in your library's #include directives accordingly.

For example, this line:

Coder-X15/MCUOS/blob/245fd78d19a99ce134ea15107ff29342a72ecb4b/MCUOS.h#L4

will need to be changed to:

#include "OS.h"

because MCUOS.h will now be in the same folder as OS.h.

[SamRuben123]

Thanks !! Now it works, except that I have to edit every instance of src

[SamRuben123]

Should the same be done to themain branch as well ?

[pert]

Yes. This was caused by the change to the library format, so it is just as relevant to the main branch as to the configurable branch.

[SamRuben123]

Thanks then, I'll edit it right away.

And please note: today is the last day of the breathing space I got, so maybe I won't always be able to commit to my repo

[SamRuben123]

Yay ! The setup script is working! Now I'd only need to wait for stars, user reviews and more contributions....

Thanks a lot @pert!!!