[Improvement] Need to update naming for the Generic Node project tree.

[azerimaker]

Summary:

Since we are sticking with the "Generic Node" name, we should clear "ST-node" name from old project files and folder names.

Why do we need this?

I just pushed battery holder files with a new name: Generic_Node-BatteryHolder, and currently the respective branch looks like this.

What is missing? What do you want to see?

Since the first (prototype) design and the upcoming versions use different enclosure, I think it's good idea to separate them as Prototype and Production designs. All the subsequent and minor design changes will be updated inside the Production folder.

How do you propose to implement this?

I propose following naming (open for other suggestions):

• Generic_Node-Prototype
• Generic_Node-Production
• Generic_Node-BatteryHolder
• Generic_Node-Libs

Acceptance Criteria:

Having this or any other clear naming convention will clear any confusion for us and other users in the future.

[elsalahy]

I have multiple comments on this:

1. GENERIC_NODE_ should be replaced with GN_
2. Folder names should not have the prefix unless it is needed to separate it from other components, for example multiple BSPs, then you differentiate it with a GN_BSP
3. I don't agree with having two folders, one for prototype and one for production, as production is just a release tag in git. Changes in the design should be reflected in the file versions and we should not have duplicate files that confuse the user.

I mentioned this before here that using a folder name with V0.1 is going to cause issues in the long run.

We need to follow a more professional git attitude in order to have a high quality output.

For now here is my recommendation: Three folders:

1. sch
2. pcb (this contains two subfolders stm32wl_board and bopla_battery_holder_board)
3. lib

This will allow you to expand for the LR1110 and SAMR34 boards in the near future

And if you want, you can add a README file beside them to briefly explain what each folder contains, similar to what I do in lib and app

Please let me know what you think about this and we can adjust to fit your development style

[johanstokking]

I have little to add to @elsalahy; please use Git tags for versioning and if a prototype is ahead of production code, then indeed use branches for that.

[johanstokking]

Loop me in if there's anything I should do here with the repository.

[azerimaker]

GENERICNODE should be replaced with GN_

✔️

For now here is my recommendation: Three folders: sch pcb (this contains two subfolders stm32wl_board and bopla_battery_holder_board) lib

❌ This unfortunately won't work, because KiCAD project tree only works if the sch and pcb files are inside the same project folder. Can be like this: project_name/ ├─ sch_file ├─ pcb_file ├─ project_related_subdirectories/gerbers/etc.

☑️Therefore, I suggest following: Hardware/ ├─ gn_battery_holder/ │ ├─ sch_file │ ├─ pcb_file │ ├─ project_related_subdirectories/gerbers/etc. ├─ gn/ │ ├─ sch_file │ ├─ pcb_file │ ├─ project_related_subdirectories/gerbers/etc. ├─ libs/ │ ├─ sch_lib_file │ ├─ pcb_footprints_file │ ├─ lib_subdirectories/3Dpackages/etc.

[elsalahy]

Ok, please consider the following points:

1. We should not structure the whole repo because a tool works in a specific way, KiCAD is just one of the many tools used for HW design, by that analogy I should just structure an entire repo to make it work with Eclipse or CMAKE

2. My proposal still stands and considered best practice by multiple KiCAD HW developers, please take a look at some of the articles and repo structures found in the list below

https://medium.com/inventhub/better-manage-kicad-projects-using-git-8d06e1310af8 https://github.com/im-tomu/tomu-hardware https://github.com/aderusha/HASwitchPlate https://github.com/z2amiller/sensorboard https://github.com/jpconstantineau/ErgoTravel

3. I had the intention for sch to contain the output pdf of the schematics to make it super easy for any one to read the schematics and not dive so deep into the each KiCAD project hierarchy just to get the output.

4. I noticed most developers have a different gerber folder unrelated to the KiCAD project PCB folder

5. again, if the whole repo is called Generic node, does it make sense to add the prefix?

