Most annoying bug....

[rollatorwieltje]

Spot the difference. View at 1:1 scale from the distance you'd normally view a screen full of code!

Looks like that garbage font Microsoft introduced in Windows Vista. I think it's called Segoe or something like that. I pretty much use Dina everywhere: https://www.donationcoder.com/Software/Jibz/Dina/

Hrm. I'd not seen Dina before, and I like one thing about it - it makes the classic 1I|l 0O distinction better even than my current preferred font (Terminus). I want that. Problem is, I find the rest of the font very tedious to look at. It's ugly.

But then, I'm insanely picky about fonts. Maybe sometime I'll make myself a modified Terminus - pull in those Dina-style 1I|l 0O, and pull in the 9pt bold from Terminusmod, at least.

Dina 9pt feels to narrow for me, I mostly use 10pt (on a 22" full hd monitor), sometimes 8pt. And on a dark background whenever possible.

[Wilksey]

No.  XC8 is based on the HiTech PICC and PICC18 compilers (Microchip bought HiTech), but XC16 and XC32 are based on GCC.

Ah, OK, 1/3rd right anyway

[krish2487]

Try the source code pro font family from Adobe.
I believe that this particular font family was designed to clearly distinguish between
i I l L 1 ! o O 0 and the similar.

PS: It is also easy on the eyes as a terminal font.


Quote from: c4757p on Today at 12:52:59 AM

>

[max_torque]

One bug that i know about, that just seems to get me time after time is the "Spi jumps into slave mode" one on AVR micros.  Set it up as a spi, master but leave the SS pin as an input (which tends to be my default port setting for unused pins when just messing around on breadboards etc) and if it goes low, the micro jumps to being a slave without some much as a "by your leave".........  fricking annoying!

[ale500]

I remember this bug we were blamed for. Two teams, the "starts" and we. The "stars" blame us, we receive a stream of data, buffer it (double buffer) and give it to the stars' library. Boom crash. They say we overwrite the data (double buffer system with synchronized call to another task). I log every event, which buffer I use to receive and which buffer I give to the other thread... no overwrite over many many cycles... but it crashes at some point. I fire up the debugger and patiently go through the code, optimized C code is quite difficult to follow with a disassembler... after some time I realize what happens... they, the "stars" forgot to initialize a structure where the data would be copied and some fields had old data... Even showing them the problem did not convince them... but they fixed it and there were no more crashes.... I was fortunate enough to have this logging mechanism as it clearly showed that the problem was somewhere else... as someone here says "there are big lies, small lies and what is on the screen of the oscilloscope".
Alignment problems in MIPS32 (PIC32), yeah I found out the hard way too... arm cortex-m3 has no problem with unaligned data...

[amyk]

Spot the difference. View at 1:1 scale from the distance you'd normally view a screen full of code!

I found it pretty quickly because my monitor is not one of those ridiculously high-resolution ones and I can actually see the pixels. (You can thank Apple for that stupid "retina" trend...)

Spot the difference. View at 1:1 scale from the distance you'd normally view a screen full of code!

Jesus Christ, that's bad. Whoever selected that font should be shot, as well as whoever designed it if it was intended for this sort of thing.

Real fonts make those much more recognizable:

I think I use that font too! Is it https://en.wikipedia.org/wiki/Fixed_(typeface) ?

[c4757p]

Terminus.

[Howardlong]

Alignment problems in MIPS32 (PIC32), yeah I found out the hard way too... arm cortex-m3 has no problem with unaligned data...

.... Functionally maybe, but non-functionally, you can expect a hit on performance depending on the circumstances. As a real example (in code rather than data, but the same applies to data), if you use Thumb-2 extensions mixing 16 and 32 bit instructions, and you happen to have a string of adjacent 32 bit instructions straddling the word boundary, this will run significantly slower than the same code word aligned. The same applies to non-word aligned data accesses. Of course if all you're doing are a few byte by byte string manipulations there is no difference, unless it's been optimised to assume word alignment that is!

That doesn't excuse the XC32 string word alignment assumption, that is bad.

So there's no free lunch on ARM, and in the real case I describe of unexplained performance degradation, that took a couple of days to figure out, which is also the reason why any low level embedded programmer should not be afraid to routinely look at the disassembly in memory, even if they never intend to write any assembly language, or indeed understand what's been generated at anything more than a cursory level.

[crispy_tofu]

Spot the difference. View at 1:1 scale from the distance you'd normally view a screen full of code!

  That's horrible.  Looks like the designers were having a nap while doing the l and I...