chicken

In my project, I use a few basic macros for GPIO. The goal is, that I can easily redefine pin assignment in a central location without compromising performance or code size.
 
The macros (gpiomacros.h):
// MSP430 gpio macros #define GPIO_SEL(port) P ## port ## SEL #define GPIO_DIR(port) P ## port ## DIR #define GPIO_OUT(port) P ## port ## OUT #define GPIO_IN(port) P ## port ## IN #define GPIO_IS_INPUT(port,pin) { GPIO_SEL(port) &= ~(pin); GPIO_DIR(port) &= ~(pin); } #define GPIO_IS_OUTPUT(port,pin) { GPIO_SEL(port) &= ~(pin); GPIO_DIR(port) |= (pin); } #define GPIO_IS_PERIPHERAL_IN(port,pin) { GPIO_SEL(port) |= (pin); GPIO_DIR(port) &= ~(pin); } #define GPIO_IS_PERIPHERAL_OUT(port,pin) { GPIO_SEL(port) |= (pin); GPIO_DIR(port) |= (pin); } #define GPIO_SET(port,pin) { GPIO_OUT(port) |= (pin); } #define GPIO_CLEAR(port,pin) { GPIO_OUT(port) &= ~(pin); } #define GPIO_READ(port,pin)  ( GPIO_IN(port) & (pin) ) In a central configuration file (e.g. hardware.h) I assign pins like this:
// Pin assignment #define LED1_PIN BIT1 #define LED1_PORT 6 #define LED2_PIN BIT0 #define LED2_PORT 1 And then in the code I interact with GPIO like this:
// Setup LEDs GPIO_IS_OUTPUT(LED1_PORT, LED1_PIN); GPIO_IS_OUTPUT(LED2_PORT, LED2_PIN); // Turn off LEDs GPIO_CLEAR(LED1_PORT, LED1_PIN); GPIO_CLEAR(LED2_PORT, LED2_PIN); The macros are resolved in two steps:
1. Higher level "functions" define the commands. E.g. GPIO_SET(), GPIO_IS_OUTPUT(), ..
2. Lower level macros used within those functions translate port, pin to a register. E.g. GPIO_IN(), GPIO_SEL(), ..
 
The end result is code like you would write when directly working with the GPIO registers. E.g. P2OUT &= ~BIT0; Note that this translation is done by the C pre-processor before the code is compiled.
 
This all works fine and dandy, with the exception of port J. Port J doesn't have a SEL register, which breaks the 1st half of the GPIO_IS_OUTPUT and GPIO_IS_INPUT macros. I currently work around this by adding special GPIO_IS_OUTPUT/INPUT_J macros, but then the main code needs to include some logic to invoke the proper macro.
#if (LED2_PORT == J) GPIO_IS_OUTPUT_J(LED2_PORT, LED2_PIN); #else GPIO_IS_OUTPUT(LED2_PORT, LED2_PIN); #endif Any ideas, how I could include a condition inside macros, that checks whether the port is J, and if so excludes the GPIO_SEL command?
 
And yes, I could probably use C++ templates with identical results and an easy workaround for port J, but I'd like to avoid migrating my plain old C project.
 
Edit: Added a few missing parentheses, thanks to Rickta59 for spotting that

Nick Gammon published an interesting post on using SPI on 16 MHz Arduinos to run WS2812 LEDs (aka neopixels) at: http://gammon.com.au/forum/?id=13357. He also provides a link with a lot of information about the NRZ protocol used by the WS2812 and tolerances:  https://wp.josh.com/2014/05/13/ws2812-neopixels-are-not-so-finicky-once-you-get-to-know-them/.  The tolerances are actually quite a bit looser than what I previously believed.  So, I set out to do something similar with Energia and LaunchPads running at different speeds.  Spoiler alert:  It works.
 
The previously linked articles provide all the background so minimal information is repeated here.  NRZ is a one wire protocol that transfers information to the LEDs by varying the length of the signal when high.  A longer pulse is used for a 1, and a shorter one for a 0.  The timing, with tolerances, is shown in the figure below.
 

