Jump to content
Sign in to follow this  
OppaErich

[solved] delay loop doesn't get called

Recommended Posts

your delay code is probably getting optimized out. You might want to try using __delay_cycles() instead. Or even better use a Timer to get more accurate results.

 

-rick

Try the above or try declaring tick as a volatile variable.

Share this post


Link to post
Share on other sites

Cheers guys. It was removed by the compiler. This came to my mind too but I didn't want to believe it. I mean, delay loops do make sense sometimes...seems compilers aren't very good in mind reading. :D

 

Not that it would work already but I didn't expect that, the code was quickly harvested from Maxim application notes.

 

Now we're talking

Share this post


Link to post
Share on other sites

It didn't take long. :( Updated code in first post.

 

After some experimenting with the delay values I get something into temperature. So I added decimal and digit to the code to get something readable by me, I want to verify that the temperature values make sense.

 

CCSv4 refused to show me the values of digit and decimal (unknown identifier), so I wanted to try with eclipse but now I get

Building target: ds18b20.elf
Invoking: MSP430 Linker
/home/oppa/bin/eclipse/msp430-toolchain/linux-i386/bin/msp430-gcc-wrapper -mmcu=msp430g2231 -o "ds18b20.elf"  ./main.o 
/home/oppa/bin/eclipse/msp430-toolchain/linux-i386/bin/../lib/gcc/msp430/4.6.0/../../../../msp430/bin/ld: ds18b20.elf section `.text' will not fit in region `rom'
/home/oppa/bin/eclipse/msp430-toolchain/linux-i386/bin/../lib/gcc/msp430/4.6.0/../../../../msp430/bin/ld: section .vectors loaded at [0000ffe0,0000ffff] overlaps section .text loaded at [0000f800,000102ab]
/home/oppa/bin/eclipse/msp430-toolchain/linux-i386/bin/../lib/gcc/msp430/4.6.0/../../../../msp430/bin/ld: region `rom' overflowed by 980 bytes
collect2: ld returned 1 exit status 

 

Is this really too much already for the G2231 and why did CCS not complain ?

Share this post


Link to post
Share on other sites
Is this really too much already for the G2231 and why did CCS not complain ?

 

There's 2016 bytes of ROM on the G2231, and unless told to perform optimization mspgcc generates very simple code with a lot of redundant moves. Use -Os, or at least -O:

linux[9]$ msp430-gcc -mmcu=msp430g2231 -Os x.c
linux[10]$ msp430-size a.out 
  text    data     bss     dec     hex filename
   642       2      20     664     298 a.out
linux[11]$ msp430-gcc -mmcu=msp430g2231 -O x.c
linux[12]$ msp430-size a.out 
  text    data     bss     dec     hex filename
   758       2      20     780     30c a.out

(Your sizes may be somewhat different; I had an internal development version in my patch on this machine.)

Share this post


Link to post
Share on other sites

Thanks.

 

Then there's also debugging symbols. Is there a rule of thumb how much that makes, roughly ?

 

It was meant to support more than one DS18B20, so I need to store serial numbers, a detection routine and then some serial interface to 'get the word out'. A CRC routine wouldn't hurt either.

 

@BH: I've added it to the source file. I ran out of memory after that.

Share this post


Link to post
Share on other sites

Looks like Eclipse with the mspgcc plugin has problems. I've changed to a G2553 and it still says .text is too big (yes, I did change the target setting).

 

I've booted XP then and tried with CCSv4. It reported two hundred something byte for .text.

 

And I discoverd that OneWire didn't work with the 2553. I guess the DCO of that one runs faster than that of the 2231, I've been too lazy to hook up the scope. I think I have to stick to calibrated values.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×