Modify LED error sequence to be more recognisable

[ghost]

Changed the LED error sequence for boards with less than 4 LEDs to be more
recognisable. The new sequence is 4 slow pulses followed by 4 fast pulses.

Fixes #1295 LED error patterns

[0xc0170]

+1 for having this distinct pattern

[theotherjimmy]

@scartmell-arm Could you also remove "ERROR_*" from the device_has keys in targets/targets.json?

[ghost]

@theotherjimmy AFAICT they are still required. There are still two different error sequences, the 4 LED sequence which is run when ERROR_PATTERN key exists, and the fast/slow pulsing one when ERROR_RED key exists. I'm not sure how else you would discern which pattern to use.

[theotherjimmy]

@scartmell-arm From the description of your PR, I would expect to see only one pattern used.

[ghost]

I changed the text to be a bit more clear. Given that the error sequence for 4 LED boards is already easily distinguishable I don't think it would be reasonable to change it so that all boards use the same sequence.

[0xc0170]

@theotherjimmy AFAICT they are still required. There are still two different error sequences, the 4 LED sequence which is run when ERROR_PATTERN key exists, and the fast/slow pulsing one when ERROR_RED key exists. I'm not sure how else you would discern which pattern to use.

I believe @theotherjimmy is up for using one pattern for all, remove not needed ERROR_PATTERN (If i got a new board, which one should I use?). This however needs a big note. Because in case we agree on this, it would change the behavior but unifies it for all boards (most of the boards compile, at least one LED on board).

[theotherjimmy]

@0xc0170 You are correct. I have a hidden (no longer I suppose) agenda to remove those stinking ERROR_* things from targets.json. If you look, my linting tool calls all of them problems.

[0xc0170]

Any voices against having one unified LED error sequence?

[0xc0170]

Why this was closed @scartmell-arm ? Please always provide a reason (for any update, closure, etc)

[ghost]

Sorry, I didn't mean to close this, it closed automatically when I renamed the branch this commit was on in my fork. If it's not possible to amend the branch the PR comes from I'll open a new PR and reference this one.

[theotherjimmy]

@scartmell-arm Why do you want to change the branch name? Could you just rebase this branch and push new changes?

[ghost]

@theotherjimmy Apparently yes.

[theotherjimmy]

To the latter question I suppose.

[theotherjimmy]

OH, this was from your master. I understand closing it. I don't know how I missed that before.

[ghost]

@theotherjimmy Yes, it was making things slightly awkward. There are now two separate PR's with the same commits but coming from different branches. I suppose it would be best to close the other one as this has the original comment chain.

[theotherjimmy]

@scartmell-arm I understand if you would prefer to close this one as it would simplify your workflow. I'll leave it up to you.

[ghost]

Thanks. In which case, closing this PR and continuing the work in #4920