Let's find together the most suitable folder structure for our community, but I don't want to keep rearranging the folders later because we are unfamiliar with git-KiCAD best practices.

[elsalahy]

Now that the HW part is sorted out, we have twp remaining tasks:

1. Update the SW tree naming (Ahmed is responsible)

2. Rename the repo (@johanstokking is responsible)

   With regards to 1:

We settled on the name Generic Node Sensor Edition which can be shorted to GN_SE or GNSE For the SW it will only affect the board support package naming prefix which is currently STNODE

example: currently we have

STNODE_BSP_LED_Init()

and it could be

GNSE_BSP_LED_Init()

or

GN_SE_BSP_LED_Init()

I'm ok with either option although I prefer GNSE.

With regards to 2:

We have two options

• Change the repo name to Generic Node Sensor Edition or it's initials
• Change the repo name to Generic Node

if we opt for Generic Node Sensor Edition we will have to create another repo for new designs and BSPs such as GN tracker edition. if we opt for Generic Node we can consider adding multiple HW designs and BSPs to the repo such as GN tracker edition

My problem with general naming such as Generic Node is that it will have a negative impact on many things:

1. When we open source the repo, people with a GNSE will observe a repo with a different name which is very confusing.
2. Marketing and ads linking to the repo will have a different name
3. Managing the firmware and the releases of multiple HW designs will be a big mess similar to Mbed OS repo

So I recommend we name the current repo Generic Node Sensor Edition and create another one for any new HW/FW designs such as tracker edition.

@johanstokking and @azerimaker and @wienke need you opinion on this.

[johanstokking]

I'm ok with either option although I prefer GNSE.

I agree

My problem with general naming such as Generic Node is that it will have a negative impact on many things:

1. When we open source the repo, people with a GNSE will observe a repo with a different name which is very confusing.
2. Marketing and ads linking to the repo will have a different name

I think we can pretty easily clarify this with a good README.

3. Managing the firmware and the releases of multiple HW designs will be a big mess similar to Mbed OS repo

This is indeed a compelling argument.

But there will be quite some shared code between the Generic Node Tracker and Sensor Edition? Or not at all?

[elsalahy]

I agree

Nice! GNSE sounds really good.

But there will be quite some shared code between the Generic Node Tracker and Sensor Edition? Or not at all?

I think it will be different,

• It will use a different target STM32L4, so target folder will be different
• It will use the original LMN or Semtech Firmware without a lot of adjustment, unlike the WL chip.

So in a way it is similar, but I think it will have a a totally different set of basic apps and configurations.

I was thinking that if we name it Generic Node Sensor Edition it can expand in this way (companies can pay us to host/support their module/sensor) and it can should be able to expand to other microcontrollers and modules that share a common goal of building a sensor edition I imagine it's expansion like this

Repository
├── docs
├── Hardware
│   ├── PCB-STM32WL
│   ├── PCB-STM32WL-SEED-module
│   ├── PCB-STM32WL-MURATA-module
│   ├── PCB-SAMR34
│   └── PCB-SAMR34-MURATA-module
├── Software
│   ├── app
└─── lib
    ├── GNSE_BSP
    ├── GNSE_SEED_BSP
    ├── GNSE_MURATA_BSP
    └── DB_BOARD_BSP (if they allow it or any custom target designed by the community)
└─── target
    ├── STM32WL
    └── SAMR34

@johanstokking we can go either way and make it work as we see fit, but i like this idea of having one repo for each device edition as it fits well with how the the designs and development boards get produced.

[johanstokking]

but i like this idea of having one repo for each device edition as it fits well with how the the designs and development boards get produced.

OK

[elsalahy]

@johanstokking whenever you can please update the repo name to Generic Node Sensor Edition or the abbreviations according to company culture and guidelines.

I will take care of the linked issues inside the code once this is done.

[elsalahy]

closed with #84