The length between pulses cannot exceed about 5 us and most everything else is pretty loose.
 
The protocol is implemented using SPI which I find pretty clever.  A byte is sent out with the SPI module with the proper length to represent the desired bit for the protocol.  The following must be determined and set to do this:
Set proper SPI clock speed using SPI.setClockDivider() in Energia Determine the proper byte to send by SPI.transfer() in Energia to represent a 0 or 1 bit For example, using the MSP430F5529:
Clock speed is 25.6 MHz Setting the SPI clock divider to 4 gives a SPI clock of 6.4 MHz and since the SPI block executes in one cycle (Arduino executes in 2), each bit in the byte is equivalent to 156.25 ns. Therefore, to send a pulse indicating a "1", a byte equal to 0b1111000 could be used which gives 4x156.25 = 625 ns.  This is in the acceptable range of 550 to 850 ns. Similarly, for a 0 an acceptable byte would be 0b11000000 or 312.5 ns. A similar process can be used to determine acceptable values for the MSP430G2553.
 
The sketch below is a simplification of the library presented by Nick which and includes the modifications described above to run on both the G2553 and F5529.  The preprocessor is used to set appropriate values for the clock divider and long and short bytes.   The functions are very nearly the same as posted by Nick.  Note that interrupts must be disabled before sending data and then reenabled manually after.
/* * WS2812 display using SPI on various TI LaunchPads with Energia * * Connections: * LaunchPad LED Strip * --------- --------- * 3V3 5VDC * Pin 15 (MOSI) DIN * GND GND * * How to use: * ledsetup (); - Get ready to send. * Call once at the beginning of the program. * sendPixel (r, g, ; - Send a single pixel to the string. * Call this once for each pixel in a frame. * Each colour is in the range 0 to 255. Turn off * interrupts before use and turn on after all pixels * have been programmed. * show (); - Latch the recently sent pixels onto the LEDs . * Call once per frame. * showColor (count, r, g, ; - Set the entire string of count Neopixels * to this one colour. Turn off interrupts before use * and remember to turn on afterwards. * * Derived from NeoPixel display library by Nick Gammon * https://github.com/nickgammon/NeoPixels_SPI * With ideas from: * http://wp.josh.com/2014/05/13/ws2812-neopixels-are-not-so-finicky-once-you-get-to-know-them/ * Released for public use under the Creative Commons Attribution 3.0 Australia License * http://creativecommons.org/licenses/by/3.0/au/ * * F Milburn November 2016 * Tested with Energia V17 and WS2812 8 pixel strip on launchpads shown below. */ #include <SPI.h> #if defined(__MSP430G2553) #define SPIDIV SPI_CLOCK_DIV2 // 16 MHz/2 gives 125 ns for each on bit in byte #define SPILONG 0b11111100 // 750 ns (acceptable "on" range 550 to 850 ns) #define SPISHORT 0b11100000 // 375 ns (acceptable "on" range 200 to 500 ns) #elif defined(__MSP430F5529) #define SPIDIV SPI_CLOCK_DIV4 // 25.6 MHz/4 gives 156.25 ns for each on bit in byte #define SPILONG 0b11110000 // 625 ns (acceptable "on" range 550 to 850 ns) #define SPISHORT 0b11000000 // 312.5 ns (acceptable "on" range 200 to 500 ns) #else #error This microcontroller is not supported #endif const unsigned int PIXELS = 8; // Pixels in the strip void setup (){ ledsetup(); } void loop (){ // Show a solid color across the strip noInterrupts(); // no interrupts while sending data showColor (PIXELS, 0xBB, 0x22, 0x22); // single color on entire strip interrupts(); // interrupts are OK now delay(1000); // hold it for a second // Show a different color on every pixel noInterrupts(); // no interrupts while sending data sendPixel(0xBB, 0x00, 0x00); // red sendPixel(0x00, 0xBB, 0x00); // green sendPixel(0x00, 0x00, 0xBB); // blue sendPixel(0xBB, 0xBB, 0xBB); // white sendPixel(0xBB, 0x22, 0x22); // pinkish sendPixel(0x22, 0xBB, 0x22); // light green sendPixel(0x22, 0x22, 0xBB); // purplish blue sendPixel(0x00, 0x00, 0x00); // pixel off interrupts(); // interrupts are OK now delay(1000); // hold it for a second } // Sends one byte to the LED strip by SPI. void sendByte (unsigned char { for (unsigned char bit = 0; bit < 8; bit++){ if (b & 0x80) // is high-order bit set? SPI.transfer (SPILONG); // long on bit (~700 ns) defined for each clock speed else SPI.transfer (SPISHORT); // short on bit (~350 ns) defined for each clock speed b <<= 1; // shift next bit into high-order position } // end of for each bit } // end of sendByte // Set up SPI void ledsetup(){ SPI.begin (); SPI.setClockDivider (SPIDIV); // defined for each clock speed SPI.setBitOrder (MSBFIRST); SPI.setDataMode (SPI_MODE1); // MOSI normally low. show (); // in case MOSI went high, latch in whatever-we-sent sendPixel (0, 0, 0); // now change back to black show (); // and latch that } // end of ledsetup // Send a single pixel worth of information. Turn interrupts off while using. void sendPixel (unsigned char r, unsigned char g, unsigned char { sendByte (g); // NeoPixel wants colors in green-then-red-then-blue order sendByte (r); sendByte (; } // end of sendPixel // Wait long enough without sending any bits to allow the pixels to latch and // display the last sent frame void show(){ delayMicroseconds (9); } // end of show // Display a single color on the whole string. Turn interrupts off while using. void showColor (unsigned int count, unsigned char r , unsigned char g , unsigned char { noInterrupts (); for (unsigned int pixel = 0; pixel < count; pixel++) sendPixel (r, g, ; interrupts (); show (); // latch the colours } // end of showColor The timing, when checked on a logic analyzer, checks out with the calculations above (hooray for math).  The "gaps" between pulses are within tolerance and largely set by code overhead as well as the byte being sent.
 


