igendel

It generates an ELF file.  Not sure how to pull the binary copy of the sections themself, but you can disassemble using (e.g. for msp430)-
 
<energia install dir>/hardware/tools/msp430/bin/msp430-objdump -CD <file.elf>
 
(or for all other ARM platforms)-
<energia install dir>/hardware/tools/lm4f/bin/arm-none-eabi-objdump -CD <file.elf>

Indeed, this isn't easy. I made a little POV project some time ago (shamed to admit, with an ATtiny85 ) and it took plenty of videos until I got something passable. It's about lowering the framerate (if the camera allows) and having as much exposure as possible for each frame. Here's the result, BTW.
 
Awesome job, @@cubeberg! It looks fantastic.

@@igendel, your prize is one it's way. Let us know when you receive it and thank you to Saelig for their sponsorship.
 

Well, I guess I paid a certain price for trying to be a gentleman and not vote for myself
Congratulations people, those were very inspiring projects, and totally deserving the prizes!

I did say a cetrain price
Anyway, the competitors set a really high standard, I'll have to brush up seriously for the next time.
 
Thanks for organizing this! Must have been quite an effort by itself.

@@igendel Looks like I missed the first page. Updating now.
Sorry.

Heh, with this and my oh-so-useful Morse code trainer, we can conquer the market
 
Thanks for the answer. BTW, your project reminded me a little of this - the bus location/timing signal. Now there's a system the bus faring hacker could really use!

Thanks for shattering my plans for consumer gadget world domination
 
Technically the range of AIS is about 50 nautical miles, but that requires an unobstructed view and a properly placed and tuned antenna.
http://www.marinetraffic.com/p/faq#4
 
With my wimpy dipole antenna (two straight hookup wires) and the wrong impedance matching (50 ohm instead of 73 for a dipole) I was able to receive the packets from the base station 11 kilometers away when in line of sight. When I was parked at the waterfront with the antenna laying on my car's dashboard, I was able to receive messages of ships in line of sight about 2.5 kilometers away and 500 meters when obstructed by buildings.

I'd put a small piece of paper over the LED I'd love to see how this works out on the different "platform"!
 
 
 
No need - Apparently there was something wrong with the file itself (too large resolution?) - I reduced the resolution, the size went from ~370K to ~204K and it was uploaded fine for the competition post.
 
Here it is:

As promised, here's the video of the device in action. Sorry for the English, accent and shaky camera
 


