On Jul 1, 2020 at 9:13 AM, <Scott Hall via TriEmbed
<mailto:[email protected]>> wrote:
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] <mailto:[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 <mailto:[email protected]>
*Sent: *Tuesday, June 30, 2020 9:04 PM
*To: *Jon Wolfe <mailto:[email protected]>
*Cc: *Brian <mailto:[email protected]>; Triangle
Embedded Computing Discussion <mailto:[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] <mailto:[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 <mailto:[email protected]>
*Sent: *Tuesday, June 30, 2020 12:48 PM
*To: *Brian <mailto:[email protected]>
*Cc: *Triangle Embedded Computing Discussion
<mailto:[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] <mailto:[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] <mailto:[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]
<mailto:[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]
<mailto:[email protected]>?subject=unsubscribe
> >
> >
> > _______________________________________________
> > Triangle, NC Embedded Computing mailing list
> >
> > To post message: [email protected]
<mailto:[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]
<mailto:[email protected]>?subject=unsubscribe
> >
>
>
> _______________________________________________
> Triangle, NC Embedded Computing mailing list
>
> To post message: [email protected]
<mailto:[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]
<mailto:[email protected]>?subject=unsubscribe
>
--
Huan Truong
www tnhh.net <http://tnhh.net> / twitter @huant
_______________________________________________
Triangle, NC Embedded Computing mailing list
To post message: [email protected]
<mailto:[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]
<mailto:[email protected]>?subject=unsubscribe
_______________________________________________
Triangle, NC Embedded Computing mailing list
To post message: [email protected]
<mailto:[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]
<mailto:[email protected]>?subject=unsubscribe
_______________________________________________
Triangle, NC Embedded Computing mailing list
To post message: [email protected] <mailto:[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]
<mailto:[email protected]>?subject=unsubscribe
--
Scott G. Hall
Raleigh, NC, USA
[email protected] <mailto:[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