And here it is showing the strip lit up in one color.
 

I tried this on several other LaunchPads I had handy and here is a summary:
FR6989 - I had never noticed, but Energia defaults to 8 MHz.  Doing the math, there isn't a good match to the WS2812 requirements without changing processor speed (which I did not try). MSP432 - there was behavior I couldn't explain, probably due to RTOS and I didn't pursue this for long. In summary, the method works although I did limited experimentation.  It would be even easier to implement outside of Energia with full access to clocks.  It was an interesting exercise but alternative methods have been posted here on 43oh with tuned assembler and having used those successfully in the past, I will probably continue to preferentially use them in the future.

Hi Polyphemus,
 
Yes, dAISy includes a bandpass filter.
 
I experimented with external LNAs a few times, but didn't see any benefit. Though I never was very systematic about my experiments.
 
The max input must not exceed 10 dBm. Even -50 dBm is more than enough to reliably decode a signal. A LNA would only be useful if it pulls very weak signals (say below -100 dBm) out of the noise.

The f_cpu variable in boards.txt file defines the clock speed of each board. F_CPU is passed into the startup code in wiring.c to configure the clocks.
 
If you're lucky, changing boards.txt is all that's needed. If not, you will have to dig into Energia source code. wiring.c can be found it in the hardware / cores / msp430 folders.
 
According to the G2553 datasheet page 21, 1.8V is the lowest supply voltage supported at up to 6 MHz. Even if your MCU runs down to 1.6V, I would not rely on it.
http://www.ti.com/lit/ds/symlink/msp430g2553.pdf

