westfw

>> I had never heard of fopencookie Me either. avr-libc has "fdev_open" and "fdev_setup_stream" on top of their much more primirive "stdio" library, and I figured that newlib (the libc used on ARM Energia implementations) must have something similar. Then it was just a matter of finding it :-(

xxx-objdump has a bunch of different options for various output formats. There is also "xxx-objcopy" for converting between different "binary formats" This is used to generate .hex files (ascii text of the binary), or .bin files (straight binary) from the .elf file that the compiler produces. (.elf files also contain a bunch of debugging information that doesn't end up in the final binary.)

I built an energia dist from the current source, and it won't compile MSP432 examples, failing to find Arduino.h and/or Energia.h. It looks like those are in a weird place compared to other boards? find . -name Arduino.h ./work/Energia.app/Contents/Resources/Java/hardware/c2000/cores/c2000/Arduino.h ./work/Energia.app/Contents/Resources/Java/hardware/cc3200/cores/cc3200/Arduino.h ./work/Energia.app/Contents/Resources/Java/hardware/common/ti/runtime/wiring/msp432/Arduino.h ./work/Energia.app/Contents/Resources/Java/hardware/lm4f/cores/lm4f/Arduino.h ./work/Energia.app/Contents/Resources/J

OK. Now I'm feeling a little embarassed, thinking that stdout was more magical than it actually is. How about just: ssize_t myWrite(void *cookie, const char *buf, size_t n) { return Serial.write((uint8_t*)buf, n); } cookie_io_functions_t myVectors = { 0, myWrite, 0, 0 }; void setup() { Serial.begin(115200); stdout = fopencookie((void *)0, "w", myVectors); setlinebuf(stdout); printf( "This is an fprintf demo\n"); } To me, this seems cleaner and more obvious than the mechanations you'd otherwise have to go through to provide a C _write_r() function that called C+

I didn't manage to get _write_r() working with printf(), but if you're willing to use fprintf(), you can use fopencookie() in obvious ways (once you find the documentation!) #include <stdio.h> ssize_t myWrite(void *cookie, const char *buf, size_t n) // wrapper function { return Serial.write((uint8_t*)buf, n); } cookie_io_functions_t myVectors = { 0, myWrite, 0, 0 }; FILE *myOut; void setup() { Serial.begin(115200); myOut = fopencookie((void *)(&Serial), "w", myVectors); setlinebuf(myOut); fprintf(myOut, "This is an fprintf demo\n"); } Including printf a

BTW, Energia 15 worked OK on my Win10 (VM) "machine." (with the install in a \bin directory.) I'm up to 10041.

There really ought to be a well-defined workaround for this by now, at least for executable paths. A quick look around seems to show that there are several ugly versions, none specifically addressing tools that live in "Program Files", but I have some ideas to try... (there is a way to change a path from "long filename" to "DOS filename"...)

Well, it looks like the "release" has some problems... The 500+MB .bin files seem to be because the .elf file contains initialized data at RAM addresses (0x2000000+), rather than "copy my initialized data from flash to RAM in the startup code" that should be there. That seems like a real problem even beyond the silly file sizes... 000091b4 R ti_sysbios_family_arm_m3_Hwi_E_noIsr__C 000091b8 R xdc_runtime_Text_charCnt__C 000091bc R ti_sysbios_family_arm_m3_Hwi_E_busFault__C 000091c0 R ti_sysbios_knl_Swi_Object__count__C 000091c4 R ti_runtime_heaps_HeapRem_Object__PARAMS__C 000091dc A __da

Also, the 432 build seems to be using "make" to build stuff for the 432, but I don't see a way to do the equiv of "make clean" to force library recompilation... and I can't figure out where it's putting the .o (or .obj) files (from the core) to clean manually either. Perhaps it's not building what I think it's building at all?

Sure. But I'm comparing the other (non-multitasking) Stellaris/Tiva boards (2400-3800 bytes) with the 432 board (45000+ bytes.) I am using the Mac version... OTOH, check out that .bin file size! -rw-r--r-- 1 staff 950 Mar 26 01:16 Blink.cpp -rwxr-xr-x 1 staff 536879208 Mar 26 01:16 Blink.cpp.bin* -rwxr-xr-x 1 staff 1271459 Mar 26 01:16 Blink.cpp.elf* -rw-r--r-- 1 staff 986539 Mar 26 01:16 Blink.cpp.map -rw-r--r-- 1 staff 15956 Mar 26 01:16 Blink.obj -rw-r--r-- 1 staff 594 Mar 26 01:16 Variables.mk -rw-r--r-- 1 staff 3831 Mar 26 01:16

Can you compile msp432 code without ti-rtos? I was sorta expecting two separate board types... ("blink" for th 432 is 45k! (though I suppose I shouldn't care.))

There are a couple of videos that showed up, linked together starting here:

Remember this: http://forum.43oh.com/topic/219-adding-structured-control-flow-to-any-assembler/ ? It was a set of macros that would add _if, _else, _do, _until and similar constructs to an assembly program. It turned out that this didn't work when using the Gnu Assembler :-( But I think I've managed to implement similar macros that DO work for the gnu assembler. They're here: https://github.com/WestfW/structured_gas I've tried to do this in a way that will make it easily portable to any of the cpus supported by gas, and provided implementations for Atmel AVR (tested!) and TI MSP43

Ah; ok. This is getting widely blogged as "Arduino compatibility for MSP430", though. (ie http://dangerousprototypes.com/2011/06/ ... -released/ )

So how serious are you about this Arduino compatibility layer? What's there now seems awfully scant (for example, the only version of millis() I found was pretty wrong, and millis() is a pretty fundamental Arduino function.) (It looks more useful as a collection of handy non-arduino-compatible functions...)