jscrane

Grrr: looks like N is #defined somewhere in the thicket of headers included by Energia! Changing it to something else worked under the old compiler. Oh well.

Hi everyone, I have a program which involves something like this: template<unsigned N> class Bar { public: char baz[N]; }; class Foo: public Bar<32> { }; Unfortunately this fails to compile under Energia, with the following error message: sketch_oct10a.cpp:0:19: error: expected ')' before numeric constant sketch_oct10a.cpp:0:19: error: expected '>' before numeric constant sketch_oct10a.cpp:0:19: error: expected unqualified-id before ')' token sketch_oct10a.cpp:6:22: error: expected template-name before '<' token sketch_oct10a.cpp:6:22: error: expected '{' before '<' token sketch_oct10a.cpp:6:22: error: expected unqualified-id before '<' token Since it compiles under Arduino, I'm guessing this is a bug in gcc version 4.6.3. This is an old compiler, from 2011. The compiler shipping with Arduino is gcc version 4.8.1, from 2013. Then I discovered TI's gcc implementation of gcc, version 4.9.1 from 2014, and sure enough it compiles this code fragment in a standalone source file. So my question is, has anyone any pointers to getting Energia to use this compiler instead of the default one? Failing that, is anyone working on updating the compiler shipping with Energia and if so, what the timescale is? Thanks, Steve

Hi guys, I've been working on this for a while and I've written about it here: http://programmablehardware.blogspot.ie/search/label/interrupted Github is here: https://github.com/jscrane/Interrupted It now runs on Energia with msp430g2553. Feedback welcome! Steve

Hello world, If your project has outgrown the capabilities of the Energia IDE, why not try Gnu Make? I've put together a set of Makefile fragments which support Energia (msp430 and lm4f) and Arduino 1.0, here: https://github.com/jscrane/uC-Makefile. For most projects, a Makefile as simple as this suffices: Followed by: Cheers, Steve

Hah! I'd say the Speccie is a hard ask emulation-wise: I was thinking something easier like the PET 2001, or maybe a Lisp Machine...

What I did on my Summer Holidays: http://programmablehardware.blogspot.ie/2014/08/retrocomputer-resurrection.html

Hi!

Following rickta59's advice and that here: https://github.com/arduino/Arduino/wiki/Arduino-IDE-1.5---3rd-party-Hardware-specification I created a platform.txt file for the boot430 board. As a side-effect, it also integrates all of the msp430-based launchpad boards into Arduino (using the Energia cores). Should anyone be interested in such an heresy, they can find it here: https://github.com/jscrane/energia

Excellent work guys! I'd just like to add that I noticed the occasional communication failure from the uploader when it was breadboarded. Today I moved it to a piece of stripboard and haven't seen a single upload error since.

Thanks to the excellent work of simpleavr and friends on this thread, http://forum.43oh.com/topic/2962-bit-bang-usb-on-msp430g2452/ ... I now have a little stripboard msp430 development board with usb bootloader! I would now like to program it from Energia but one immediate stumbling block is that it uses a custom upload tool, not mspdebug. Any ideas how I can tell boards.txt (or anywhere else which needs to know) about this? Thanks, Steve

I have modified the default pinouts for Stellaris to be compatible with Daniel Rebollo's boosterpack. This means that it should work out of the box with the UFTF_Demo_320x240 example for lm4f. I have also added Launchpad and Fraunchpad support. See https://github.com/jscrane/UTFT-Energia Cheers, Steve

So reusing the SPI library as-is costs 50% in performance and wastes a GPIO? Suggests to me that SPI could use some refactoring love. Maybe split out a superclass for clients like FatFs and call into it from the existing class? Comments? Steve

OK I went back to square one: * Original library from HK on ATmega328p with new 16-bit display HY32D (controller SSD1289): works ok * My latest library on same hardware: ok * Transferred display wiring to Stellarpad: wiring D0-D7=PB0-PB7; D8-D15=PE0-3+PC4-7; RS=PA_5; WR=PA_7; CS=PA_6; RST=PD_6; RD=VREF; VCC=VREF. ...and it works! So I guess the things you have to look out for: * getting the controller chip right (in sketch + memorysaver.h) * wiring the data bus correctly: PB now gets the low 8 bits (the ones which would be connected to ground in 8-bit mode) * connecting RD high Cheers, Steve

I guess this is just because sport() uses bitwise-or to set bits, so you need to clear existing bits as well...

I've done some more experimenting (in 8-bit mode) and have successfully driven my display (an S6D1121) from PE0-3 and PC4-7. When I combined that with PB0-7 (already tested in 8-bit mode) for 16-bit mode, nothing! I have checked in these latest changes to github anyway, maybe you could test with your display if it's different from mine? Steve