In the Horowitz/Hill Art of Electronics, third edition, design practices with discrete 74HCxxx, FPGA and Microprocessor are compared and discussed.
As an example, the ultimate gibberish machine is described, a circuit that sends out a succession of pseudorandom bytes, as standard RS232 serial data, with 2 selectable speeds, 9600 / 1200 baud. 
 
Independent of the processor type, the implementation with a small micro and program it in C looks like the clear winner here, smallest engineering effort, lowest hardware effort (have to admit that I do not have the faintest idea about FPGA.)
 
The example in the book used some 8051ish device, so I was wondering on how this would look like on a MSP430/launchpad
 
See my code below, based on the 8051 C code from the book, but adapted to run as low power as possible (LPM3)
The power consuption of this thing is: 40uA at 9600baud, 6uA at 1200baud  
//MSP430G2553LP implementation of the ultimate gibberish machine //from the art of electronics, third edition, Chapter 11.3. //Produces a pseudorandom datastream at 9600/1200baud, 8n1 //P1.0 output, sync, processor busy //P1.2 output, serial pseudorandom data //P1.3 input, data rate select (button,at start) //32768Hz crystal is required //2016-10-23 maelli01 #include <msp430.h> unsigned char d,c,b,a=1; int main(void) { WDTCTL = WDTPW + WDTHOLD; // Stop WDT P1DIR = ~BIT3; P1REN=BIT3; P1OUT=BIT3; // all output, except button P1SEL = BIT2; P1SEL2=BIT2; // P1.2=TXD P2REN = 0x3F; // all unused pins resistor enable P3REN = 0xFF; // all unused pins resistor enable UCA0CTL1 |= UCSSEL_1; // CLK = ACLK if(P1IN&8){ // button not pressed: 9600 baud UCA0BR0 = 3; // 32768Hz/9600 = 3.41 UCA0MCTL = UCBRS1 + UCBRS0; // Modulation UCBRSx = 3 } else{ // button pressed: 1200 baud UCA0BR0 = 27; // 32768Hz/1200 = 27.3 UCA0MCTL = UCBRS1; // Modulation UCBRSx = 2 } UCA0BR1 = 0x00; UCA0CTL1 &= ~UCSWRST; // **Initialize USCI state machine** IE2 |= UCA0TXIE; // Enable USCI_A0 TX interrupt __bis_SR_register(LPM3_bits + GIE); // Enter LPM3 w/ int } #pragma vector=USCIAB0TX_VECTOR __interrupt void USCI0TX_ISR(void){ P1OUT |=1; UCA0TXBUF=((d<<1)|(c>>7))^c; // 32 bit pseudorandom generator d=c; c=b; b=a; a=UCA0TXBUF; P1OUT &=~1; }

For a long time, I have had an interest in FPGA development. You can find boards that come with a JTAG programmer on ebay for less than $20. The following ebay link shows a board similar to the one I had purchased http://www.ebay.com/itm/361568712810  I experimented with it a lot for a while and then I probably got distracted by some new TI toy  Occasionally, I would pick it up and try different things with it. However, the cost and form factor of the chips discourages me from doing anything real with it.  For me these things are more of an educational plaything.
 
Yesterday, I noticed the neo430 project on opencores.org. It is an msp430 compatible processor implemented in VHDL. It didn't take me long to get it installed and it actually seems to work pretty well. There are some difference between the neo430 and the msp430. ( see list below for the details ) Using the Altera Cyclone II EP2C5 board I linked above I was able to use the example code to create an msp430 like device with 4K of ROM and 4K of RAM. It runs a serial bootloader over its UART peripheral and allows you to toggle the pins using its parallel port peripheral. It has a simple timer peripheral. It has its own custom peripherals and 'C' header files setup to access those. It comes all setup to use msp430-gcc as a development tool with the device you create.
 
The instructions are pretty complete neo430 instructions  , I just followed them to get started.  For my Altera chip, I used the free web edition of quartus II 13.0.1 sp1 to convert the VHDL code into a loadable bitstream. Once you load that on to the FPGA chip using the USB-Blaster, a serial terminal is used to interact with the bootloader and upload msp430-gcc compiled files.  The provided makefiles automate the msp430 code creation process.  I'm using this on linux and I had to make a few changes to point at the directory where my msp430-gcc is installed. If you are windows user it will probably just work out of the box for you.

