NatureTM

I saw touch ported some rfid reader code to msp430, and so I thought I'd share what I've got for the Parallax RFID reader. The code is a bit bloated and inefficient, but it seems to work well. It compiles from about 1300B to 1500B program size in CCS, depending on if optimization is used, and uses 60B RAM.
 
Most of the work is done in software, so TimerA and the USI are free. I couldn't get it to run at 1MHz, so you'll need an MSP430 with calibration constants or a clock source. It works fine at 8MHz or higher.
 
I used a voltage divider to bring the reader's 5V data line down, and powered the reader with my launchpad's TP1 and TP4 test points.
 

#include "msp430g2231.h" #include #define PIN_RFID_DATA BIT7 // normally high #define PIN_RFID_ENABLE BIT4 // active LOW #define PIN_LED BIT0 #define RFID_BAUD 2400 #define MCLK_FREQUENCY 8000000 #define WDT_DIVIDER 512 #define BYTES_PER_MESSAGE 12 #define BYTES_PER_TAG 10 #define N_ALLOWED_TAGS 1 #define RESULT_SUCCESS 0 #define RESULT_TIMEOUT 1 #define RESULT_ERROR 2 #define RESULT_NO_DATA 3 #define READER_WARMUP 800 #define MIDSCAN_TIMEOUT 200 const char tags[N_ALLOWED_TAGS][bYTES_PER_TAG] = {'3', '6', '0', '0', '6', '2', '2', 'B', 'A', 'E'}; const unsigned long WDT_FREQUENCY = MCLK_FREQUENCY / WDT_DIVIDER; volatile unsigned long wdtCounter = 0; unsigned int stateCount; char rfidData[bYTES_PER_MESSAGE] = {0}; char rfidByte; char bitIndex = 0; char newByte = 0; volatile char haveNewByte = false; volatile char busy = false; char wdtTicksPerBit; unsigned long millis(){ return wdtCounter / ((float)WDT_FREQUENCY / 1000); } void delayMillis(unsigned long milliseconds){ unsigned long wakeTime = wdtCounter + (milliseconds * WDT_FREQUENCY / 1000); while(wdtCounter < wakeTime); } void addBits(char n, char state){ int i; if(state) for(i = 0; i < n; i++){ rfidByte |= 0x01 << bitIndex; bitIndex++; } else for(i = 0; i < n; i++){ rfidByte &= ~(0x01 << bitIndex); bitIndex++; } } char scanTag(){ unsigned long timeout = millis() + READER_WARMUP; char byteIndex = 0; P1OUT &= ~PIN_RFID_ENABLE; while(!haveNewByte){ if(millis() > timeout){ P1OUT |= PIN_RFID_ENABLE; busy = false; return RESULT_NO_DATA; } } if(newByte == 0x0A){ while(byteIndex < BYTES_PER_MESSAGE){ timeout = millis() + MIDSCAN_TIMEOUT; rfidData[byteIndex] = newByte; byteIndex++; haveNewByte = false; while(!haveNewByte){ if(millis() > timeout){ P1OUT |= PIN_RFID_ENABLE; busy = false; return RESULT_TIMEOUT; } } } P1OUT |= PIN_RFID_ENABLE; return RESULT_SUCCESS; } else{ P1OUT |= PIN_RFID_ENABLE; haveNewByte = false; busy = false; return RESULT_ERROR; } } char isValidTag(){ char iTag; char iByte; char valid = true; for(iTag = 0; iTag < N_ALLOWED_TAGS; iTag++){ for(iByte = 0; iByte < BYTES_PER_TAG & valid; iByte++){ if(rfidData[iByte + 1] != tags[iTag][iByte]) valid = false; } } return valid; } void handleMessage(){ if(isValidTag()) P1OUT ^= PIN_LED; } void main(void){ DCOCTL = CALDCO_8MHZ; BCSCTL1 = CALBC1_8MHZ; WDTCTL = WDTPW + WDTTMSEL + WDTIS1;// + WDTIS0; IE1 |= WDTIE; // Enable WDT interrupt wdtTicksPerBit = ((float)WDT_FREQUENCY / RFID_BAUD); P1IE |= PIN_RFID_DATA; P1IES |= PIN_RFID_DATA; P1DIR |= PIN_RFID_ENABLE + PIN_LED; P1OUT |= PIN_RFID_ENABLE + PIN_LED; _BIS_SR(GIE); // enable interrupts while(1){ switch(scanTag()){ case RESULT_SUCCESS: handleMessage(); delayMillis(1000); break; case RESULT_NO_DATA: delayMillis(1000); break; // nothing here for RESULT_ERROR // just scan the tag again right away } } } #pragma vector=WDT_VECTOR __interrupt void watchdog_timer(void){ stateCount++; wdtCounter++; } #pragma vector=PORT1_VECTOR __interrupt void Port1(void){ static char state; unsigned int nBits; P1IES ^= PIN_RFID_DATA; // capture both edges P1IFG &= ~PIN_RFID_DATA; if(!busy){ bitIndex = 0; busy = true; state = 0; stateCount = wdtTicksPerBit * -1; // ignore start bit } else{ nBits = (stateCount / wdtTicksPerBit); // trim off the stop bit if the last data bit is also a "1" // maybe catch some other unexpected behavior too if(nBits + bitIndex > 8) nBits = 8 - bitIndex; addBits(nBits, state); state ^= BIT0; stateCount = 0; } if(bitIndex == 8){ busy = false; newByte = rfidByte; haveNewByte = true; } }
 
