Jump to content

Leaderboard


Popular Content

Showing content with the highest reputation on 09/20/2012 in all areas

  1. 1 point
    So I finally tried out the replacement cdc_acm module from the e2e forums. I'm using the file 7028.msp430_patch.zip mentioned in this post http://e2e.ti.com/support/low_power_rf/f/156/p/53610/697952.aspx#697952. I'm using Ubuntu 11.04 with a 2.6.38 kernel. Installing this patch solved my problems with /dev/ttyACM0 and linux. I tried the unmodified Energia ASCII Table example. The code in that sample doesn't wait before sending data, however with this patched module it just works. With the old cdc-acm my whole UI would freeze for multiple 10s of seconds. There are some things that are different from an Arduino. The main one being the launchpad doesn't reset the msp430g2553 chip when it receives a DTR line signal down the /dev/ttyACM0. What does that mean? Opening and closing the serial console doesn't restart the msp430. When you open the window you must press the reset button on the launchpad to have it restart like an Arduino would. However, with this patch, the UI doesn't lock up any more or stall when you first run it. You also don't have to be worried about printing data when the serial console isn't open. Two other people have also tried this patch with similar good results. One system was Ubuntu 10.04/2.6.something kernel and arch linux with a 3.something kernel. I think this goes a long way to addressing stability for the linux version of Energia. Yay Gerald Stanje the kernel hacker author. +1 -rick
  2. 1 point
    Nytblade

    COM port tunneling?

    Here is how I program remotely: 1) attach my launchpad to my home unix box 2) point a webcam at the launchpad board so I can watch the LEDs (the webcam publishes to a webserver running on the local machine). this can be helpful for debugging if you want to make the LEDs flash when something happens. 2) ssh into the home PC from the remote location 3) use screen/tmux to have multiple "windows" open 4) use mspdebug/gcc/gdb/vim to develop code on my home PC 5) use minicom or screen to access the home PC's serial ports I check the code into a private Subversion repo so that when I'm at home, I can just check it out on my laptop and use CCS instead (sometimes debugging is easier with a GUI). I also keep all my datasheet PDFs in subversion so I can easily download them all at once to a remote PC. I only use one SSH connection and use port forwarding to get to the SVN port (some places like public Wifis block SVN). Now I just need to build a robotic gripper arm to do soldering for me and I will never have to be at home
  3. 1 point
    oPossum

    Printing to the CCS debugger console

    The CCS RTS (run time support library) supports simple device drivers and streams. The printf() function uses this driver/stream system to print to the debugger console window. There isn't enough memory in any of the G series devices to use printf() due in part to the memory requirements of the RTS stream buffers. I created a very basic printf() that makes direct calls to user provided putc() and puts() functions. This reduces the memory use substantially. Using this simple printf() with the CCS debugger console can be done with this code.... unsigned char _CIOBUF_[12 + 32]; // This *must* be global and named _CIOBUF_ // 12 bytes needed for header and null terminator // void putc(char c) // --- Send char to debugger using CIO { // static char * p = (char *)&_CIOBUF_[11]; // Pointer to string buffer // if(c) *p++ = c; // Append any non-null char to buffer // Write to host when buffer is full or char is null if((p >= (char *)&_CIOBUF_[sizeof(_CIOBUF_) - 1]) || (c == 0)) { *p = 0; // Null terminate string const unsigned l = p - (char *)&_CIOBUF_[10];// String lengh including null _CIOBUF_[0] = _CIOBUF_[5] = l & 0xFF; // Data and string length LSB _CIOBUF_[1] = _CIOBUF_[6] = l >> 8; // Data and string length MSB _CIOBUF_[2] = 0xF3; // Write command _CIOBUF_[3] = 1; _CIOBUF_[4] = 0; // stdout stream __asm(" .global C$$IO$$"); // CIO breakpoint __asm("C$$IO$$:nop"); // p = (char *)&_CIOBUF_[11]; // Reset string buffer pointer } // } void puts(char *s) { while (*s) putc(*s++); } // Send string to debugger inline void cio_flush(void) { cio_putc(0); } // Flush the CIO write buffer This works by filling a buffer with information that the debugger will read and interpret. The debugger sets a breakpoint at symbol C$$IO$$ and reads the buffer when the breakpoint is hit. Unfortunately there is quite a bit of overhead with this method so applications are limited. Increasing the buffer size (_CIOBUF_) will help performance by transferring more data with each breakpoint invocation.
×
×
  • Create New...