Jump to content
43oh

westfw

Members
  • Content Count

    21
  • Joined

  • Last visited

Everything posted by westfw

  1. >> 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 :-(
  2. 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.)
  3. 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
  4. 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+
  5. 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
  6. BTW, Energia 15 worked OK on my Win10 (VM) "machine." (with the install in a \bin directory.) I'm up to 10041.
  7. 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"...)
  8. 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
  9. 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?
  10. 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
  11. 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.))
  12. There are a couple of videos that showed up, linked together starting here:
  13. 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
  14. Ah; ok. This is getting widely blogged as "Arduino compatibility for MSP430", though. (ie http://dangerousprototypes.com/2011/06/ ... -released/ )
  15. 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...)
  16. Arduino relies on a bootloader, so that the host systems only need to talk to "serial" ports. Arduino uses (used?) a USB/Serial converter with well-established and well-proven multi-platform driver support. (The new "Uno" uses a different chip with theoretically wider (standardized) implementation, but less in that "well established and proven" department.) Arduino uses a CPU whose gcc implementation was already "mature" (and "packaged") on multiple platforms. Arduino's environment (eg "Processing") was envisioned as multi-platform (and even somewhat Mac-specific) from the ground up. It w
  17. No, since I'm also used to a non-GUI development environment, I get along fine with EMACS and Makefiles and such. An interesting possibility is to run Eclipse on Mac with the individual compiler apps that run underneath running in Wine...
  18. I'm using gcc because I'm on a Mac, mostly. (and I'm used to using gcc for AVR, 68K, MIPS, and PPC, and using a unix-like build environment rather than a product-specific IDE.) My understanding is that the latest version of gcc for msp430 is set up to use the TI include files, rather than the non-TI include files it used to use. This should go a long ways to making things more compatible. (there are probably still "minor" incompatibilities at the edges: defining ISRs and so on, but I think the different include files were the big problem.)
  19. Digging up the old code, and looking at your ideas more carefully, I see that they are not so much the same after all. The old code all relied on generating named/numbered symbols that used standard assembler forward referencing, so all it needed was depth counters rather than an actual stack. And it needed the ability to concatenate the counter and the symbol base name within macros. For your amusement, here the meat of the x86 MASM version: if_ macro condition begctr= begctr+1 endctr= endctr+1 ;; eee @makjmp BEG,%begctr,JN&condition ;; JNE BEGnnn savctr= savctr+1 @stnam SAV,%sa
  20. Ah. Nice. I had run into similar macros a couple of decades ago, and even implemented them for x86 (MASM!), but those implementations were all dependent on being able to implement the "control stack" using fancy symbol/macro definition features that aren't present in many of the current assemblers, and I had never thought of simply using brute force like you do! Do you happen to have the macros already implemented for the Gnu assembler syntax? That would cover a whole lot of CPUs...
×
×
  • Create New...