This was part of a project I was working on to tweet when my cats poop. I was using some RF Link boards from eBay so I wouldn't need a data connection to the litter box. It turns out RF Links are very noisy, and the code for wireless was just too big for my 2K flash MSP430's. I've got some 8K's on order, but for now my cats' bowel movements will continue to remain a mystery.

this isn't a msp430 project but I am posting it in the other microcontroller since some of you use the evalbot and might be interested.
 
I finally got my evalbot working the way I wanted it to and I can start working on other things. I wanted to share my progress if any one was interested. It's mostly based off the LWIP example but I try to explain every thing I am doing. Its a 2 parter I am not a very good writer and English is not my first language (go easy). Also I don't have any place to host the files. But if any one wants my projects I can send them.
 
Basically, I load a web page off a USB drive. the web page has some javascript to detect if you are using the arrow buttons. It then calls the appropriate CGI function to drive the robot
 
I strapped a wireless router on top to the robot is fully remote controllable. with no wires. Its allot cooler that way.
 
Check it out
http://hobbymc.blogspot.com/2011/03/my-evalbot-first-steps-hosting-webpage.html
and
http://hobbymc.blogspot.com/2011/03/my-evalbot-first-steps-ethernet.html

I've got a couple snippets that are similar to arduino functions. I just assumed this stuff was already out there.
 
Here's what I have for millis and delayMillis:
 

#include "msp430g2231.h" #define MCLK_FREQUENCY 1000000 #define WDT_DIVIDER 512 const unsigned long WDT_FREQUENCY = MCLK_FREQUENCY / WDT_DIVIDER; volatile unsigned long wdtCounter = 0; unsigned long millis(){ return wdtCounter / ((float)WDT_FREQUENCY / 1000); } void delayMillis(unsigned long milliseconds){ // todo: handle rollover unsigned long wakeTime = wdtCounter + (milliseconds * WDT_FREQUENCY / 1000); while(wdtCounter < wakeTime); } void main(void){ DCOCTL = CALDCO_1MHZ; BCSCTL1 = CALBC1_1MHZ; WDTCTL = WDTPW + WDTTMSEL + WDTIS1; IE1 |= WDTIE; _BIS_SR(GIE); // toggle pin every second P1DIR |= BIT0; while(1){ P1OUT ^= BIT0; delayMillis(1000); } } #pragma vector=WDT_VECTOR __interrupt void watchdog_timer(void){ wdtCounter++; }
 
And here's what I have for analogRead:
 

#include "msp430g2231.h" #define ANALOG_PIN 4 unsigned int analogRead(){ ADC10CTL0 |= ADC10SC; while(ADC10CTL1 & ADC10BUSY); return ADC10MEM; } void analogPinSelect(unsigned int pin){ if(pin < 8){ ADC10CTL0 &= ~ENC; ADC10CTL1 = pin << 12; ADC10CTL0 = ADC10ON + ENC + ADC10SHT_0; } } void main(void){ unsigned int analogValue; DCOCTL = CALDCO_1MHZ; BCSCTL1 = CALBC1_1MHZ; WDTCTL = WDTPW + WDTHOLD; // read adc repeatedly analogPinSelect(ANALOG_PIN); while(1){ analogValue = analogRead(); } }

