[TriEmbed] Hacking a fake vintage radio (with Arduino + Pi 0)

Tue Jun 30 20:04:20 CDT 2020

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 <
triembed at triembed.org> 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 <triembed at triembed.org>
> *Sent: *Tuesday, June 30, 2020 12:48 PM
> *To: *Brian <triembed at undecidedgames.net>
> *Cc: *Triangle Embedded Computing Discussion <triembed at triembed.org>
> *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
> <triembed at triembed.org> 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 <
> triembed at triembed.org> 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: TriEmbed at triembed.org
> > > 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:
> unsubscribe-TriEmbed at bitser.net?subject=unsubscribe
> > >
> > >
> > > _______________________________________________
> > > Triangle, NC Embedded Computing mailing list
> > >
> > > To post message: TriEmbed at triembed.org
> > > 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:
> unsubscribe-TriEmbed at bitser.net?subject=unsubscribe
> > >
> >
> >
> > _______________________________________________
> > Triangle, NC Embedded Computing mailing list
> >
> > To post message: TriEmbed at triembed.org
> > 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:
> unsubscribe-TriEmbed at bitser.net?subject=unsubscribe
> >
>
>
> --
>
> Huan Truong
> www tnhh.net / twitter @huant
>
> _______________________________________________
> Triangle, NC Embedded Computing mailing list
>
> To post message: TriEmbed at triembed.org
> 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:
> unsubscribe-TriEmbed at bitser.net?subject=unsubscribe
>
> _______________________________________________
> Triangle, NC Embedded Computing mailing list
>
> To post message: TriEmbed at triembed.org
> 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:
> unsubscribe-TriEmbed at bitser.net?subject=unsubscribe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.triembed.org/pipermail/triembed_triembed.org/attachments/20200630/42ccdaeb/attachment.htm>