Oh yeah, that explains my issue. I definitely ran into that issue
where I have checked and had no reason to believe I was doing
something wrong, yet, when I evacuated each switch to a function, the
switch worked correctly. But neither scoping with an anonymous scope
nor renaming the variables work.

The reason I used the switch was that I read on stackoverflow at one
point and someone said that we should use switches instead of elseifs
when we have a lot of cases. Then, using switches, the compiler will
be able to (at some point) create a lookup table for you so it's
faster. I doubt that was what happening at least on the Arduino case.
You'll need a giant lookup table which the uCs don't have memory for.
I suspect that in a lot of cases, using switches is probably just as
slow as using elseifs. Now as I see that it is so buggy, I probably
will not use switches, at least on Arduino.

Cheers,
- Huan.

On Tue, Jun 30, 2020 at 9:23 AM Brian via TriEmbed
<[email protected]> wrote:
>
> Side note:
>
> The arduino compiler has bugs in how it handles switch statements.  I've
> run into situations lately where the order of the case statements matter
> (which it never should); cases are completely ignored, etc.
>
> I believe it may be tied to the use of local scoping within a case, e.g.:
>
> switch(thing) {
>     case 1:
>        {
>           // stuff with case-local scope
>        }
>        break;
> }
>
> Syntactically- and semantically-correct code has proven to generate
> incorrect runtime results.
>
> I haven't had time/motivation to submit a bug report, but I should do
> that.  At any rate, a potential workaround is to reorder your cases.
>
> -B
>
> On 6/24/20 9:51 PM, Huan Truong via TriEmbed wrote:
> > Thanks Pete!
> >
> > I feel like there was something really mysterious about the switch 
> > statement. Even if I pasted the whole blocks of code of each function I 
> > would have called to the {} inside a case, the code still wouldn’t work. 
> > That baffled me by a mile.
> >
> > But yeah, I spent way too much time on the project that I’m comfortable 
> > with the idea of not understanding some of it now. The watchdog timer code 
> > was baffling too.
> >
> > Please excuse my typos, sent from phone.
> >
> > On Jun 24, 2020, at 10:14 AM, Pete Soper via TriEmbed 
> > <[email protected]> wrote:
> >
> > What a beautifully presented adventure. Loved reading it. And when you say 
> > a problem "could be bad" you make your point. :-) (meant as a "find Waldo" 
> > exercise for alert readers)
> >
> > Hadn't heard of "kev" or any other Arduino emulator for that matter. That 
> > aspect was interesting too.
> >
> > The other issue with redeclaration of the vars local to the switch 
> > statement is that they literally don't exist outside it, so communicating 
> > their values outside the block would be difficult. :-)  In general, every 
> > {} defines a local scope in C/C++ and you can declare variables inside that 
> > scope but they cease to be defined outside the scope. The scope outside any 
> > {} (aka "global") or vars declared "static" can avoid this issue but not 
> > the redefine issue.
> >
> > Thanks for sharing this!
> >
> > Pete
> >
> >
> >> On 6/24/20 12:43 PM, Huan Truong via TriEmbed wrote:
> >> This has taken me way more time than I thought, but finishing this
> >> retrofit is a big achievement for me. It's really silly and serves
> >> exactly no purpose other than RE'ing something no one cares about.  So
> >> I just want to share for some shits and giggles.
> >>
> >> http://www.tnhh.net/posts/adventures-hacking-fake-vivitar-vintage-radio.html
> >>
> >>
> >>
> >>
> >>
> >
> > _______________________________________________
> > Triangle, NC Embedded Computing mailing list
> >
> > To post message: [email protected]
> > List info: http://mail.triembed.org/mailman/listinfo/triembed_triembed.org
> > TriEmbed web site: http://TriEmbed.org
> > To unsubscribe, click link and send a blank message: 
> > mailto:[email protected]?subject=unsubscribe
> >
> >
> > _______________________________________________
> > Triangle, NC Embedded Computing mailing list
> >
> > To post message: [email protected]
> > List info: http://mail.triembed.org/mailman/listinfo/triembed_triembed.org
> > TriEmbed web site: http://TriEmbed.org
> > To unsubscribe, click link and send a blank message: 
> > mailto:[email protected]?subject=unsubscribe
> >
>
>
> _______________________________________________
> Triangle, NC Embedded Computing mailing list
>
> To post message: [email protected]
> List info: http://mail.triembed.org/mailman/listinfo/triembed_triembed.org
> TriEmbed web site: http://TriEmbed.org
> To unsubscribe, click link and send a blank message: 
> mailto:[email protected]?subject=unsubscribe
>


-- 

Huan Truong
www tnhh.net / twitter @huant

_______________________________________________
Triangle, NC Embedded Computing mailing list

To post message: [email protected]
List info: http://mail.triembed.org/mailman/listinfo/triembed_triembed.org
TriEmbed web site: http://TriEmbed.org
To unsubscribe, click link and send a blank message: 
mailto:[email protected]?subject=unsubscribe

Reply via email to