I saw touch ported some rfid reader code to msp430, and so I thought I'd share what I've got for the Parallax RFID reader. The code is a bit bloated and inefficient, but it seems to work well. It compiles from about 1300B to 1500B program size in CCS, depending on if optimization is used, and uses 60B RAM.
 
Most of the work is done in software, so TimerA and the USI are free. I couldn't get it to run at 1MHz, so you'll need an MSP430 with calibration constants or a clock source. It works fine at 8MHz or higher.
 
I used a voltage divider to bring the reader's 5V data line down, and powered the reader with my launchpad's TP1 and TP4 test points.
 

#include "msp430g2231.h" #include #define PIN_RFID_DATA BIT7 // normally high #define PIN_RFID_ENABLE BIT4 // active LOW #define PIN_LED BIT0 #define RFID_BAUD 2400 #define MCLK_FREQUENCY 8000000 #define WDT_DIVIDER 512 #define BYTES_PER_MESSAGE 12 #define BYTES_PER_TAG 10 #define N_ALLOWED_TAGS 1 #define RESULT_SUCCESS 0 #define RESULT_TIMEOUT 1 #define RESULT_ERROR 2 #define RESULT_NO_DATA 3 #define READER_WARMUP 800 #define MIDSCAN_TIMEOUT 200 const char tags[N_ALLOWED_TAGS][bYTES_PER_TAG] = {'3', '6', '0', '0', '6', '2', '2', 'B', 'A', 'E'}; const unsigned long WDT_FREQUENCY = MCLK_FREQUENCY / WDT_DIVIDER; volatile unsigned long wdtCounter = 0; unsigned int stateCount; char rfidData[bYTES_PER_MESSAGE] = {0}; char rfidByte; char bitIndex = 0; char newByte = 0; volatile char haveNewByte = false; volatile char busy = false; char wdtTicksPerBit; unsigned long millis(){ return wdtCounter / ((float)WDT_FREQUENCY / 1000); } void delayMillis(unsigned long milliseconds){ unsigned long wakeTime = wdtCounter + (milliseconds * WDT_FREQUENCY / 1000); while(wdtCounter < wakeTime); } void addBits(char n, char state){ int i; if(state) for(i = 0; i < n; i++){ rfidByte |= 0x01 << bitIndex; bitIndex++; } else for(i = 0; i < n; i++){ rfidByte &= ~(0x01 << bitIndex); bitIndex++; } } char scanTag(){ unsigned long timeout = millis() + READER_WARMUP; char byteIndex = 0; P1OUT &= ~PIN_RFID_ENABLE; while(!haveNewByte){ if(millis() > timeout){ P1OUT |= PIN_RFID_ENABLE; busy = false; return RESULT_NO_DATA; } } if(newByte == 0x0A){ while(byteIndex < BYTES_PER_MESSAGE){ timeout = millis() + MIDSCAN_TIMEOUT; rfidData[byteIndex] = newByte; byteIndex++; haveNewByte = false; while(!haveNewByte){ if(millis() > timeout){ P1OUT |= PIN_RFID_ENABLE; busy = false; return RESULT_TIMEOUT; } } } P1OUT |= PIN_RFID_ENABLE; return RESULT_SUCCESS; } else{ P1OUT |= PIN_RFID_ENABLE; haveNewByte = false; busy = false; return RESULT_ERROR; } } char isValidTag(){ char iTag; char iByte; char valid = true; for(iTag = 0; iTag < N_ALLOWED_TAGS; iTag++){ for(iByte = 0; iByte < BYTES_PER_TAG & valid; iByte++){ if(rfidData[iByte + 1] != tags[iTag][iByte]) valid = false; } } return valid; } void handleMessage(){ if(isValidTag()) P1OUT ^= PIN_LED; } void main(void){ DCOCTL = CALDCO_8MHZ; BCSCTL1 = CALBC1_8MHZ; WDTCTL = WDTPW + WDTTMSEL + WDTIS1;// + WDTIS0; IE1 |= WDTIE; // Enable WDT interrupt wdtTicksPerBit = ((float)WDT_FREQUENCY / RFID_BAUD); P1IE |= PIN_RFID_DATA; P1IES |= PIN_RFID_DATA; P1DIR |= PIN_RFID_ENABLE + PIN_LED; P1OUT |= PIN_RFID_ENABLE + PIN_LED; _BIS_SR(GIE); // enable interrupts while(1){ switch(scanTag()){ case RESULT_SUCCESS: handleMessage(); delayMillis(1000); break; case RESULT_NO_DATA: delayMillis(1000); break; // nothing here for RESULT_ERROR // just scan the tag again right away } } } #pragma vector=WDT_VECTOR __interrupt void watchdog_timer(void){ stateCount++; wdtCounter++; } #pragma vector=PORT1_VECTOR __interrupt void Port1(void){ static char state; unsigned int nBits; P1IES ^= PIN_RFID_DATA; // capture both edges P1IFG &= ~PIN_RFID_DATA; if(!busy){ bitIndex = 0; busy = true; state = 0; stateCount = wdtTicksPerBit * -1; // ignore start bit } else{ nBits = (stateCount / wdtTicksPerBit); // trim off the stop bit if the last data bit is also a "1" // maybe catch some other unexpected behavior too if(nBits + bitIndex > 8) nBits = 8 - bitIndex; addBits(nBits, state); state ^= BIT0; stateCount = 0; } if(bitIndex == 8){ busy = false; newByte = rfidByte; haveNewByte = true; } }
 
