64K is still quite a lot! Embedded Programming Microthread

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > 64K is still quite a lot! Embedded Programming Microthread

csammis: Aug 26, 2003; Mental Institution

The Radio Shacks around me (suburban Kansas City) all stock the shields and displays and so on but their selection of discrete components is maddening. Only a few different resistor and capacitor values and all the stores in the area seem to have the same stock :smith:

# ¿ Jan 30, 2013 15:42

Adbot: ADBOT LOVES YOU

# ¿ Apr 29, 2024 14:49

csammis: Aug 26, 2003; Mental Institution

Does anyone work with TI's MSP430 line and their open source GCC toolchain?

I'm picking up a project that I haven't touched in three years which was originally built with MSPGCC. I decided to download the new TI toolchain and give it a spin but it's giving me some linker problems which seem to be related to generated code size.

Using the MSPGCC toolchain and -g -Os I get the following from size:

code:

   text	   data	    bss	    dec	    hex	filename
    562	     54	      5	    621	    26d	main.elf

Using the TI toolchain, same compiler flags, no code changes, it won't even link:

code:

~/ti/gcc/bin/../lib/gcc/msp430-elf/5.2.1/../../../../msp430-elf/bin/ld: main.elf section `.text' will not fit in region `ROM'
~/ti/gcc/bin/../lib/gcc/msp430-elf/5.2.1/../../../../msp430-elf/bin/ld: main.elf section `.data' will not fit in region `RAM'
~/ti/gcc/bin/../lib/gcc/msp430-elf/5.2.1/../../../../msp430-elf/bin/ld:
  section __interrupt_vector_3 loaded at [000000000000ffe4,000000000000ffe5] overlaps section .text loaded at [000000000000f984,0000000000010515]
~/ti/gcc/bin/../lib/gcc/msp430-elf/5.2.1/../../../../msp430-elf/bin/ld: region `RAM' overflowed by 80 bytes
~/ti/gcc/bin/../lib/gcc/msp430-elf/5.2.1/../../../../msp430-elf/bin/ld: region `ROM' overflowed by 1516 bytes
collect2: error: ld returned 1 exit status
make: *** [main.elf] Error 1

What the hell? mspgcc is based on GCC 4.5.3 and the version of the TI toolchain I downloaded is based on GCC 5.2.1...I would have hoped the code generation would get better, not shittier. The MCU in question is a MSP430G2231 if that makes a difference.

# ¿ Jan 19, 2016 23:52

csammis: Aug 26, 2003; Mental Institution

JawnV6 posted:

Did the linker script change at all? Or is it pulling some generic description instead of something specific to the G2231?

I'm not sure about MSPGCC. As far as I can tell the only hint that it has that it's looking at a G2231 is the -mmcu=msp430g2231 option. If it's using something specific that seems to be opaque to my Makefile at least.

The TI toolchain was being specifically passed ( via -T) some msp430g2231.ld script that was distributed with the toolchain. Sorry, I forgot to mention that in my first post

The link result is the same whether I pass or don't pass the linker script argument.

edit: my grammar is bad today

csammis fucked around with this message at 00:19 on Jan 20, 2016

# ¿ Jan 20, 2016 00:17

csammis: Aug 26, 2003; Mental Institution

JawnV6 posted:

There should be a header file like msp430g2231.h, make sure it's not grabbing something generic like msp430g2xx1.h. But that's just for SFR's and other chip-specific things, missing that would not cause your current problem and if you're failing linking you're beyond anything in that header.

I was using <msp430.h> but I tried changing it to <msp430g2231.h> just to make sure it wasn't including anything squirrelly. It didn't result in any change to the linker output.

quote:

.ld script is where errors like that come from. All my work was with CCS, so I'm sorta guessing at the mspgcc setup, but is the failing build producing a .map file anywhere? I can't suss out which numbers are wrong, you have 128b/0x80 of actual RAM, in no base is '54' too large to be contained in that by 80. The map file should tell you what's getting put where.

Yeah, I've got maps from both. gist for MSPGCC, gist for TI's msp430-gcc. I've never looked at linker output in this detail but taking a stab at this...

TI's linker is bringing in many more symbols. There's a metric ton of crap in the TI generated .text segment that isn't brought in by mspgcc...looks like TI is bringing in all of libc even though it's not explicitly referenced in code. Okay swell. Adding -nostdlib yields a different linker error:

code:

main.o: In function `hard_delay':
/Users/csammis/Projects/Hardware/MSP430/msp430-zeldachest/src/main.c:20: undefined reference to `__mspabi_divli'

