new functions (#1570): get_vtarget, get_varef, get_fosc, get_sck_period #1574

Ho-Ro · 2023-11-18T10:25:46Z

this is only a proof of concept
declarations for libavrdude, parser in term.c
sample implementations in stk500v1.c

MCUdude · 2023-11-19T18:59:24Z

Thanks for the PR @Ho-Ro, a very welcome PR! I'll go through it soon. However, we should also look into adding this functionality to the JTAG1, JTAG2, and JTAG3 programmers as well. I'm sure it's very similar to how you did the stk500 and stk500v2 implementation.

MCUdude · 2023-11-19T20:35:25Z

I'm getting this error when trying to read the ISP clock speed using an STK500 board running v2 firmware.

$ ./avrdude -cstk500v2 -patmega8515 -P pl2303 -t
avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e9306 (probably m8515)

avrdude: processing -t interactive terminal
avrdude> sck
avrdude error: command failed
avrdude error: unable to get parameter 0xc0
avrdude error: cannot obtain sck duration
avrdude error: (fosc) unable to get sck period (rc = -1)

When using a board that's running v1 firmware, it works just fine.

EDIT:
I can't read the ISP clock speed using the AVRISPmkII either. However, I can if I use the parms command. Strange...

$ ./avrdude -cavrispmkii -patmega328p -t
avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e950f (probably m328p)

avrdude: processing -t interactive terminal
avrdude> parms
Vtarget         : 5.4 V
SCK period      : 8.00 us
avrdude> sck
avrdude error: command failed
avrdude error: unable to get parameter 0xc0
avrdude error: cannot obtain sck duration
avrdude error: (fosc) unable to get sck period (rc = -1)
avrdude> q

avrdude done.  Thank you.

Ho-Ro · 2023-11-19T20:52:12Z

I added get_sck_period() and get_vtarget() for JTAG1 - please check if 2165db8 works.

avrdude error: unable to get parameter 0xc0

Sorry, my fault, I used the wrong stk600 parameter PARAM2_SCK_DURATION, fixed with ecba08d, works again

avrdude> sck
SCK period = 2.2 us

MCUdude · 2023-11-19T20:54:22Z

I see now that the ISP clock frequency is a bit fiddly. You'll have to either use PARAM_SCK_DURATION or PARAM2_SCK_DURATION depending on which programmer is in use.

AFAIK you can't just change PARAM2 to PARAM. Even though it now works the output is wrong:


$ ./avrdude -cavrispmkii -patmega328p -t
avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e950f (probably m328p)

avrdude: processing -t interactive terminal
avrdude> parms
Vtarget         : 5.4 V
SCK period      : 8.00 us
avrdude> sck
SCK period = 6.5 us
avrdude> q

avrdude done.  Thank you.

You should probably copy the implementation from stk500v2_print_parms1 to make sure I works with every programmer, not just the vanilla stk500v2 or avrispmkii.

Ho-Ro · 2023-11-19T21:22:21Z

I think it will need a bigger refactoring: extract the functions to retrieve the values and use these functions in stk500v2_print_parms1 and stk500v2_get_xxx to avoid DRY. Unfortunately I can only check with my original STK500 and the ScratchMonkey. But not today, tomorrow is another day.

Ho-Ro · 2023-11-22T17:39:24Z

I've rebased my PR on the new main and tested with nanoSTK and ScrMo, please have a look if it works for the other stk500v2 based programmer types.

stefanrueger · 2023-11-24T23:03:03Z

Thanks @Ho-Ro. I've had a cursory look at the code,and all looks good (but will do a thorough review once no longer marked as draft).

…sck_period this is only a proof of concept declarations for libavrdude, parser in term.c sample implementations in stk500v1.c Signed-off-by: Martin <Ho-Ro@users.noreply.github.com>

Signed-off-by: Martin <Ho-Ro@users.noreply.github.com>

difficult to test w/o programmer HW (only orig STK500 (v2) and SMo) Signed-off-by: Martin <Ho-Ro@users.noreply.github.com>

difficult to test w/o programmer HW (only orig STK500 (v2) and SMo) Signed-off-by: Martin <Ho-Ro@users.noreply.github.com> # Conflicts: # src/stk500v2.c

Signed-off-by: Martin <Ho-Ro@users.noreply.github.com>

Ho-Ro · 2023-11-26T19:03:10Z

And again rebased on latest main, I will check during the week and un-draft when I'm confident that it works.

Ho-Ro · 2023-11-28T19:21:28Z

I did my last tests, all ok from my side.

MCUdude · 2023-11-28T20:14:58Z

I'll test the PR again.

BTW the whitespaces for the SCK line aren't correct (missing six whitespaces. It is, however, correct in git main.
Would be great if you could go through the rest the the files could correct this in jtagmkI.c, stk500.c and stk500v2.c.

$ ./avrdude -cdragon_isp -patmega328p -t
avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e950f (probably m328p)

avrdude: processing -t interactive terminal
avrdude> parms
Vtarget               : 5.0 V
SCK period      : 32.12 us

MCUdude · 2023-11-28T20:59:54Z

I just rested this PR, again using two separate STK500 board running v1 and v2 firmware. I also tested the PR using an avrispmkii.

Everything works great! The only issue I've found is the missing whitespaces, and different number of decimals between the parms and the new commands.

$ ./avrdude -cavrispmkii -patmega328p -t
avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e950f (probably m328p)

avrdude: processing -t interactive terminal
avrdude> sck
SCK period = 8.0 us
avrdude> parm
Vtarget               : 5.4 V
SCK period      : 8.00 us

stefanrueger · 2023-11-29T08:10:34Z

src/jtagmkI.c

+    *v = 500e3;
+  else if (dur == JTAG_BITRATE_250_kHz)
+    *v = 250e3;
+  else


Would it not be better to have sth like

else if(dur == JTAG_BITRATE_125_kHz) *v = 125e3; else return -1;

AVRDUDE is normally good at checking all possible things that can go wrong. We might also want to sprinkle in a pmsg_error("(reason for returning -1)\n"); when a function couldn't do its job and returns -1. This makes debugging soooo much easier.

stefanrueger · 2023-11-29T08:12:45Z

src/jtagmkI.c

+static int jtagmkI_get_vtarget(const PROGRAMMER *pgm, double *v) {
+  unsigned char vtarget = 0;
+  if (jtagmkI_getparm(pgm, PARM_OCD_VTARGET, &vtarget) < 0)
+    return - 1;


(This is not wrong, but the monadic change sign operator normally isn't followed by a space.)

stefanrueger · 2023-11-29T08:16:51Z

src/stk500.c

@@ -1252,8 +1281,9 @@ static int stk500_set_fosc(const PROGRAMMER *pgm, double v) {
      }
    }
    if (idx == sizeof(ps) / sizeof(ps[0])) {
-      pmsg_warning("f = %u Hz too low, %u Hz min\n", fosc, PDATA(pgm)->xtal / (256 * 1024 * 2));
-      return -1;
+      pmsg_warning("f = %u Hz too low, using %u Hz\n", fosc, PDATA(pgm)->xtal / (256 * 1024 * 2));


Good thinking! I like that the code does the nearest best and warns

stefanrueger · 2023-11-29T08:19:58Z

src/stk500.c

+    return rc;
+
+  if (prescale) {
+  fosc = PDATA(pgm)->xtal / ((cmatch + 1) * 2 * ps[prescale - 1]);


Indentation looks wrong, braces not needed? Would fosc = prescale? ...: ....; be crisper and clearer?

Actually fosc isn't needed either? *v = prescale? ...: ...; would do.

Strange, I will check the indentation, normally gcc warns about such stupid formatting.
But I would stick with the if / else construct (w/o braces, possibly a leftover of my previous more complicated calculation) b/c the ternary is harder to read:
fosc = prescale ? PDATA(pgm)->xtal / ((cmatch + 1) * 2 * ps[prescale - 1]) : 0;

Pro tip: if one of the two branches is trivial then making that the first option aids readability:

*v = !prescale? 0: /* here comes what it really is */;

Thx, I've also seen that fosc is not needed and removed it.

stefanrueger · 2023-11-29T08:28:24Z

src/stk500.c

+  unsigned dur;
+  int rv = 0;
+
+  if ((rv = stk500_getparm(pgm, Parm_STK_SCK_DURATION, &dur))< 0) {


Is the spacing around binary < deliberate? It's a bit unusual to have asymmetric spacing (edit: around a binary operator).

Typo when staring to long at the screen during nighttime (same as above return - 1;). This is the reason that I do an automatic clang-format -i ... before I check in my own projects. And my qtcreator is told to do it automatically when saving.

stefanrueger · 2023-11-29T08:29:51Z

src/stk500v2.c

@@ -294,7 +301,10 @@ void stk500v2_setup(PROGRAMMER * pgm)
  memset(pgm->cookie, 0, sizeof(struct pdata));
  PDATA(pgm)->command_sequence = 1;
  PDATA(pgm)->boot_start = ULONG_MAX;
-  PDATA(pgm)->xtal = STK500V2_XTAL;
+  if (str_starts(pgmid, "scratchmonkey"))


Crisper and clearer in one line, but that's a matter of taste (and it's your decision).

ok, looks good

PDATA(pgm)->xtal = (str_starts(pgmid, "scratchmonkey")) ? SCRATCHMONKEY_XTAL : STK500V2_XTAL;

Looks so much neater, don't you agree? You can even remove the parentheses for the test and the spaces before ? and : to crisp it up:

PDATA(pgm)->xtal = str_starts(pgmid, "scratchmonkey")? SCRATCHMONKEY_XTAL: STK500V2_XTAL;

stefanrueger · 2023-11-29T08:36:40Z

src/stk500v2.c

+    jtagmkII_getparm(pgmcp, PAR_OCD_VTARGET, vtarget_jtag);
+    pgm_free(pgmcp);
+    return b2_to_u16(vtarget_jtag) / 1000.0;
+  } else if (PDATA(pgm)->pgmtype != PGMTYPE_JTAGICE3) {


Elsing a return is a bit unusual. It's defo not needed. And code might look clearer if a clear line is left

if(...) { ... return ...; } if(...) { ... return ...; } return 0; }

fully agree :)

stefanrueger · 2023-11-29T08:37:22Z

src/stk500v2.c

+  case PGMTYPE_STK500:
+    stk500v2_getparm(pgm, PARAM_SCK_DURATION, &sck_duration);
+    return stk500v2_sck_to_us(pgm, sck_duration);
+    break;


Again break after a return is ... unnecessary distraction (many times)

stefanrueger · 2023-11-29T08:38:53Z

src/stk500v2.c

+      return 0.0;
+    if (osc_pscale == 0)
+      return 0.0;
+    else {


Elsing this return looks confusing (to me)

I reworked this part, looks nice and tidy. Normally I'm against multiple returns from a function, but this is probably my old-school thinking (as a result of being socialised with Pascal that has no return, just reaching the end of the function and also due to using compiler with bad data flow analysis (e.g. Turbo C or early gcc 2.something that yells at me "end of function reached w/o return statement"); BUT here it structures much better - thx for insisting.
I still see a little style discrepancy in case/switch indenting - here

case() { switch A: ... switch B: ... }

vs. the non indenting avrdude style

case() { switch A: ... switch B: ... }

but I left it indented - the last switch and the closing brace in one column looks confusing (to me) :)

Yes, flow of control can be a philosophically charged discussion. There are a lot of pros for having one point of return, eg, that is very useful when resourced need to be freed.

And, yes, switch indentation also attracts various schools of thought. One fraction likens the case to if, else and else if role and indentation...

All good, and both are cool. (though one is still cooler 😉)

stefanrueger · 2023-11-29T08:41:44Z

src/stk500v2.c

+    dac = (clock_conf & 0x0ffc) >> 2u;
+    fosc = pow(2, (double)oct) * 2078.0 / (2 - (double)dac / 1024.0);
+    return fosc;
+    break;


The default clause isn't needed as a return 0.0 follows the switch. (Or the latter return isn't needed.)

I like the explicit default better than the implicit. I would better sacrifice the last return.

Sure: your preference.

stefanrueger

Very happy with the code. A few tiny suggestions to improve readability and maintainability. Most pertinent: would appreciate an error message accompanying unsuccessful returns (unless a called function earlier already prints an error). In case things go wrong this is soooo much more helpful when there is an indication where things went wrong: pmsg_error() with -v prints source code file and line number.

stefanrueger · 2023-11-29T08:58:26Z

@Ho-Ro So, yes happy to merge this after you have considered my comments and aligned spacing that @MCUdude found. It is a good addition to the programmer functions and a lot more logical than before. Thanks!

Ho-Ro · 2023-11-29T09:44:00Z

I will push the proposed and discussed changes tonite when I'm back at my devel. laptop.

Signed-off-by: Martin <Ho-Ro@users.noreply.github.com>

Ho-Ro · 2023-11-29T21:38:35Z

So, it was fun and I learned a lot of avrdude's internals!
The starting point was the limited space at my home desk when I wanted to update the firmware of my ComponentTester and looked for a replacement for my space consuming STK500 (+ USB serial cable + power supply), detected the Arduino as ISP, had issues with the EEPROM (because I stupidly named it -c arduino (the EEPROM word addressing pitfall), shortly switched to ScratchMonkey and ended up in hacking my own nanoSTK - but first I got my component tester up and running ;)
Good Night

stefanrueger · 2023-11-29T23:03:18Z

THanks for your contribution @Ho-Ro. Can be merged from my point of view. Unless @MCUdude or @mcuee find something through testing, I will do so soonish.

mcuee · 2023-11-30T00:13:45Z

I'd like to carry out some sanity checking today or tomorrow even though I may not have the right HW to test.

src/jtagmkI.c

MCUdude · 2023-11-30T08:42:20Z

src/jtagmkI.c

@@ -1158,7 +1189,8 @@ static void jtagmkI_display(const PROGRAMMER *pgm, const char *p) {



This is actually my mistake. I just realized that the two lines (in jtagmkI.c):

msg_info("%sICE HW version : 0x%02x\n", p, hw); msg_info("%sICE FW version : 0x%02x\n", p, fw);

has an incorrect amount of spaces. Would you mind removing two spaces for each of them, so they'll look like this instead?

msg_info("%sICE HW version : 0x%02x\n", p, hw); msg_info("%sICE FW version : 0x%02x\n", p, fw);

Just a quick thought: Let the computer do this nasty work. Could a format like this help to maintain an uniform appearance more easily instead of manual space counting?

const int msg_space = 21; msg_info("%s%-*s : 0x%02x\n", p, msg_space, "ICE HW version", hw);

Absolutely. We should probably have done this in the first place.
However, I think this should be done at a global scale, and as its very own PR.
Adding "dumb" spaces is sufficient for the time being. Maybe I'll look into fixing it after 7.3 has been released.

mcuee · 2023-11-30T12:09:50Z

It seems to work fine with my STK500v2 clone running official STK500v2 FW (using ATmega8535 MCU), but with only the programmer portion.

The sequence of the output is not the same.

This PR.

PS>.\avrdude_pr1574 -C .\avrdude_pr1574.conf -c stk500v2 -P COM41 -p m328pb -t
avrdude_pr1574: AVR device initialized and ready to accept instructions
avrdude_pr1574: device signature = 0x1e9516 (probably m328pb)

avrdude_pr1574: processing -t interactive terminal
avrdude> parms
Vtarget               : 5.1 V
SCK period            : 8.7 us
Varef                 : 5.0 V
Oscillator            : 3.686400 MHz
XTAL frequency        : 7.372800 MHz
avrdude> quit

avrdude_pr1574 done.  Thank you.

git main:

PS> .\avrdude_git -c stk500v2 -P ch340 -p m328pb -t
avrdude_git: AVR device initialized and ready to accept instructions
avrdude_git: device signature = 0x1e9516 (probably m328pb)

avrdude_git: processing -t interactive terminal
avrdude> parms
Vtarget               : 5.1 V
Varef                 : 5.0 V
Oscillator            : 3.686400 MHz
SCK period            : 8.7 us
XTAL frequency        : 7.372800 MHz
avrdude> quit

avrdude_git done.  Thank you.

mcuee · 2023-11-30T12:19:36Z

Okay also for AVRISP mkii clone running official Atmel FW but the alignment is a bit off.

Edit: ignore this result as it is not with the latest commit.

This PR:

PS>.\avrdude_pr1574 -C .\avrdude_pr1574.conf -c avrispmkii -p m328pb -t
avrdude_pr1574: AVR device initialized and ready to accept instructions
avrdude_pr1574: device signature = 0x1e9516 (probably m328pb)

avrdude_pr1574: processing -t interactive terminal
avrdude> parms
Vtarget               : 5.2 V
SCK period      : 8.00 us
avrdude> quit

avrdude_pr1574 done.  Thank you.

git main:

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude_git -c avrispmkii -p m328pb -t
avrdude_git: AVR device initialized and ready to accept instructions
avrdude_git: device signature = 0x1e9516 (probably m328pb)

avrdude_git: processing -t interactive terminal
avrdude> parms
Vtarget               : 5.2 V
SCK period            : 8.00 us
avrdude> quit

avrdude_git done.  Thank you.

Ho-Ro · 2023-11-30T13:03:54Z

Tomorrow I'll be back home and can try again with my STK500 (SW v2) if nobody else has this original AVR fossil.

SCK period            : 8.00 us

yikes - where do these two decimals come? - oh, I see, it's from main branch (.\avrdude_git)

mcuee · 2023-11-30T13:29:22Z

@Ho-Ro

Sorry I attached the wrong log for STK500v2, now it is okay, both the git main and this PR shows 8.7us but the sequence is not the same.

For AVRISP mkII, this PR has an issue with alignment. Both this PR and git main show '8.00us'.

Edit: ignore my test results for this PR. I was not using the latest commit. I will update soon.

mcuee · 2023-11-30T13:42:29Z

@Ho-Ro

Sorry I attached the wrong log for STK500v2, now it is okay, both the git main and this PR shows 8.7us but the sequence is not the same.

For AVRISP mkII, this PR has an issue with alignment. Both this PR and git main show '8.00us'.

Edit: ignore my test results for this PR. I was not using the latest commit. I will update soon.

@Ho-Ro
Here are the result with latest commit.

For STK500v2, the sequence of the output is not the same. I tend to think it is better to be consistent with git main in this case.

P> .\avrdude_git -c stk500v2 -P COM41 -p m328pb -qq -T"parms"
Vtarget               : 5.1 V
Varef                 : 5.0 V
Oscillator            : 3.686400 MHz
SCK period            : 8.7 us
XTAL frequency        : 7.372800 MHz
P> .\avrdude_pr1574v1 -C .\avrdude_pr1574v1.conf -c stk500v2 -P COM41 -p m328pb -qq -T"parms"
Vtarget               : 5.1 V
SCK period            : 8.7 us
Varef                 : 5.0 V
Oscillator            : 3.686400 MHz
XTAL frequency        : 7.372800 MHz

No issues with AVRISP mkII. This PR is outputing 8.0us and git main is showing 8.00us. I think this PR is more consistent so it is okay.

PS>.\avrdude_git -c avrispmkii -p m328pb -qq -T"parms"
Vtarget               : 5.0 V
SCK period            : 8.00 us
PS>.\avrdude_pr1574v1 -C .\avrdude_pr1574v1.conf -c avrispmkii -p m328pb -qq -T"parms"
Vtarget               : 5.0 V
SCK period            : 8.0 us

Signed-off-by: Martin <Ho-Ro@users.noreply.github.com>

Ho-Ro · 2023-11-30T16:46:37Z

Also stk500 parameter sequence is now ok.

mcuee added the enhancement New feature or request label Nov 18, 2023

Ho-Ro marked this pull request as draft November 18, 2023 10:31

Ho-Ro force-pushed the get_4_1570 branch 2 times, most recently from 73b0fb9 to 787770f Compare November 22, 2023 15:33

Ho-Ro added 8 commits November 26, 2023 19:39

new functions (avrdudes#1570): get_vtarget, get_varef, get_fosc, get_…

4444ca8

…sck_period this is only a proof of concept declarations for libavrdude, parser in term.c sample implementations in stk500v1.c Signed-off-by: Martin <Ho-Ro@users.noreply.github.com>

fix memory access error, provide 4 get_ functions for stk50v2

29a315c

Signed-off-by: Martin <Ho-Ro@users.noreply.github.com>

get_sck_period() and get_vtarget() for JTAG1

c5e117d

Signed-off-by: Martin <Ho-Ro@users.noreply.github.com>

fix sck typo wrong parameter

d3a1429

Signed-off-by: Martin <Ho-Ro@users.noreply.github.com>

fosc / sck test for most stk500v2 based programmer (except mk3?)

42a7f67

difficult to test w/o programmer HW (only orig STK500 (v2) and SMo) Signed-off-by: Martin <Ho-Ro@users.noreply.github.com>

fosc / sck test for most stk500v2 based programmer (except mk3?)

64c82fd

difficult to test w/o programmer HW (only orig STK500 (v2) and SMo) Signed-off-by: Martin <Ho-Ro@users.noreply.github.com> # Conflicts: # src/stk500v2.c

variable xtal setting; formatting

2ec638f

Signed-off-by: Martin <Ho-Ro@users.noreply.github.com>

update stk500v1 sck display

b438ba5

Signed-off-by: Martin <Ho-Ro@users.noreply.github.com>

Ho-Ro force-pushed the get_4_1570 branch from 44b404c to b438ba5 Compare November 26, 2023 18:41

Ho-Ro marked this pull request as ready for review November 28, 2023 19:19

stefanrueger reviewed Nov 29, 2023

View reviewed changes

stefanrueger linked an issue Nov 29, 2023 that may be closed by this pull request

Certain terminal commands may be confusing #1570

Closed

Last (?) tidying according review from MCUdude and stefanrueger

aaa26d9

Signed-off-by: Martin <Ho-Ro@users.noreply.github.com>

MCUdude reviewed Nov 30, 2023

View reviewed changes

src/jtagmkI.c Outdated Show resolved Hide resolved

MCUdude reviewed Nov 30, 2023

View reviewed changes

parms spacing correction (jtagmkI); parms sequence correction (stk500v2)

af22682

Signed-off-by: Martin <Ho-Ro@users.noreply.github.com>

Ho-Ro mentioned this pull request Nov 30, 2023

Display string alignment instead of "space counting" #1584

Closed

stefanrueger merged commit 633669b into avrdudes:main Dec 1, 2023
10 checks passed

Ho-Ro deleted the get_4_1570 branch December 1, 2023 09:43

MCUdude mentioned this pull request Dec 2, 2023

Terminal mode improvements #1587

Merged

		@@ -1158,7 +1189,8 @@ static void jtagmkI_display(const PROGRAMMER pgm, const char p) {

new functions (#1570): get_vtarget, get_varef, get_fosc, get_sck_period #1574

new functions (#1570): get_vtarget, get_varef, get_fosc, get_sck_period #1574

Conversation

Ho-Ro commented Nov 18, 2023

MCUdude commented Nov 19, 2023

MCUdude commented Nov 19, 2023 • edited Loading

Ho-Ro commented Nov 19, 2023

MCUdude commented Nov 19, 2023

Ho-Ro commented Nov 19, 2023

Ho-Ro commented Nov 22, 2023

stefanrueger commented Nov 24, 2023

Ho-Ro commented Nov 26, 2023

Ho-Ro commented Nov 28, 2023

MCUdude commented Nov 28, 2023 • edited Loading

MCUdude commented Nov 28, 2023

Choose a reason for hiding this comment

Choose a reason for hiding this comment

stefanrueger Nov 29, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

stefanrueger Nov 29, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

stefanrueger Nov 29, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

stefanrueger Nov 29, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

stefanrueger Nov 29, 2023 • edited Loading

Choose a reason for hiding this comment

stefanrueger Nov 29, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

stefanrueger Nov 29, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

stefanrueger left a comment

Choose a reason for hiding this comment

stefanrueger commented Nov 29, 2023

Ho-Ro commented Nov 29, 2023

Ho-Ro commented Nov 29, 2023

stefanrueger commented Nov 29, 2023

mcuee commented Nov 30, 2023

Choose a reason for hiding this comment

Ho-Ro Nov 30, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mcuee commented Nov 30, 2023 • edited Loading

mcuee commented Nov 30, 2023 • edited Loading

Ho-Ro commented Nov 30, 2023

mcuee commented Nov 30, 2023 • edited Loading

mcuee commented Nov 30, 2023 • edited Loading

Ho-Ro commented Nov 30, 2023

MCUdude commented Nov 19, 2023 •

edited

Loading

MCUdude commented Nov 28, 2023 •

edited

Loading

stefanrueger Nov 29, 2023 •

edited

Loading

stefanrueger Nov 29, 2023 •

edited

Loading

stefanrueger Nov 29, 2023 •

edited

Loading

stefanrueger Nov 29, 2023 •

edited

Loading

stefanrueger Nov 29, 2023 •

edited

Loading

stefanrueger Nov 29, 2023 •

edited

Loading

stefanrueger Nov 29, 2023 •

edited

Loading

Ho-Ro Nov 30, 2023 •

edited

Loading

mcuee commented Nov 30, 2023 •

edited

Loading

mcuee commented Nov 30, 2023 •

edited

Loading

mcuee commented Nov 30, 2023 •

edited

Loading

mcuee commented Nov 30, 2023 •

edited

Loading