This was part of a project I was working on to tweet when my cats poop. I was using some RF Link boards from eBay so I wouldn't need a data connection to the litter box. It turns out RF Links are very noisy, and the code for wireless was just too big for my 2K flash MSP430's. I've got some 8K's on order, but for now my cats' bowel movements will continue to remain a mystery.

Well, the answer is both yes and no.
 
Yes to how it's being said.
No to what devices are being queried.
 
Dallas Semiconductor (now Maxim) created a family of devices that talk 1-wire protocol. Here's a copy/paste from their website:
 
The 1-Wire and iButton products combine the single-contact 1-Wire serial interface with nonvolatile memory, mixed-signal, and secure authentication functions into products that serve a broad range of applications. 1-Wire products are manufactured in traditional IC packaging. iButton products are available in a unique, robust stainless steel package.
 
But how would I use these devices?
 
Well, I have been trying to land a contract with a local company that uses a truck load of ds18b20's in their product. We're talking in the order of 400 to 500 temp sensors in one installation. Every single one of these sensors is on a single 1-wire bus. They monitor the temperature of big piles of stuff to prevent spoilage and whatnot. I'm trying to prove to myself that I can do this and somehow land a job. Wouldn't that be cool to walk into a job interview and do a hands on demo? Scary but cool.
 
Did I answer your question?

I made a square wave synth that has a standard MIDI interface with launchpad. I think I should make the midi stuff into a library so the code isn't so hard to follow, but clean and polished has never been my thing.
 
I seem to always have trouble using the USI with serial that doesn't have a clock signal. [E]rr from IRC told me I should use a state machine. I just had sort of a general idea of what that was when I coded it, so I'm not sure "state machine" is the proper term for what I'm using, but I think it's something like that.
 
Here's the BOM:
1x TI Launchpad or another MSP430
1x 280 ohm resistor (can use internal pull-up instead)
1x 220 ohm resistor
1x Sharp PC900V optoisolator
1x Speaker (I just bought one from RadioShack)
1x MIDI female jack
A midi cable and some kind of midi controller
 
...and the code.
http://naturetm.com/wp-content/uploads/2011/02/main.c
 
There's a little more info and some videos of a Launchpad quintet on my blog.
http://naturetm.com/?p=111

I made a square wave synth that has a standard MIDI interface with launchpad. I think I should make the midi stuff into a library so the code isn't so hard to follow, but clean and polished has never been my thing.
 
I seem to always have trouble using the USI with serial that doesn't have a clock signal. [E]rr from IRC told me I should use a state machine. I just had sort of a general idea of what that was when I coded it, so I'm not sure "state machine" is the proper term for what I'm using, but I think it's something like that.
 
Here's the BOM:
1x TI Launchpad or another MSP430
1x 280 ohm resistor (can use internal pull-up instead)
1x 220 ohm resistor
1x Sharp PC900V optoisolator
1x Speaker (I just bought one from RadioShack)
1x MIDI female jack
A midi cable and some kind of midi controller
 
...and the code.
http://naturetm.com/wp-content/uploads/2011/02/main.c
 
There's a little more info and some videos of a Launchpad quintet on my blog.
http://naturetm.com/?p=111

I made a square wave synth that has a standard MIDI interface with launchpad. I think I should make the midi stuff into a library so the code isn't so hard to follow, but clean and polished has never been my thing.
 
I seem to always have trouble using the USI with serial that doesn't have a clock signal. [E]rr from IRC told me I should use a state machine. I just had sort of a general idea of what that was when I coded it, so I'm not sure "state machine" is the proper term for what I'm using, but I think it's something like that.
 