I'll try and post more on my experiments.  In the meantime, I thought others might find it interesting.
 
Functional Diagram:

 
Memory Layout:

 

You should try some larger needle tips. My pickup tool is a small DC motor pump + PVC tubing and Luer-loc syringes, I've found switching to larger diameter tip enables me to pickup larger parts TSSOP and 32 pin TQFP.

More fun in the lab

 

Progress is slow in dAISy land, mostly due to lack of time. But I finally got time to unpack and test the first production batch of the 2-channel dAISy HAT for Raspberry Pi.

 
I've used MacroFab for the first time, which worked out great. Because they don't have NRE, it's the perfect solution for slowly ramping up volumes while still tweaking the design.
 
I even built a little jig for programming and testing.

 
Even though I included a Tag-connect footprint, I decided to use pogo pins and a F5529 LaunchPad for programming. As communication with the Raspberry Pi is only via UART, I can also fully test the board via the LaunchPad. Saves a ton of time compared to using a real RPi.
 
I will have to write some useful documentation before putting them up for sale on Tindie. I'm a little scared of the potential support nightmare to help non-IT people configure their RPis.
 
PM me if you can't wait and don't need no stinkin' documentation.
 
Edit: Now available on Tindie https://www.tindie.com/products/astuder/daisy-hat-ais-receiver-for-raspberry-pi/

Progress is slow in dAISy land, mostly due to lack of time. But I finally got time to unpack and test the first production batch of the 2-channel dAISy HAT for Raspberry Pi.

 
I've used MacroFab for the first time, which worked out great. Because they don't have NRE, it's the perfect solution for slowly ramping up volumes while still tweaking the design.
 
I even built a little jig for programming and testing.

 
Even though I included a Tag-connect footprint, I decided to use pogo pins and a F5529 LaunchPad for programming. As communication with the Raspberry Pi is only via UART, I can also fully test the board via the LaunchPad. Saves a ton of time compared to using a real RPi.
 
I will have to write some useful documentation before putting them up for sale on Tindie. I'm a little scared of the potential support nightmare to help non-IT people configure their RPis.
 
PM me if you can't wait and don't need no stinkin' documentation.
 
Edit: Now available on Tindie https://www.tindie.com/products/astuder/daisy-hat-ais-receiver-for-raspberry-pi/

My grandson and I have been upgrading the airplane from last year.

 
In addition to the existing jet exhaust, spot light, and voice feature we have added lots more LEDs and changed the power supply to two C batteries.  Now that 1 watt spotlight on the nose can really shine.  There is a new G2553 to play a song and make space noises- we are calling it the radio - through a piezo crystal while a RGB LED provides synchronized visuals.

 
I designed a simple G2553 PCB for wearables which will be used for my granddaughter's costume.  It uses a coin cell for power and the plan is to blink LEDs.  The in thing for wearables seems to be a circular shape with gator holes but having made this one I think I'll try something different next time.

 
Last years post:  http://forum.43oh.com/topic/9004-potm-blue-angels-f-18-costume/
 

Just a quick update on the issues I described above, if someone stumbles by
I was able to trace down the cause for the crashes I had when the receiver was operating at its sensitivity level (weak signal). It was indeed related to the "packet length byte" associated with the data payload getting corrupted.
 
After some poking around in the AIR library I found that that the CC1101 packet length configuration was set to 61 bytes. In my sketch I had only reserved 10 bytes in data memory for RX data, because I was only sending 10 bytes. My confusion around that was that with the AIR library, you specify in your sketch how many bytes you are receiving each time. I had set this value to 10, believing that the packet handling then would be done using this value. I was wrong, under the hood of the AIR library, it was still accepting packets up to 61 bytes long.
 
