• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 81 subscribers
  • Views 3587 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

I want to read a line of input from the Code Composer Studio console using an MSP430.

Mark Palaima
Prodigy 30 points
Other Parts Discussed in Thread: MSP430F5171

I am able to get printf(…) working to the CCS console by doing the following:

    Proj properties -> Debug -> Enabled CIO function use    
    Proj properties -> Build -> Linker - Basic Options (set heap stack size to 500)  

Given the interaction of stdout, CCS w/debugger and the FET works for printf(…), I am encouraged that reading from stdin is also possible.  

My environment     MCU: MSP430F5171     IDE: Code Composer Studio 5.5.0.00077  

The code fragment is as follows:
   static char response[32] ;     ...    
   fgets(response, 32, stdin) ;      
   // Code above immediately falls through to here and does not block for my input from the console  

The compiler/linker have no warnings/errors.  The code fragments I am using work in standard C/C++ environments with Eclipse IDE.  

I am new to firmware but have been able to get some custom board bring up working, deal with I2C, use interrupts, timers, etc… so I have marginal experience but enough to use the basic tools and MCU.  Any help is great appreciated.

  • 0
    Guru 227245 points

    Being able to compile doesn’t mean the program will run as expected. :)
    While fgets can be used, it won’t work as you think. There is no OS on the MSP, and therefore no stdout or stdin. For printf, the debugger places a breakpoint in the putchar function, fetching outgoing characters. And likely does the same on getchar and therefore gets. However, the f… functions are probably just stubs unless you provide low-level I/O functions with the required flesh. (note that you're not using fprintf for output.)

  • 0 in reply to Jens-Michael Gross
    Prodigy 30 points

    Thanks for the quick feedback.  I understand the MSP430 does not have a OS or RTOS and that a clean compile/link is not a guarantee of proper execution.  The clean compile/link was for clarity that I did not have any linkage errors etc... for libs I might need or be missing etc...

    My guess on having to increase the stack/heap sizes was correct in that the printf(...) was just failing with the lower limits.  When increased, the underlying allocs had enough breathing room to now to succeed.  My gut tells me this is a similar problem with fgets(...) and I will debug through more code to find out what's happening.

    I understand that stdio aspects on a MSP430 is a stretch for such a constrained device but I only need printf(...) and fgets(...) working to achieve my goal.  Don't people have similar needs over a UART?  Couldn't such an approach be used to interact with the CSS debugger console?

    I am using the printf(...) and fgets(...) to enable a simple command line interpreter from the CCS debugger for dynamically reading/writing to I2C slaves, triggering interrupts, starting timers, doing resets to other chips on my board etc...  This cuts down my code changes/restarts and lets me test much faster.

    If someone has actually solved my fgets(...) question with the required code it would be useful to be posted.  

    It seems somewhat strange to just provide all these stubs and require people to figure it out per MSP430 family incarnation.  Given that CCS, MSP430xxx and FET430UIF are all TI, I was hoping the general libs would have some solutions included and possibly ones of lighter weight or limited versions for the smaller 430's working with TI's own toolchain.

    Will post back my findings and thank you for my first response in this forum!

        MrP

  • 0 in reply to Mark Palaima
    Prodigy 30 points

    Suspicion on increasing the heap/stack would help was confirmed.

    On another forum my question was answered and the solution was to increase the heap to > 576 to enable a pair of 256 byte buffers + some control data to be successfully allocated inside fgets.c

    My command line interpreter is working fine now and fgets(...) blocks till I hit enter from the console in CCS.

     

  • 0 in reply to Jens-Michael Gross
    Guru 25210 points

    Jens-Michael Gross said:
    There is no OS on the MSP

    By that I could also say there's also no OS on the Intel Core i5 processor in my computer either.

    The MSP devices I use here do run an OS. It's just not built in from TI.

    </nitpicking>

  • 0 in reply to Mark Palaima
    Guru 227245 points

    Okay, requiring 512 bytes of buffer is of course a huge requirement. And In didn’t remember that the heap size is limited by default (on MSPGCC, it is by default all that is remaining between top of stack and the data area)

    Why didn’t you try using gets instead of fgets? This should work as well and wouldn’t need buffers and administrative data for the stream handling. As I said, you’re already using printf instead of fprintf.

    Brian, your're right, but then, nobody who is writing an applicaiton for an Intel processor would expect that he has to write an OS and a BIOS too. Or compile and link it into the application. Regarding this, the MSP is 'empties' than a good old C64 (and people are usually less skilled in the low-level stuff these days)
    So you can't compare a naked MSP (the normal case) with a naked x86 (the very unusual case).

  • 0 in reply to Mark Palaima
    Intellectual 800 points

    Thanks.. I was facing the same problem on AM335x SK board.  I just bumped up the heap.  You saved me another headache.

**Attention** This is a public forum