NO NO, DON'T USE GOTO ! Seriously though, this has been a behaviour of the Arduino compiler compilation for a while -- its even mentioned in some Arduino books. The workaround is to have a single function called for each case label and to put the statements desired with the function. This gets optimized to a jump table anyway, so its just a matter of doing this in practice.
On Wed, Jul 1, 2020 at 12:34 AM Jon Wolfe via TriEmbed < [email protected]> wrote: > Yep, GCC has a ton of extensions to C and C++, though they obviously need > careful consideration when using, if it’s work the downside of making the > code less portable. > > > > https://gcc.gnu.org/onlinedocs/gcc-5.2.0/gcc/C-Extensions.html > > > > One of my favorites is local functions. > > > > > > > > *From: *Rodney Radford <[email protected]> > *Sent: *Tuesday, June 30, 2020 9:04 PM > *To: *Jon Wolfe <[email protected]> > *Cc: *Brian <[email protected]>; Triangle Embedded Computing > Discussion <[email protected]> > *Subject: *Re: [TriEmbed] Hacking a fake vintage radio (with Arduino + Pi > 0) > > > I had never heard of the GCC label variable, so I had to google it... wow, > I learned something new tonight! > > > https://stackoverflow.com/questions/1777990/is-it-possible-to-store-the-address-of-a-label-in-a-variable-and-use-goto-to-jum > > > On Tue, Jun 30, 2020 at 8:57 PM Jon Wolfe via TriEmbed < > [email protected]> wrote: > >> >> >> There is a trick you can use with gcc that is a non-standard C construct >> where you can use ‘goto’ and give it a variable containing the address of a >> label. You then create an array of label address and you can then >> dynamically index that array to jump to various locations. I’ve seen it >> used as an optimization technique, and you can also have more control over >> the program flow, though it is using the infamous keyword, Essentially >> though it end up looking pretty much like a switch-case. >> >> >> >> That is really odd about that gcc bug. It’s not like I’ve never seen >> them, but 99.9% of the time when I thought I had found a compiler bug in >> C/C++, it turns out to be something else. (hafl the time one of those >> things that disappears with a “clean/rebuild all”) I remember the Arduino >> /AVR/gcc linker used to have a bug related to 8-bit AVR chips that had more >> than 64KB of flash memory, such as the ATMega 1284. Those chips address by >> 16 bit words not bytes, so 128kb of flash is accessible without trick likes >> far pointers, but the linker would mess up the address calculations >> sometimes I think for interrupt handlers or functions called by interrupt >> handlers that crossed the 64kb boundary. >> >> >> >> >> >> *From: *Huan Truong via TriEmbed <[email protected]> >> *Sent: *Tuesday, June 30, 2020 12:48 PM >> *To: *Brian <[email protected]> >> *Cc: *Triangle Embedded Computing Discussion <[email protected]> >> *Subject: *Re: [TriEmbed] Hacking a fake vintage radio (with Arduino + >> Pi 0) >> >> >> 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 >> >> _______________________________________________ >> 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 > > -- Scott G. Hall Raleigh, NC, USA [email protected] *Although kindness is rarely a job, no matter what you do it's always an option.*
_______________________________________________ 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
