Combining board variations

[bugadani]

Hi!

This is a completely uninformed question, as in I've not tried anything yet. But I'd like to know if it's possible to combine board variations. My example is:

I have a board where multiple parts can be combined in an independent way. Suppose I have three part:

• A power supply, that can be either an LDO or a SMPS.
• A temperature sensor, than can be any of two models
• And an optional humidity sensor

I would like to somehow be able to generate all possible combinations without needing to list a lot of +/- fields in the Config field. I.e, for the humidity sensor I'd like to have a +HUM tag, and I don't want to mention that tag in any of the other 2 features.

Reading the docs, I think I can do something like this by either generating Config field values using some external script, or maybe by using filters, but I'm not sure. However, if either of these work, they aren't ideal in my opinion.

So, the question is: Can I apply multiple variations at the same time? E.g. "Generate output for the HUM, SMPS, TEMP_A variation (again, without me having to declare all the possible combinations in my schematic).

Thanks!

[bugadani]

Additional questions, related to the original:

• Is it possible to generate every configured "output" for every variant? If I have 3 variants, it's rather cumbersome to list every (in my case, 5) output for each. Maintaining the kibot config will become quite difficult, I think, if I have to do this.
• ~Can I use +default and -default as variant markers?~ I tried it, I don't seem to be able to. However, I think it would be advantageous to allow +default instead of requiring -<every single variant>

[set-soft]

1. You can combine variants. Just choose a variants mechanism that allows it. KiBoM and KiCost mechanisms can do it. You just need to think carefully how to tag your components. Please take a look at how each mechanism works and use the one that better suits you. Note that a variant can be a set of features, you can name it production and it be "with LDO, sensor model A and no humidity sensor".
2. You can generate all outputs for each combination. You can pass the variant from the command line and you can use the variant name as part of the destination directory. Take a look at the issues that @mdeweerd opened (most of them closed). He uses KiCost variants and has similar needs.

[set-soft]

BTW: If you can't find a solution make a simple example that shows your situation and put it in a GitHub repo. So I can show you how to solve it.

[mdeweerd]

@bugadani I can confirm that you can because I do!

This is my "general" approach:

• Each function is a variant.
• I apply the variant to components that are impacted by the variant.
• I use a regex for the variant select.

Example of variant fields on components:

1wireOnConn2
5vjack
5vreg,ana5V
5vreg,ana5V,screen5v
64k
FlwOnConn2
ana3V3-inactif
ana5V
bridgedf06
bridgesldb1
clm,lvl2,bornier_lvl12_flw_clm
rtc
rtc.smallcap
rtc.supercap

• 5vreg,ana5V is a component that is selected when the board wants the 5V regulator as a function, or when the analog needs 5V
• 5vreg,ana5V,screen5v is a component that is also selected when the screen needs 5V.
• RTC: rtc = rtc present, variants: with smallcap or supercap or not. rtc.supercap,rtc.smallcap means the component is needed with either supercap or small cap (diode to protect the *cap from discharge).

  rtc
  rtc.smallcap
  rtc.supercap
  rtc.supercap,rtc.smallcap

Then the variant regex looks like (with other options):

VARIANT="^(mot1|1wireOnConn2|connextscl|rtc|rtc.supercap|board_type_tp|button3|screen5v|bridgesldb1|64k|notvneg)$"

I use an Excel file to helsp me create that regex.

And for kibot I declare variants like this:

global:
  output: "%f_%r_%d-%i.%x"
  #dir: "%f_%r_%d%v/"
  out_dir: "%sf_%sr_%sd_%g/"
  date_time_format: "%Y%m%d_%H%M%S"
  date_format: "%Y%m%d"
  time_format: "%H%M%S"
  # kiauto_time_out_scale: 2
  # kiauto_wait_start: 20
  variant: variant_name

variants:
  - name: 'variant_name'
    comment: 'VariantComment'
    type: kicost
    file_id: _VariantPostifx
    variant: "^(inp1screw|inp1|inp1tripAOP|ana5V|mot2|board_type_cp|button3|screen5v|bridgesldb1|64k|notvneg)$"
    pre_transform: 'kicost_rename'