Here's the BOM:
1x TI Launchpad or another MSP430
1x 280 ohm resistor (can use internal pull-up instead)
1x 220 ohm resistor
1x Sharp PC900V optoisolator
1x Speaker (I just bought one from RadioShack)
1x MIDI female jack
A midi cable and some kind of midi controller
 
...and the code.
http://naturetm.com/wp-content/uploads/2011/02/main.c
 
There's a little more info and some videos of a Launchpad quintet on my blog.
http://naturetm.com/?p=111

I made a square wave synth that has a standard MIDI interface with launchpad. I think I should make the midi stuff into a library so the code isn't so hard to follow, but clean and polished has never been my thing.
 
I seem to always have trouble using the USI with serial that doesn't have a clock signal. [E]rr from IRC told me I should use a state machine. I just had sort of a general idea of what that was when I coded it, so I'm not sure "state machine" is the proper term for what I'm using, but I think it's something like that.
 
Here's the BOM:
1x TI Launchpad or another MSP430
1x 280 ohm resistor (can use internal pull-up instead)
1x 220 ohm resistor
1x Sharp PC900V optoisolator
1x Speaker (I just bought one from RadioShack)
1x MIDI female jack
A midi cable and some kind of midi controller
 
...and the code.
http://naturetm.com/wp-content/uploads/2011/02/main.c
 
There's a little more info and some videos of a Launchpad quintet on my blog.
http://naturetm.com/?p=111

http://www.instructables.com/id/LaunchP ... ansmitter/
 
Not my project

I was just in the same boat 2 days ago. I created my part from scratch.
i used this as a guide
http://www.instructables.com/id/How-to- ... e-CAD-too/
 
a few note though that I changed. the pads for my chip I left them on the default layer. He says he used smd to add them but I types pad. Also DON'T mess with the grid. It gets really annoying when you build your schematics because the wire need to snap to the grid and your pin for it to have a connection.
 
Finally the wire he uses to make the shape of the chip, I put it on the tPlace layer

not me

Well, I've been using it for a bit now. It's actually pretty useful in several applications I didn't expect. For example, I'm tinkering with an rfid reader. Its baud rate isn't easily divided down to from the default clock settings, so I decided to use something like a state machine to read the data. This involved setting up an interrupt to capture and handle the edge transitions of the serial data.
 
Well, it wasn't working. I had a suspicion that the interrupt was taking too long, and missing some transitions. In the past, I would have enabled Timer A and used it to count the cycles in the interrupt. Then I'd have to think about if the time would have an impact on operation.
 
With the logic sniffer, I just added 2 lines to toggle a pin at the beginning of the ISR, and toggled it back at the end. I hooked one lead of the sniffer to the toggled pin, and the other to the serial pin. From there, I was able to see how long the ISR was taking with respect to the serial data rate. I then moved the toggles around within the interrupt to determine which part was the biggest time-waster, and optimized that section. There was less guesswork, and I could get fast visual feedback on how my changes impacted the duration of the ISR.
 
I guess my point is, It's helped a couple times already, and I think it will help more and more as I figure out new ways to use it.
 
As far as how well it works... Well, it's pretty buggy, both on the hardware and software sides. It took me some reading and trial and error to figure out which settings play well together. Some settings when used together cause it to fail. Sometimes it just stops working randomly. The solution is just to disconnect it from the computer, reconnect it, and then restart the software.
 
At first, I was a pretty upset with the bugs. I was starting to think I'd have to make some contributions to the client software just to be able to use it reliably, but I didn't feel like putting another project on my plate. It turns out a lot of the issues are being worked on, and some of the workarounds I was using were documented. Now that I have a feel for what it does and does not like, it's pretty reliable. About 1 in 10 captures fail. Still, I only have to reconnect the device and restart software.
 
Overall, it's been useful to me, both for debugging and as a learning tool. If you want something that's completely reliable and user-friendly, it might not be a good choice for you, at least in its current state. However If you're like me, operating on a tight budget, willing to spend a little time learning to "play nice" with the system, and willing to deal with a few bugs, I think it's an excellent investment.

Ok, I am going to "keep it real" with you guys. I am a complete slob. I live with my girlfriend, and she's pretty much given up on cleaning up after me. I'm just lucky I don't get yelled at every day about it. Sometimes I clean and organize, but it looks like this again after a week or so. I could have tidied up a bit, but then I'd be living a lie! So, as promised, things are about to get "real" in this mofo.
 

 

 

