Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


DanAndDusty last won the day on October 24 2011

DanAndDusty had the most liked content!

About DanAndDusty

  • Rank
    Level 1

Profile Information

  • Gender
    Not Telling
  • Location
    Sussex, UK

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Id love one of these, they look so cool.. Especially the black. Im in the UK too so no worries about Import Tax (I have something sitting in the post office I had to pay
  2. Hey, bh. Just a thought. Is there any chance you could throw in one of the freebie launchpad pcbs with my order please? Will be fun to take a closer look at.<br />Ta<br />Dan<br />
  3. There is indeed. I'm on my phone at the moment so I can't check where. But its in the project properties, arm linker sections. I think by default its set to 256 bytes. I usually set it to 2048 bytes as a minimum.
  4. Paid $35.13 (Module + PCB)...Fee paid.. Thanks for arranging the Groupbuy B#
  5. 1. Bluehash-----------------2--------------------US 2. Gwdeveloper-----------1---------------------US 3. Reaper7-----------------1---------------------PL 4. DanAndDusty-----------1--------------------UK
  6. Hi Potatochan, looking at your code the problem you have is not to do with the for loop (which you are using as a software delay) but with the fact that your port isn't in a "known state".. In pseudo code you have.... Put the WatchDogTimer on hold.. (Tell the watch dog.. Go on hold. If you don't do this your 430 will reset regularly) Tell the 430 that in Port 1 bits 0 and 6 are used for output. Loop forever Toggle bit 6 of port 1 If the LED on bit 6 is on turn it off, if its off turn it on count to 5000 Counting is purely as a delay Toggle bit 0 of port 1 As with the other toggle.. but for the other LED Continue the loop As you can see.. all the interactions with P1OUT are dependent on what was there before. You noticed them in sync and not in sync not because of what I was looping to, but because of what they were on before. Im guessing you run the code (maybe stepping through) then edited the number, re-uploaded and run the code. Depending on where you stopped the code the LEDs could have been on or off semi randomly. The solution is to put the port into a known state. After the line that sets P1DIR your problem would be solved if you put in P1OUT = 0; Which says take every bit low. As to the counting loop being optimised out as pabigot said.. think about when you played Hide and Seek as a child.. (Im hoping this game is universal ) The game starts with 1 child counting to a number maybe 100. This was purely to give a delay before they started hunting. Now some children counted slow and some counted fast, and some were clever and thought that the counting achieved nothing and could be optimised to "1, 2, skip a few, 99 100". The compiler when in release mode can optimise your code and decide "That counting achieves nothing so I can safely ignore it".. so your code behaves differently in release mode from debug mode. The solution here is to use __delay_cycles(xx) where xx is the number of cycles to pause. At 1MHz using __delay_cycles(1000000) will always wait 1 second, __delay_cycles(100000) will always delay 1/10th of a second. I can't remember the default speed of the 430 I think its either 1MHz or 1.1MHz.. I always set the clock to one of the calibrated speeds at the sametime as I put the WDT in hold mode. The lines to do this are.... BCSCTL1 = CALBC1_1MHZ; // Set range DCOCTL = CALDCO_1MHZ; // Set DCO step and modulation The way I would have written your code would be.... #include <msp430.h> #define LED_RED BIT0 // The Red LED is on P1.0 #define LED_GREEN BIT6 // Green LED is P1.6 void main(void) { WDTCTL = WDTPW + WDTHOLD; BCSCTL1 = CALBC1_1MHZ; // Tell the 430 to run at a calibrated DCOCTL = CALDCO_1MHZ; // Clk speed of 1MHz P1DIR = LED_RED + LED_GREEN; // We want outputs on Red and Green LEDs only P1OUT = 0; // Start with both LEDs off while(1) { P1OUT ^= LED_GREEN; // Toggle state of the green LED __delay_cycles(500000); // Delay for 1/2 a second (clock is at a known 1MHz) P1OUT ^= LED_RED; // Toggle the red LED } } I think this code would do what you want. Things to notice are... 1) The #defines at the top. These tell the compiler "Whenver you see LED_RED in the code replace it with BIT0". BIT0 is itself a #define for 0x1, BIT6 is a #define for 0x40. These take a little longer than using 0x41 instead of LED_RED + LED_GREEN, but this delay is done by the compiler on your PC before the code gets to your 430. So the 430 gets the exact same code as with what you had written and so runs with exactly the same efficiency, but for someone reading your code it is obvious which LED is being toggled at which line. 2) Setting the clock to calibrated speeds. The 430 has a very flexible clocking system that run run the CPU at almost any speed upto 16MHz, the devices have certain speeds calibrated into them at the factory, i.e. the MSP430G2553 has 1MHz, 8MHz and 16MHz if I remember correctly. We are saying run at a known speed of 1MHz. If you wanted 16MHz use CALBC1_16MHZ and CALDCO_16MHZ. If you did this though you would have to alter your __delay_cycles line to __delay_cycles(8000000) for a 1/2 second delay. 3) Changing your for(;; ;-) to while(1).. This one is personal taste. Each says "Loop forever". Personally I think the while(1) is easier to understand but many many other people prefer the for(; ;-) method so you will see both in examples round the net. I meant this as a quick response and got carried away as usual.. I hope it helped. Dan P.S. One further thing to add. Putting the CPU into a known good state is a good practice to get into. For example when you start using interrupts each interrupt has an interrupt flag that says this interrupt has occured. Good practice says to always clear this flag before enabling the interrupt. It is a good habit to get into and saves much hair pulling, keyboard bashing later on (I know.. I learned this one the hard way)
  7. You could try running the test code I wrote a while back. It runs the ADC and DCO at a variety of speeds and ADC settings. It then uses the UART to tell you how many samples it managed and tells you what the highest and lowest readings were. Anyway the link is http://forum.43oh.com/topic/892-adc10-speed-tests-using-hardware-uart/ You can see my test readings. You could see if yours are of a similar stability. Hope this helps. Dan
  8. Grats cube. Have fun and don't forget to share your findings. Dan Sent from my GT-I8160 using Tapatalk 2
  9. DanAndDusty


    As far as I'm aware there is not much you can do about that. Hibernate mode basically removes power to the main core of the CPU and so the debugger loses track of it. I'd love to be proven wrong and have someone chip in with "you just have to do xyz" cause I have had issues with the same thing. Depending on why you want to hibernate though you may find sleep or deep sleep mode sufficient (at least for debugging purposes) Dan
  10. I don't use energia so I may be way off track here but the chip is the lm4f120H5qr (note the H in the part number) the include file you are looking for doesn't have that h. This may give you a clue as to what to look for. As I say though I don't use energy's and have never installed it so that may be what the h file should be called. Dan
  11. I don't use energia so I'm not too familiar with its ins and outs. But what I did notice is in your void setup() routine you loop but inside it you use pinmode(Sen......) not pinmode(Sen.........) So you could easily be reading floating pins as this is where you set pullups. Sent from my GT-I8160 using Tapatalk 2
  12. You can do it with 2 female to female jumper wires. I soldered wires across 2 lots of 2 female headers making a 2x2 block with wires soldered across. This is neat and unobtrusive. The only non solder job I can think of though is 2 crossed f2f jumper wires. Have a great Christmas. Dan Sent from my GT-I8160 using Tapatalk 2
  13. Yup. That's the one I was thinking of. Thanks for doing the link hunting. Sent from my GT-I8160 using Tapatalk 2
  14. Just a quick thought. You *can* run the 2231s at 16mhz. There is a forum thread about calibrating the missing values (on phone ATM so can't search easily). To use them you also need to edit the header file for the 2231 which I seem to remember is also in the forum thread. Sounds like a fun booster. Can't comment much more though as I haven't successfully played with i2c. Good luck. Dan Sent from my GT-I8160 using Tapatalk 2
  15. I have CVS (5.2) debugging nicely on Linux. Not at the pc ATM so going from memory. Start CVS from the command line and you get more debugging messages. Go to program the device then swap back to the shell window. For me there were 2 missing shared libs. A ftdi one (available from their website) and something like libusb-1.so. these both had to be 32 bit on my 64 but system. After putting these in place the next error I had was regarding permissions so I had to create a udev rule. Once I had done all this it all works great. I can program, single step and use breakpoints. The only issue I have is that if the launchpad is disconnected while debugging then ccs has a tendency to crash. Other than that its a dream and sooo much faster/smoother than I had under a vm. Hope this helps. Dan P.s. forgot to mention that at I also had to create an XML file for the connection. Can't remember much on that though as basically cut and pasted from the web sonewhere
  • Create New...