Jump to content
43oh

DanAndDusty

Members
  • Content Count

    134
  • Joined

  • Last visited

  • Days Won

    1

Posts posted by DanAndDusty

  1. If anyone in Europe want's one then shout and I can mail it directly from the UK.

    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. 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 :smile:) 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)

  3. 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

  4. 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

  5. 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

  6. 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

     

     

  7. 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

     

     

  8. 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

     

     

  9. 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

  10. That would be cool. I have a ton of stuff from the 1st mindstorms. Top of my head there must be 3 or 4 add on kits plus main kit. Not touched it for years but I seem to remember that getting the ir tower (old serial one not the USB) working was tons of hassle.

     

    So for me^h^h my son a mindstorms booster would be awesome.

     

    Sent from my GT-I8160 using Tapatalk 2

  11. Hi,

     

    I have a hard time understand the pins assignment on the launch pad (first time user), Can you help?

     

    For example:

     

     

    #define RS GPIO_PIN_0 Is this conect to PD0 ????

    #define E GPIO_PIN_1 Is this conect to PD1 ????

    #define D4 GPIO_PIN_4 ??

    #define D5 GPIO_PIN_5 ??

    #define D6 GPIO_PIN_6 ??

    #define D7 GPIO_PIN_7 ??

     

    Thanks for your help.

     

    I don't have one of these LCDs but at the top he says Full port B used.. So I would read those as GPIO_PIN_1 is PB1 and so on..

  12. Ouch Larsie, that sucks...

     

    Mine shipped a few days early and arrived Friday (the original shipping date).. I opened it this morning (gotta love it when Wife goes to her mums for the day:) )..

     

    Sofar all I have managed to do is get the toolchains working under linux.

    CCS5.2, 32Bit libusb-1 and libftd2xx.so libraries installed, an XML connection file and a udev rule was all it eventually took though It took me longer to do than reading that would imply :)

     

    Project0 is currently flashing red and blue at me as I type. Time for a coffee and some serious reading I think :)

     

    Cheers,

     

    Dan

  13. Ive installed CCS5 under linux and compile them from in there.. To get the code to the board I use MSPDEBUG from the command line. If I need to debug then I fire up a VM with XP on it and debug from there.

     

    The C2000 Launchpad works a dream under linux with full debugging support so as support for the 430 launchpad under linux is planned Im looking forwards to that. I have no idea on time-scales though so anyone any better ideas?

     

    Dan

×
×
  • Create New...