Well, I've been using it for a bit now. It's actually pretty useful in several applications I didn't expect. For example, I'm tinkering with an rfid reader. Its baud rate isn't easily divided down to from the default clock settings, so I decided to use something like a state machine to read the data. This involved setting up an interrupt to capture and handle the edge transitions of the serial data.
 
Well, it wasn't working. I had a suspicion that the interrupt was taking too long, and missing some transitions. In the past, I would have enabled Timer A and used it to count the cycles in the interrupt. Then I'd have to think about if the time would have an impact on operation.
 
With the logic sniffer, I just added 2 lines to toggle a pin at the beginning of the ISR, and toggled it back at the end. I hooked one lead of the sniffer to the toggled pin, and the other to the serial pin. From there, I was able to see how long the ISR was taking with respect to the serial data rate. I then moved the toggles around within the interrupt to determine which part was the biggest time-waster, and optimized that section. There was less guesswork, and I could get fast visual feedback on how my changes impacted the duration of the ISR.
 
I guess my point is, It's helped a couple times already, and I think it will help more and more as I figure out new ways to use it.
 
As far as how well it works... Well, it's pretty buggy, both on the hardware and software sides. It took me some reading and trial and error to figure out which settings play well together. Some settings when used together cause it to fail. Sometimes it just stops working randomly. The solution is just to disconnect it from the computer, reconnect it, and then restart the software.
 
At first, I was a pretty upset with the bugs. I was starting to think I'd have to make some contributions to the client software just to be able to use it reliably, but I didn't feel like putting another project on my plate. It turns out a lot of the issues are being worked on, and some of the workarounds I was using were documented. Now that I have a feel for what it does and does not like, it's pretty reliable. About 1 in 10 captures fail. Still, I only have to reconnect the device and restart software.
 
Overall, it's been useful to me, both for debugging and as a learning tool. If you want something that's completely reliable and user-friendly, it might not be a good choice for you, at least in its current state. However If you're like me, operating on a tight budget, willing to spend a little time learning to "play nice" with the system, and willing to deal with a few bugs, I think it's an excellent investment.

Bluehash!
 
I'd like to do a poll to see what compiler tools everyone is using. Can you tweak the forum to allow polls?
 
Here's what's on my mind.
 
I use CCS4 and so my code snippets are written in that fashion. I understand that mspgcc is different enough that the code has to be re-written before it will compile.
 
What tools do you use?
 
Options:
1. CCS4
2. IAR
3. GCC
4. Rowley
5. Other
 
What do you think?

This can be fixed using diodes. In fact, even if you decide to use solution like 74hc138/151/393, you will still need diodes because 138's outputs are not open collector.
 
3 chips, 8 diodes, 8 resistors, 64 switches

 
this one uses 3 74hc03 open collector NAND gates, shown only 5, but you get the idea

 
last but not least, 64 switches with shift register and 6 pins, 3 to address 138, clk, latch, and serial in. 2 chips only.

I guess it all depends on the manufacturer.
 
I think the problem is that the lower 4017 will always saturate one of the transistors no matter if the collector is at Vcc or not.
The current will flow through 2k2, T1, 2k2, and then the final transistor.
Another problem I see, if you push two switches at the same time, you will short 2 outputs of the top 4017 when one is high and other low.
How about something like this:

 
Other suggestions:
1. instead of transistors, use 10 open collector AND or NAND gates, 3 chips.
2. if you can live with 80 switches, how about multiplexer, like 74hc151 and a binary counter instead of lower 4017.
3. if 64 switches are enough, demultiplexer (74hc138), multiplexer and one 8 stage or two 4 stage binary counters.

Here's an interesting thread about this issue:
http://e2e.ti.com/support/microcontrollers/msp43016-bit_ultra-low_power_mcus/f/166/t/60157.aspx
 
I guess it boils down to the fact that binary representation isn't oficially supported by the C language. A couple of solutions are offered by the thread. One is that header file with all the defines already made, the other is a macro. I'm not an expert on compilers, but I'd think the header would do the job fine without wasting cpu cycles.

Here's an interesting thread about this issue:
http://e2e.ti.com/support/microcontrollers/msp43016-bit_ultra-low_power_mcus/f/166/t/60157.aspx
 
I guess it boils down to the fact that binary representation isn't oficially supported by the C language. A couple of solutions are offered by the thread. One is that header file with all the defines already made, the other is a macro. I'm not an expert on compilers, but I'd think the header would do the job fine without wasting cpu cycles.