And help me generate/partially generate, I use a makefile with at its core:

MAKEFILE_PATH := $(dir $(abspath $(firstword $(MAKEFILE_LIST))))
VARIANTS=variant_name variant_name2 variant_name3

TARGETS=schematic_color schematic_bw bom ibom position gerbers gerb_drill pdf_pcb pdf_pcb_fab excellon step render_3d_top render_3d_bottom render_2d_top render_2d_bottom kicost

#TARGETS=schematic_color step ibom  pdf_pcb pdf_pcb_fab
#TARGETS=schematic_color schematic_bw
#VERBOSE=-vvvv

TARGETS=render_3d_top render_3d_bottom render_2d_top render_2d_bottom

selected:
        for i in $(VARIANTS) ; do \
             echo $$i ; \
             $(MAKEFILE_PATH)kibot -c PROJECT.kibot.yaml -b PROJECT.kicad_pcb -e PROJECT.sch -g variant=$$i $(VERBOSE)  $(TARGETS) \
             | tee $${i}_build.log ; \
        done

$(MAKEFILE_PATH)kibot is used here because I have a wrapper for kibot to run it inside a docker container, and the wrapper is in the same path as the Makefile. I other scripts I replaced that with something smarter (KIBOT:=...)

[bugadani]

Thank you both for answering. Looks like this is a lot more involved than what I hoped for. I will need some time to sort through everything, I think.

So far the best piece of information I had was this example which helped, but still left a lot to guesswork. Here, for example a link to the actual kibot config would have been helpful, I think.

@set-soft

Please take a look at how each mechanism works

I would like to, but I don't know where to find information. I think this is the basis of most of my problems. The main README hints at lots of things, but for example, the Filters and variants section mainly details the filters, and only points at the example project when it comes to variants.

I will take some time sorting through things, try to apply them to my situation and I'll report back. Thanks for the help!

[bugadani]

Looking at the arduino example, I can't see how the different variants are generated. @mdeweerd's comment indicates that I should use a command line parameter to select a variant, however, it is not documented how I can do this using a github actions workflow, as variant doesn't seem to be passed to kibot in entrypoint.sh.

[bugadani]

@mdeweerd

And for kibot I declare variants like this:

Just to clarify on one point: In your example, the variant: "^(inp1screw|inp1|inp1tripAOP|ana5V|mot2|board_type_cp|button3|screen5v|bridgesldb1|64k|notvneg)$" is a single variant combination, correct? So, you still have to give all these regexes in your config, meaning you have a pontentially large number of items in the variants list, correct?

Your method seems to be pretty close to what I'm looking for, thank you very much for taking the time to explain.

[mdeweerd]

As you want multiple variants, the default variant is not sufficient.

You can just run "kibot" in the directory if your yaml ends in ".kibot.yaml" and the basename is like your project name.

Add -g variant=VARIANT to run for VARIANT.

Regarding the workflow, the one used for ardu_prog is just calling upon make in multiple steps, but one can combine all of them in just make target as I show in my extract above.

It should not be too hard to update that github action.

See https://github.com/INTI-CMNB/kibot_variants_arduprog/blob/master/.github/workflows/kibot.yml#L30-L32 .

[set-soft]

however, it is not documented how I can do this using a github actions workflow, as variant doesn't seem to be passed to kibot in entrypoint.sh.

The action is a very limited option for quick setup. For more complex cases I suggest using a Makefile, like in the ArduProg example. This provides much more flexibility.

[bugadani]

Thanks, I've been able to use a python script to generate kibot configs that suit my needs. I'll face the Makefile bridge if I need anything more complex in the future :)

Thank you both for your help, the kicost style and regexes work quite well.

[set-soft]

it is not documented how I can do this using a github actions workflow, as variant doesn't seem to be passed to kibot in entrypoint.sh.

Now the v2 action supports variant as argument.

[bugadani]

Thank you!