So every time the lengt byte was corrupted to a value between 10 and 61, some other data was overwritten by junk (packets with lenght byte > 61 bytes is automatically discarded by the CC1101 packet handler with the AIR library).
 
The simple fix was of course to increase the rxdata space to 61 bytes, I had a simple application and using the G2553 with enough RAM. Doing this, I got what seemed like a rock stable application even at an RF level where most of the packets was corrupted due to poor signal to noise ratio.
 
Not terribly happy with the AIR library, but I guess it wasn't really made for tinkering too much, just running the example sketches as is...
 
Edit: I see that the OP has made the same mistake as I did, he is only reserving 50 bytes in data memory for RX data. So his application will be more stable than mine, because its only packages with length between 50 and 61 that will crash his application.

@@bluehash that was my worry as well. Luckily I just received the correct replacement.
 
However this one came directly from Fort Worth, TX. The original shipment was processed by Digi-Key, judging from the the labels and sent from Thief River Falls. So there's still the possibility of a mislabeled bin somewhere in a warehouse in rural Minnesota.

Got my free shipping bounty today as well.
 
I feel guilty ordering samples on their own, so I thought when buying these things - "well, will add a few other goodies as it won't cost them much more to add to the same package". Funnily though, I received a total of 4 separate packages for all the stuff - one with the booster pack, one with the MSP432, one with only 2 other IC's I paid for, and one with all the samples...
 
I know it's peanuts for TI, but they must have made a loss on my ~45 bucks order! You gotta love TI!
 

My free shipping bounty came in today.
 
All analog components need to be delivered in an anti-static bag, TI certainly takes that seriously.

 
But unfortunately something went wrong here :-(

My free shipping bounty came in today.
 
All analog components need to be delivered in an anti-static bag, TI certainly takes that seriously.

 
But unfortunately something went wrong here :-(

Chapter 24.3 of the datasheet specifies 3.15 to 3.63 V for recommended operating conditions.
http://www.ti.com/lit/ds/symlink/tm4c123gh6zrb.pdf
 
Also see chapter 24.6.2:
 

There are plenty of 3G USB dongles on AliExpress. E.g. this one:
https://www.aliexpress.com/item/beautiful-white-3g-sim-card-modem/520949234.html
 
The question is of course, if there are Linux drivers for it. But at least Windows 2000 is supported :-)

My Pi collection of just tripled today.

 
Any suggestions on how to network the Zero?

Depending on the speed you need you can use a:
 
USB WiFi dongle, 
USB to Ethernet adapter,
serial to Ethernet adapter, or an
ESP8266.
 
The first two will need an adapter or USB OTG cable, and may require a powered hub to work reliably. There are also several boards like this one that add standard USB ports to the Pi (they use pogo pins), which would not require the OTG cable/adapter.
The last two will require you to solder wires or pins to connect them to the GPIO pins, and will be much slower.
 
As for the IoT HAT mentioned by Rei Vilo, I have one of these and it can be ordered without the female header, which would allow using stacking headers thus gaining access to the unused GPIO pins. 

My Pi collection of just tripled today.

 
Any suggestions on how to network the Zero?

More fun in the lab

 

It's a modified aquarium pump with an improvised foot pedal (piece of wood with a hole to cover with your toe to enable the suction action). The airflow is not sufficient for larger parts, but 0603 works great. I got it off eBay two years ago for $20 or so.

More fun in the lab

 

I don't have a BeagleBone, but found these two articles from Ken Shirriff very insightful.
 
The BeagleBone's I/O pins: inside the software stack that makes them work
http://www.righto.com/2016/08/the-beaglebones-io-pins-inside-software.html
 
PRU tips: Understanding the BeagleBone's built-in microcontrollers
http://www.righto.com/2016/08/pru-tips-understanding-beaglebones.html
 
Like all his articles, these are long and VERY detailed. Solidly in the "all you ever wanted to know about.."  category.
 
I suspect (hope) there are more BeagleBone articles coming.