Small warning for those who do not read manuals:
 
TI produces for us a very good kit at a very competitive price. But no thing is not entirely perfect.
 
Into this kit is pin P1.3 connected to button S2. OK, no problem. But for debouncing button, RC combination C34/R24 is also attached to P1.3.
 
And here's the problem. C34/R24 is not detachable. Still not problem to us? Look to the simple sample code:

#include "io430.h" #include "intrinsics.h" const unsigned char FONT[] = { 0x00, 0x06, 0x22, 0x00, 0x6D, 0x00, 0x00, 0x20, 0x39, 0x0F, 0x00, 0x70, 0x08, 0x40, 0x00, 0x52, 0x3F, 0x06, 0x5B, 0x4F, 0x66, 0x6D, 0x7D, 0x07, 0x7F, 0x6F, 0x48, 0x48, 0x39, 0x48, 0x0F, 0x53, 0x00, 0x77, 0x7C, 0x39, 0x5E, 0x79, 0x71, 0x6F, 0x76, 0x30, 0x1E, 0x76, 0x38, 0x15, 0x54, 0x3F, 0x73, 0x67, 0x50, 0x6D, 0x78, 0x3E, 0x1C, 0x2A, 0x76, 0x6E, 0x5B, 0x39, 0x64, 0x0F, 0x23, 0x08, 0x20, 0x77, 0x7C, 0x58, 0x5E, 0x79, 0x71, 0x6F, 0x74, 0x04, 0x1E, 0x76, 0x18, 0x15, 0x54, 0x5C, 0x73, 0x67, 0x50, 0x6D, 0x78, 0x3E, 0x1C, 0x2A, 0x76, 0x6E, 0x5B, 0x39, 0x30, 0x0F, 0x40, 0x00 }; // ASCII table [0x20 - 0xFF] /********************************************************************************************/ /* Test - minimalize power consumption of MSP430G2211 */ /* */ /* I use one character from the display LCD-S301C31TR, connected to port 1 */ /* P1.0 = Seg.A1, P1.1 = Seg.B1, P1.2 = Seg.C1, P1.3 = Seg.D1, */ /* P1.4 = Seg.E1, P1.5 = Seg.F1, P1.6 = Seg.G1, P1.7 = COM */ /* */ /* Power consumption is 76uA/3.5V, 65uA/3V, 33uA/1.5V (problem is RC of P1.3) */ /* Without P1.3 power consumption is 3.2uA/3.5V, 2.7uA/3V, 1.35uA/1.5V */ /********************************************************************************************/ int main( void ) { unsigned int i, j; WDTCTL = WDTPW + WDTHOLD; // Stop watchdog timer to prevent time out reset BCSCTL3 |= LFXT1S1; // VLOCLK enable (my VLOCLK worked at ~~10kHz) TACCR0 = 50u - 1u; // 10kHz/200Hz = 50 - interrupt every 5msec (200Hz) TACTL |= TASSEL_1 + ID_0 + MC_1; // Timer A clock source select: 1 - ACLK = VLOCLK // Timer A input divider: 0 - /1 // Timer A mode control: 1 - Up to CCR0 TACCTL0 = CCIE; // Capture/compare interrupt enable __enable_interrupt(); //P1DIR = 0xFF; // Set all P1 to output direction // - alternative - P1DIR = 0xFF - BIT3; // Set all P1 to output direction (without P1.3) for(; // Never ending story { for(i=0; i<(128-32); i++) // Browse ASCII table chars [0x20 - 0xFF] { for(j=0; j<100; j++) // Any character displayed 0.5 sec { if(P1IN & BIT7) P1OUT = FONT[i]; else P1OUT = ~FONT[i]; __bis_SR_register(LPM3_bits); // ZZZZZZZZZzzzzzzz.......... // CPU, MCLK, SMCLK, DCO are disabled, ACLK are active } } } } #pragma vector = TIMERA0_VECTOR // Timer A CC0 __interrupt void DELAY(void) { __bic_SR_register_on_exit(LPM3_bits); // WAKE UP, BABY !!! }
 
OK. The problem is here, what is the solution?
 
1) Do not use P1.3 (not good, this small cheap chips have a few pins ...)
2) Move your lovely chip out of the Launchpad to Breadboard. Thanks to SpyBiWire you need only four wires ...
3) Simply ignore this problem
4) Modify your Launchpad to fix this issue
 