The function in question:

code:

void hard_delay()
{
    __asm__
    (
        "mov #1000, r2  \n\t"
        "dec r2         \n\t"
        "jnz $-2        \n\t"
    );
}

Is the __asm__ builtin referencing symbols in stdlib? How does that happen?

# ¿ Jan 20, 2016 17:10

csammis: Aug 26, 2003; Mental Institution

Yep there's a division operator in the code, and removing that does clear up the .text section. Looks like the mspgcc compiler was only bringing in _udivmodsi4 and _divmodsi4 to handle that instruction. I guess the TI toolchain's ABI is all-or-nothing and the mspgcc toolchain is more stripped-down?

The .data section is still overflowing. mspgcc is only bringing in the global objects in my code (the 0x36 bytes of space from main.o). The TI toolchain is bringing in that and then 128 more bytes of...something called impure_ptr. Any ideas what this represents? Googling is mostly yielding "HOW DO I MAKE IT GO AWAY" and not "what is it" which is what I'd really like to learn

code:

*snip*
 .data          0x000000000000023c        0x0 /Users/csammis/Projects/ti/gcc/bin/../lib/gcc/msp430-elf/5.2.1/../../../../msp430-elf/lib/430/libc.a(lib_a-impure.o)
 .data._impure_ptr
                0x000000000000023c        0x2 /Users/csammis/Projects/ti/gcc/bin/../lib/gcc/msp430-elf/5.2.1/../../../../msp430-elf/lib/430/libc.a(lib_a-impure.o)
                0x000000000000023c                _impure_ptr
 .data.impure_data
                0x000000000000023e       0x78 /Users/csammis/Projects/ti/gcc/bin/../lib/gcc/msp430-elf/5.2.1/../../../../msp430-elf/lib/430/libc.a(lib_a-impure.o)
*snip*

# ¿ Jan 20, 2016 20:34

csammis: Aug 26, 2003; Mental Institution

Arachnamus posted:

They will be in the walls or ceilings or skirting boards

I really don't want to discourage creativity but f I were buying a house and I saw "bespoke smart home system designed by current owner, by the way you'll have to tear the house apart to remove or fix it" on a seller's disclosure - you would disclose that, right, and not just leave a letter for the new owners on closing day? - I'd run so loving fast the realtor would get wind chapped. Maybe you're not worried about or thinking about resale value right now but consider what JawnV6 said about physical access to the boards for changes / maintenance that you'll be doing. Do you really want to tear up a skirting board to fix a loose wire, then nail it back down and repaint? I'll go out on a limb and say that no, you don't.

If I were renovating a house and wanted to get creative with the hacker-friendly amenities, I'd run a 5V DC ring and the fastest Ethernet available to empty 2-gang boxes in every room of the house. That way you have a nice little niche everywhere to put your microcontroller projects that isn't a permanent installation or hard to access.

# ¿ Jan 26, 2017 15:13

csammis: Aug 26, 2003; Mental Institution

Arachnamus posted:

I was wondering about a 5V ring, but aren't the voltage drops significant for DC even over those sorts of lengths?

Yeah, I wasn't thinking about the voltage drop over house-length runs :saddowns:

# ¿ Jan 26, 2017 20:48

csammis: Aug 26, 2003; Mental Institution

Malcolm XML posted:

Further advantages of gangboxes: you can mains to them and put in a cute little power supply.

Don't tell your home insurer!!!!

Hah, I suggested gangboxes in my first post on the topic...when the voltage drop topic came up my first thought was "Well you could just put mains to it and stick a power supply on the back of it" and my second thought was "excellent way to start a house fire!"

Munkeymon posted:

Can't you just run it off a constant-voltage supply?

I was imagining running several 5V taps off a single supply, and I'm not an expert (obviously), but the voltage drop problem would require that all runs from the supply would be exactly the same length to deliver the same voltage at the tap...right?

# ¿ Jan 26, 2017 21:30

csammis: Aug 26, 2003; Mental Institution

My degree was in computer science which at the time and at that university was basically a math/statistics degree. I suspect I'm an outlier though, at least where I work.

JawnV6 posted:

Is "Computer Engineering" an ABET accredited major at a degree-granting institution?

Is that uncommon? "Computer Engineering" is the name of an ABET accredited undergraduate program where I went to school :confused:

csammis fucked around with this message at 02:42 on May 19, 2017

# ¿ May 19, 2017 02:35

csammis: Aug 26, 2003; Mental Institution

Phobeste posted:

Embedded Programming Microthread: Another Rebranded Eclipse

