David Bender

I wrote this library to do fancy analysis and collation of intel hex files https://github.com/analog10/ihp If you find it useful please leave a comment in the forum.

I think it would be really cool to have a battery powered ESP8266 that could write to the flash of an MSP430 via the UART BSL. There are 2 free GPIO on the ESP8266 that could toggle the RST and TST lines as well as the normal RX/TX. In operation, one could upload a small file to the ESP8266 via web interface and initiate the transfer via a button on the same. Also once could read/write the information segments as well. Is there any existing project like this or any interest in the community for it?

begin_lcd_write() just buffers data and initializes the TA0.1 IE. The LCD data are clocked in the timer interrupt handler so there really isn't any blocking. I think an improvement would be to supersample 8 times, average and then use the change in value as a determination of how far the encoder turned, rather than only comparing discrete levels.

I had a lack of digital input pins for a pushbutton rotary encoder switch so I used an analog input. I wrote up my results here: https://analog10.com/posts/rotary_encoder_analog_input.html It works pretty well except for an occasional reverse tick but that's probably a flaw in my code.

The master is talking to 8 slaves using chip select pins on P3. Only 1 pin is pulled low at a time using the ~ operator, so STE is NOT floating. I think I mostly solved my issue with the following code: (By mostly solved I mean I am seeing garbage on MISO when a slave is not present on the active chip select, but that seems to be a checksum issue now) #include <msp430g2553.h> #include <string.h> #include "stdarg.h" enum { /* Port 1 */ LED1 = BIT0 ,LED2 = BIT1 ,CHIP_SELECT = BIT3 }; int main(void){ WDTCTL = WDTPW | WDTHOLD; /* TODO Check if -mdisable-watchdog set.

The following code accepts over the SPI bus a byte from the master to control 8 relays, and returns the state of 8 inputs. I am running into an issue where the slave always responds to the SCLK, driving MISO, even when the STE (pin 1.4) is not asserted low. Any ideas why? #include "msp430g2553.h" #include <string.h> enum { /* Port 1 */ LED1 = BIT0 ,LED2 = BIT1 }; int main(void){ WDTCTL = WDTPW | WDTHOLD; BCSCTL1 = CALBC1_16MHZ; DCOCTL = CALDCO_16MHZ; /* SMCLK = DCO / DIVS = nMHz */ /* ACLK = VLO = ~ 12 KHz */ BCSCTL2 &= ~(DIVS_0); BCSCTL3 |= LFXT1S_2; P2SEL &

Are you looking for a board with a programmer or just a chip on it? I have one for sale on tindie for 6.95 + 2.00 shipping and includes P3.0-P3.7 (no programmer though) https://www.tindie.com/products/analog10/dos-ocho-launchpad-compatible-board-with-28-pins/

Harbor Freight offers a decent deal on a digital gauge that also communicates its reading (much like a Chinese calipers). I built up an MSP430 based solution to retransmit this data via UART and externally power the dial gauge (eliminating the need for a button cell battery). Project details are at https://analog10.com/posts/external_power_for_the_pittsburgh_dial_gauge.html Code is at https://github.com/analog10/Digital_Dial_Gauge_Reader Happy Holidays

I build images on my desktop, then access them from my raspberry-pi via ssh-fs...no need to build them locally.

We have to worry about an edge happening in our critical section initialization. So change initialization as follows. __disable_interrupt(); uint8_t back = PxIES; PxIFG = 0; PxIES = PxIN; /* According to slau144j 8.2.7.2 It's not possible to trigger a fake transition if PxIES is getting set to the same values as PxIN. So if there is a bit on PxIFG we did get an edge just after we set PxIES. */ uint8_t snap = PxIFG; PxIFG = 0; if(snap & BITN){ if(PxIES & BITN) /* emit falling */ else /* emit rising */ } PxIES &= BITN; back &= ~BITN; PxIES |= back; PxIE |= BITN;

You would also want to change BIT0 to BIT2 in this line: ADC10AE0 |= BIT0;

Make sure you don't use a baud rate faster than 9600 baud; the launchpad G2 doesn't work properly going any faster.

You probably can get decent web performance with the TM4C129. You can't use a naive web server though. I've written an embedded web server for my client (on an ARM chip as well) and can recommend the following: 1) Don't buffer the client request; try to parse the request as the data comes in. 98% of your requests are GETs and do not require buffering. Consequently you can boost the number of sockets you can process at a time. 2) I recommended trying Connection: close because I thought the browser may have been trying to reuse the socket and your code didn't seem to support that. Connectio

Doh, I looked at Tone.cpp again and now it makes sense. I had thought Energia would set up the Timer output directly but it actually toggles the POUT in the interrupt handler. I would expect to see a few microseconds of jitter between the cam pulse and the crankshaft pulse that triggered it, but should be OK.

Are you actually getting any output? P2_1 is associated with TimerA1.1. However, Energia's tone() function only works with TimerA0. Choose a different pin that associates with a TimerA0.x output. https://github.com/energia/Energia/blob/master/hardware/msp430/cores/msp430/Tone.cpp