(https://www.youtube.com/watch?v=0og_ZvkAL6A)
 
I tries to attach an updated schematic (for the standalone chip instead of the Launchpad), but my browser encounters  some script problem, so that'll have to wait I guess.

The educational boosterpack has an LCD, a buzzer and an RGB LED. When using the accelerometer or gator holes as key, you could do this whole project adhering to "standards". That would be kinda cool I think.
 
Oh, use
instead of just [code ]

Hello!

Lately I have been teaching myself the ancient art of Morse Code. For transmission trainging I got a proper Straight Key from eBay, and wrote a sketch for an Arduino Leonardo that converts the "dots" and "dashes" on the key to keyboard input for the PC. It worked, but then I read about the current 43Oh Contest of the Month and decided to take this to the next level...

So here it is - the MSP430 Morse Trainer 1.0

This standalone device has two inputs: the Morse straight key (which is essentially a momentary, "Normally-Open" switch) and a microswitch. The microswitch accepts, in the spirit of Morse code, short presses (to reset current mode) and long ones (to switch mode). There are two modes of operation: "Free", which allows the user to key in different characters freely, and "Test" which generates random test strings that the user is required to key in. The test mode keeps score for the current string, and also displays it using a simple "animation" at the end of each test.
 
Here's an image of the free mode. I had to dim the display's backlight using a resistor because it blinded the camera. Believe me, it looks a lot better in real life.

Edit: Yes, there's a typo in there... or is it a keyo? :-)
 
All text is displayed on a 16x2 LCD; I got one that said "3V" in the eBay description, but maybe standard "5V" ones would work just as well. Two charlieplexed LEDs indicate the current mode on the panel, and there's a "continuous" piezo buzzer that echoes the key because you have to have beeps in Morse code :-)
 
Here's the test mode in mid-test. Notice the V's and the X's that mark right and wrong answers.

 
And when the test is done, the score is shown both in the text above and in bar animation that ends like this:

 
The entire thing is run by a single, stand-alone MSP430G2452. I programmed it with Energia and an MSP430 Launchpad. I chose it over the MSP430G2553 because I wanted to keep that one for other projects, and for the challenge of squeezing the code into the 2452's smaller space. Now, the code is far from optimal - I'm still not familiar with the inner workings of these chips - but I'm kind of proud of the economical Morse-to-ASCII conversion. The code uses the LCD library that comes with Energia.
 
Here's my code:
MorseTrainer.ino
Can someone please tell me how to paste the code in a nice box with vertical scroll and syntax highlight? The "code" tag isn't giving me that.
 
 
A cardboard structure (originally, the lid of a webcam packaging) houses the components. Most of the stuff is held in place using hot glue, and there are some LED holders too. I printed a "panel" on paper and taped it to the cardboard; it includes the Morse code reference. Here's the MS-Word file for printing the panel:
 
MorseTable.doc
 
That's how it all looks inside. Wires are connected with headers for modularity and due to laziness ;-)

Edit: The red wire for the piezo buzzer (bottom right) isn't connected to the right place - I disconnected it temporarily and forgot to put it back for the picture. It should go to any 3.3V connection.
Edit II: Of course, the power source isn't in the picture. There's a 3.3V Voltage Regulator there that accepts ~3.5-6V, so the power lines from a USB are optimal. It can also take 3-4 AA/AAA batteries, a LiPo cell etc.
 
 
And the schematics:

 
I will post this project on the Contest of the Month thread as soon as I make a proper video. Comments and questions are obviously welcome!

As promised, here's the video of the device in action. Sorry for the English, accent and shaky camera
 


(https://www.youtube.com/watch?v=0og_ZvkAL6A)
 
I tries to attach an updated schematic (for the standalone chip instead of the Launchpad), but my browser encounters  some script problem, so that'll have to wait I guess.

Hello!

Lately I have been teaching myself the ancient art of Morse Code. For transmission trainging I got a proper Straight Key from eBay, and wrote a sketch for an Arduino Leonardo that converts the "dots" and "dashes" on the key to keyboard input for the PC. It worked, but then I read about the current 43Oh Contest of the Month and decided to take this to the next level...

So here it is - the MSP430 Morse Trainer 1.0

This standalone device has two inputs: the Morse straight key (which is essentially a momentary, "Normally-Open" switch) and a microswitch. The microswitch accepts, in the spirit of Morse code, short presses (to reset current mode) and long ones (to switch mode). There are two modes of operation: "Free", which allows the user to key in different characters freely, and "Test" which generates random test strings that the user is required to key in. The test mode keeps score for the current string, and also displays it using a simple "animation" at the end of each test.
 
Here's an image of the free mode. I had to dim the display's backlight using a resistor because it blinded the camera. Believe me, it looks a lot better in real life.

Edit: Yes, there's a typo in there... or is it a keyo? :-)
 
All text is displayed on a 16x2 LCD; I got one that said "3V" in the eBay description, but maybe standard "5V" ones would work just as well. Two charlieplexed LEDs indicate the current mode on the panel, and there's a "continuous" piezo buzzer that echoes the key because you have to have beeps in Morse code :-)
 
Here's the test mode in mid-test. Notice the V's and the X's that mark right and wrong answers.

 
And when the test is done, the score is shown both in the text above and in bar animation that ends like this:

 
The entire thing is run by a single, stand-alone MSP430G2452. I programmed it with Energia and an MSP430 Launchpad. I chose it over the MSP430G2553 because I wanted to keep that one for other projects, and for the challenge of squeezing the code into the 2452's smaller space. Now, the code is far from optimal - I'm still not familiar with the inner workings of these chips - but I'm kind of proud of the economical Morse-to-ASCII conversion. The code uses the LCD library that comes with Energia.
 
Here's my code:
MorseTrainer.ino
Can someone please tell me how to paste the code in a nice box with vertical scroll and syntax highlight? The "code" tag isn't giving me that.
 
 
A cardboard structure (originally, the lid of a webcam packaging) houses the components. Most of the stuff is held in place using hot glue, and there are some LED holders too. I printed a "panel" on paper and taped it to the cardboard; it includes the Morse code reference. Here's the MS-Word file for printing the panel:
 
MorseTable.doc
 
That's how it all looks inside. Wires are connected with headers for modularity and due to laziness ;-)

Edit: The red wire for the piezo buzzer (bottom right) isn't connected to the right place - I disconnected it temporarily and forgot to put it back for the picture. It should go to any 3.3V connection.
Edit II: Of course, the power source isn't in the picture. There's a 3.3V Voltage Regulator there that accepts ~3.5-6V, so the power lines from a USB are optimal. It can also take 3-4 AA/AAA batteries, a LiPo cell etc.
 
 
And the schematics:

 
I will post this project on the Contest of the Month thread as soon as I make a proper video. Comments and questions are obviously welcome!

Hello!

Lately I have been teaching myself the ancient art of Morse Code. For transmission trainging I got a proper Straight Key from eBay, and wrote a sketch for an Arduino Leonardo that converts the "dots" and "dashes" on the key to keyboard input for the PC. It worked, but then I read about the current 43Oh Contest of the Month and decided to take this to the next level...

So here it is - the MSP430 Morse Trainer 1.0

This standalone device has two inputs: the Morse straight key (which is essentially a momentary, "Normally-Open" switch) and a microswitch. The microswitch accepts, in the spirit of Morse code, short presses (to reset current mode) and long ones (to switch mode). There are two modes of operation: "Free", which allows the user to key in different characters freely, and "Test" which generates random test strings that the user is required to key in. The test mode keeps score for the current string, and also displays it using a simple "animation" at the end of each test.
 
Here's an image of the free mode. I had to dim the display's backlight using a resistor because it blinded the camera. Believe me, it looks a lot better in real life.

Edit: Yes, there's a typo in there... or is it a keyo? :-)
 
All text is displayed on a 16x2 LCD; I got one that said "3V" in the eBay description, but maybe standard "5V" ones would work just as well. Two charlieplexed LEDs indicate the current mode on the panel, and there's a "continuous" piezo buzzer that echoes the key because you have to have beeps in Morse code :-)
 
Here's the test mode in mid-test. Notice the V's and the X's that mark right and wrong answers.

 
And when the test is done, the score is shown both in the text above and in bar animation that ends like this:

 
The entire thing is run by a single, stand-alone MSP430G2452. I programmed it with Energia and an MSP430 Launchpad. I chose it over the MSP430G2553 because I wanted to keep that one for other projects, and for the challenge of squeezing the code into the 2452's smaller space. Now, the code is far from optimal - I'm still not familiar with the inner workings of these chips - but I'm kind of proud of the economical Morse-to-ASCII conversion. The code uses the LCD library that comes with Energia.
 
Here's my code:
MorseTrainer.ino
Can someone please tell me how to paste the code in a nice box with vertical scroll and syntax highlight? The "code" tag isn't giving me that.
 
 
A cardboard structure (originally, the lid of a webcam packaging) houses the components. Most of the stuff is held in place using hot glue, and there are some LED holders too. I printed a "panel" on paper and taped it to the cardboard; it includes the Morse code reference. Here's the MS-Word file for printing the panel:
 
MorseTable.doc
 
That's how it all looks inside. Wires are connected with headers for modularity and due to laziness ;-)

Edit: The red wire for the piezo buzzer (bottom right) isn't connected to the right place - I disconnected it temporarily and forgot to put it back for the picture. It should go to any 3.3V connection.
Edit II: Of course, the power source isn't in the picture. There's a 3.3V Voltage Regulator there that accepts ~3.5-6V, so the power lines from a USB are optimal. It can also take 3-4 AA/AAA batteries, a LiPo cell etc.
 
 
And the schematics:

 
I will post this project on the Contest of the Month thread as soon as I make a proper video. Comments and questions are obviously welcome!

Hello!

Lately I have been teaching myself the ancient art of Morse Code. For transmission trainging I got a proper Straight Key from eBay, and wrote a sketch for an Arduino Leonardo that converts the "dots" and "dashes" on the key to keyboard input for the PC. It worked, but then I read about the current 43Oh Contest of the Month and decided to take this to the next level...

So here it is - the MSP430 Morse Trainer 1.0

This standalone device has two inputs: the Morse straight key (which is essentially a momentary, "Normally-Open" switch) and a microswitch. The microswitch accepts, in the spirit of Morse code, short presses (to reset current mode) and long ones (to switch mode). There are two modes of operation: "Free", which allows the user to key in different characters freely, and "Test" which generates random test strings that the user is required to key in. The test mode keeps score for the current string, and also displays it using a simple "animation" at the end of each test.
 
Here's an image of the free mode. I had to dim the display's backlight using a resistor because it blinded the camera. Believe me, it looks a lot better in real life.

Edit: Yes, there's a typo in there... or is it a keyo? :-)
 
All text is displayed on a 16x2 LCD; I got one that said "3V" in the eBay description, but maybe standard "5V" ones would work just as well. Two charlieplexed LEDs indicate the current mode on the panel, and there's a "continuous" piezo buzzer that echoes the key because you have to have beeps in Morse code :-)
 
Here's the test mode in mid-test. Notice the V's and the X's that mark right and wrong answers.

 
And when the test is done, the score is shown both in the text above and in bar animation that ends like this:

 
The entire thing is run by a single, stand-alone MSP430G2452. I programmed it with Energia and an MSP430 Launchpad. I chose it over the MSP430G2553 because I wanted to keep that one for other projects, and for the challenge of squeezing the code into the 2452's smaller space. Now, the code is far from optimal - I'm still not familiar with the inner workings of these chips - but I'm kind of proud of the economical Morse-to-ASCII conversion. The code uses the LCD library that comes with Energia.
 
Here's my code:
MorseTrainer.ino
Can someone please tell me how to paste the code in a nice box with vertical scroll and syntax highlight? The "code" tag isn't giving me that.
 
 
A cardboard structure (originally, the lid of a webcam packaging) houses the components. Most of the stuff is held in place using hot glue, and there are some LED holders too. I printed a "panel" on paper and taped it to the cardboard; it includes the Morse code reference. Here's the MS-Word file for printing the panel:
 
MorseTable.doc
 
That's how it all looks inside. Wires are connected with headers for modularity and due to laziness ;-)

Edit: The red wire for the piezo buzzer (bottom right) isn't connected to the right place - I disconnected it temporarily and forgot to put it back for the picture. It should go to any 3.3V connection.
Edit II: Of course, the power source isn't in the picture. There's a 3.3V Voltage Regulator there that accepts ~3.5-6V, so the power lines from a USB are optimal. It can also take 3-4 AA/AAA batteries, a LiPo cell etc.
 
 
And the schematics:

 
I will post this project on the Contest of the Month thread as soon as I make a proper video. Comments and questions are obviously welcome!

I beg to differ; since not ALL the cases are identical (be it 1/2000 or 1/20,000,000,000), this shouldn't be the compiler's decision to make. The microcontroller is a logic device, not a statistical device... Where would you put the limit? is 1 in 5 "optimizable"? 1 in 100? and if it insists on optimizing, it should at least be consistent and optimize "i % 2000" as well. To make a long story short, what we have here is unpredictable compiler behavior and that can't be good.
 
Of course, the code I wrote is not too smart and I wouldn't use this technique in real development. But that's not the point.

Depends how the NOP is expressed. Since C doesn't have a NOP instruction, the right way is through an intrinsic like __nop() which is compiler-specific and is documented to have a particular effect including that it will not be moved or discarded.
 
If you try to use things like asm statements and don't get the details right it might well be removed. For example, in gcc the following is supposed to be a nop:

#define nop() __asm__ __volatile__("nop":It's not necessarily trustworthy, though: the RTL specifies that there is no impact on any registers, so even though it's volatile it technically could be rearranged relative to any neighboring instructions that don't involve volatile operations. (Probably wouldn't be, since quality-of-implementation suggests that any volatile ASM statement be a barrier to moves, but as gcc optimizes more and more that expectation might be dropped.) 
Had it been instead:

#define nop() __asm__ ("nop":the compiler could well move it. It probably wouldn't drop it, though, since it doesn't actually look at the contents of the string "nop" to determine what effect is being requested. 
(In fact, I encountered exactly this problem with "eint"/"dint" done in asm instructions before I added them as intrinsics to mspgcc: they moved to where they didn't do what I needed them to do.)
 
This is why intrinsics are generally better than inline assembly: the compiler knows what's being asked of it and can ensure that it respects the meaning of the resulting program. Similarly if you do choose to use inline assembly, always use RTL to express the dependencies rather than reference registers in the template (like "mov r2, r15") because the compiler might be using r15 for something else and won't see the reference inside the template.
 
Interesting. In my experience, this sort of thing is extremely common.

Ah k, I guess it never occurred to me to try doing it that way  The only conflict I'd be curious about is ISRs for more complex projects... since Energia (& Arduino) provide their own ISRs for various IRQ sources.
 
As far as compiler settings, it would either be in preferences.txt or possibly non-settable.  Looking around at the defaults, I don't see anything for it (on my Mac this is /Applications/Energia.app/Contents/Resources/Java/lib/preferences.txt) so my suspicion is the compiler settings are hard-coded in the Java application code.
 
In either case, I prefer to write apps freehand and use Makefiles while employing the msp430-gcc and mspdebug tools (adding their location to $PATH).  That way I have complete control over the build environment.

Try this:
#include <msp430G2553.h> main() { long i = 0; WDTCTL = WDTPW + WDTHOLD; //for 16MHz clock, uncomment following 2 lines //    BCSCTL1 = CALBC1_16MHZ; //    DCOCTL = CALDCO_16MHZ; P1DIR = 65; P1OUT = 0; while (1) { i++; if (i == 200000) { P1OUT ^= 1; if (P1OUT & 1) P1OUT ^= 64; i = 0; } } }

First, the default clock speed is 1MHz, not 16MHz.
 
When you change to
 if (i == 2000) { your LED is blinking, but it's blinking very fast.
 
try changing i to long and do i == 200000 or similar

It is quite slow unless a power of 2 is used, for example n % 512
 

try 200000UL and 2000000UL

@@igendel
 
Try search "udev rules" in this forum 1st. I can explain more if needed.

No doubt. When I get some free time to play with the Launchpad, I'm gonna bug you all big time! ;-)
 
Be careful with what you wish...
 
ok, here goes, attaching the code.
 
 
RollBall.zip

Hi all,
 
Just to show off a little something I did It's an LCD display of a "ball" rolling around on a spotted surface, and bouncing from the boundries. The direction and speed of rolling is determined by the tilt of the entire setup. 
 
The hardware is a Nokia 5110 LCD breakout and a cheap 3-axis accelerometer breakout, both hooked directly to the MSP430 Launchpad. Code was written in Energia. 
 
Here's the video:

 
I don't consider the code clean enough to publish, however I'll be happy to answer any questions about it.
 
Happy coding!