Modify. But how?
 
My suggestion is: break the route from C34/R24 to pin P1.3 of IC1 socket. Remove pinheader J5. Drill two new holes between S2 and J5. Solder a new, six-pin header at location J5. Use two new pins on the pinheader for detachable connection from C34/R24 to button S2. Route S2 to P1.3.
 
And that is all. End of story.

Here's a little code template I have created.
Not sure what I am going to use it for, but someone might find it helpful.
Handling of the interrupts is done in main rather than in interrupt routine itself.
 

#include "msp430g2231.h" #define EV_TIMER BIT0 #define EV_PORT1 BIT1 #define EV_WDT BIT2 #define EV_USI BIT3 unsigned char events = 0; void main(void) { WDTCTL = WDTPW + WDTHOLD; // stop WDT // configure all here __bis_SR_register(LPM0_bits + GIE); // switch to LPM0 with interrupts while(1) { while(events) { if(events & EV_TIMER) { events &= EV_TIMER; // do your thing //clear TAIFG, etc. //enable interrupts, main, CCR0, CCR1, etc. } else if(events & EV_PORT1) { events &= ~EV_PORT1; // do your thing //P1IFG &= ~BITn; // clear IFG //P1IE |= BITn; // enable interrupt } else if(events & EV_WDT) { events &= ~EV_WDT; // do your thing IFG1 &= ~WDTIFG; //IE1 |= WDTIE; // enable WDT interrupt } else if(events & EV_USI) { events &= ~EV_USI; // do your thing USICTL1 &= ~USIIFG; //USICTL1 |= USIIE; // enable interrupts } } __bis_SR_register(LPM0_bits); // switch to LPM0 } } // WDT interrupt service routine #pragma vector=WDT_VECTOR __interrupt void Watchdog_Timer (void) { //IE1 &= ~WDTIE; // disable WDT interrupt events |= EV_WDT; __bic_SR_register_on_exit(LPM0_bits); // exit LPM0 } // Timer A interrupt service routine #pragma vector=TIMERA0_VECTOR __interrupt void Timer_A (void) { //disable interrupts, main, CCR0, CCR1, etc. events |= EV_TIMER; __bic_SR_register_on_exit(LPM0_bits); // exit LPM0 } // Port 1 interrupt service routine #pragma vector=PORT1_VECTOR __interrupt void Port_1(void) { //P1IE &= ~BITn; // disable interrupt events |= EV_PORT1; __bic_SR_register_on_exit(LPM0_bits); // exit LPM0 } // USI interrupt service routine #pragma vector = USI_VECTOR __interrupt void USI_TXRX (void) { //USICTL1 &= ~USIIE; // disable interrupts events |= EV_USI; __bic_SR_register_on_exit(LPM0_bits); // exit LPM0 } // TODO Add ADC routine

I took a look at the schematic and it's supposed to be that way. They're both pulled high through a 47k resistor. Why? I'm not sure. It looks like the pins are connected to some internal peripheral pins labeled SOMI1 and SIMO1.

Hi all,
 
Browsing through DangerousPrototypes blog today, I saw Ian posted some info about TI's floating-point Piccolo MCUs. Texas Instruments has development boards with F28069 in memory stick form factor on promotion now ($11 if using the promo code Piccolo11 at checkout).
 
It seems those Piccolo MCUs have far more capabilities than I'll ever use in my simplistic projects, but there are a lot of clever people in this forum who may find it useful
 
You can see and order the dev board here:
https://estore.ti.com/TMDX28069USB-F28069-Piccolo-controlSTICK-P2257C43.aspx?DCMP=F2806x&HQS=Other+EM+f2806x_em1_es
 
Here is where I got this tip from:
http://dangerousprototypes.com/2011/01/13/c2000-piccolo-f2806x-mcu/
 
Cheers,
zn

That seems like a pretty good way of doing it. The datasheet says the converter's output ranges from 1Hz to 1MHz, so you could probably check the counter at 1 sec intervals. I bet with some experimentation you'll find an interval that works well with the chip and your project. That chip also features a divider in case you feel the counter-incrementing interrupt occurs too often.
 
An alternative could be to user Timer A in capture mode. You could trigger the capture with the converter's output. An interrupt occurring on capture could be used to measure the interval between pulses. It would give you a reading on light intensity much more often, but you *may* need to do some extra work averaging out the values or dealing with noise. This might be a good method for threshold detection ie detecting a camera strobe.