# ¿ Jun 8, 2017 03:21

csammis: Aug 26, 2003; Mental Institution

nielsm posted:

Am I right to be angry that their configurator app from 2016 is written in Visual Basic 6?

I think "resigned" is more how I feel when I see something like that.

quote:

Am I reading the MCU spec sheet right that it does just map the 32 KB image into 0h-8000h and begin execution at 0h on reset?

Yup, that's what the spec sheet says. It also says the active interrupt vectors are stored at 0000h to 0400h but your firmware may very well remap them somewhere else (or not use interrupts).

As far as disassembly goes, Thumb-2 is not that complicated an instruction set :v:

Grab a Thumb-2 opcode manual and a programming reference for that chip that shows where the system registers are mapped then go to town!

# ¿ Jul 23, 2017 19:41

csammis: Aug 26, 2003; Mental Institution

Switzerland posted:

Goal: Make my own wearable watch, preferably one that *doesn't* look like some 2-inch thick, babby's first kit watch.

You mentioned a stepper motor which makes me think you are thinking about a mechanical watch, and that is capital-H capital-ARD all-bold HARD. Hit up Youtube for watchmaker videos to get an idea of what you'd be in for. It's far more practical to start digital for sure.

quote:

Battery form factor: Dependent on other components, but preferably something that'll last a month or longer.

Depending on your component choices that might be reasonable, but for a battery the size of a wristwatch you just aren't looking at a zillion milliamp-hours. If you get to the point of choosing components we could help you figure out what power consumption would be in the worst case (tightening up power savings can get quite difficult) and that would give you a reasonable idea of what you'd be looking at.

quote:

I'll see if I can learn a thing and start with a desk clock

Great! I'm sure everyone here would love to help!

# ¿ Mar 22, 2018 03:11

csammis: Aug 26, 2003; Mental Institution

I wrote an I2C driver recently (for the same reasons as you) and I probably would have crushed the whole thing under a moving train if I hadn't had a logic analyzer to see what was going on :unsmith:

# ¿ May 14, 2018 21:20

csammis: Aug 26, 2003; Mental Institution

iospace posted:

B. the coordinates are X Z Y, not X Y Z.

I was all set to call BS on this but sure enough that�s what the datasheet says :psyduck:

e: and the accel is X Y Z what the hell

# ¿ May 15, 2018 04:26

csammis: Aug 26, 2003; Mental Institution

iospace posted:

The interesting thing, though this may be EMF from my computer so who knows, is my dad's iPhone was reading 186 when I was getting 180. Forgot to check North.

Magnetometer calibration is a whole thing. There's hard iron interference - permanent magnets nearby that might be distorting any magnetic fields (think speaker magnets or lightly magnetized screws) - and soft iron interference - ferrous metals that have been temporarily magnetized unintentionally (by the Earth's magnetic field) or intentionally (speaker coils, transformers, what have you). These can usually be statically mapped out and compensated for in any given device. Then there's the most hilarious gotcha of all: magnetic north is usually nowhere close to true north. The Earth's magnetic north pole isn't situated on its geographic pole and depending on where you are on the Earth's surface the offset could vary by a fraction of a degree to several degrees. This is called magnetic declination. Your dad's iPhone is probably compensating for it because it knows, geographically, where it is. There are a few models which are used to calculate drift and issue corrections but one standard approach is to precalculate an table of magnetic declination values based on latitude and longitude and then interpolate based on your current location. NOAA has a service you can use to create that table. You can get as ridiculously fine-grained as you have the program space for.

This app note has some good calibration information. This app note is in my opinion the gold goddamn standard for tilt compensated e-compass calculation and calibration (and it's based around the LSM303).

Mr. Powers posted:

Enjoy magnetometer to heading hell!

Amen brother, amen

# ¿ May 15, 2018 13:53

Adbot: ADBOT LOVES YOU

# ¿ Apr 29, 2024 14:49

csammis: Aug 26, 2003; Mental Institution

Private Speech posted:

I just found out TI has some pretty nifty ULP MCUs with decent-sized on-chip FRAM, and they are about 30% cheaper than any equivalent-sized FRAM chips I can find.

The MSP430FRs? I've been using them and I like them.

quote:

I also found out that they have yet another eclipse-based IDE.

Personally I hate Eclipse for editing so I do my coding elsewhere and use CCS to build / debug. In fairness I really like the stack usage and memory allocation graphs, and it has a live power consumption monitor during debugging sessions which is pretty neat.

# ¿ May 26, 2018 17:04

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > 64K is still quite a lot! Embedded Programming Microthread