Search the Community

Showing results for tags 'c++'.

More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • News
    • Announcements
    • Suggestions
    • New users say Hi!
  • Spotlight!
    • Sponsor Spotlight
    • Sponsor Giveaways
  • Energia
    • Energia - MSP
    • Energia - TivaC/CC3XXX
    • Energia - C2000
    • Energia Libraries
  • MSP Technical Forums
    • General
    • Compilers and IDEs
    • Development Kits
    • Programmers and Debuggers
    • Code vault
    • Projects
    • Booster Packs
    • Energia
  • Tiva-C, Hercules, CCXXXX ARM Technical Forums
    • General
    • SensorTag
    • Tiva-C, Hercules, CC3XXX Launchpad Booster Packs
    • Code Vault
    • Projects
    • Compilers and IDEs
    • Development Kits and Custom Boards
  • Beagle ARM Cortex A8 Technical Forums
    • General
    • Code Snippets and Scripts
    • Cases, Capes and Plugin Boards
    • Projects
  • General Electronics Forum
    • General Electronics
    • Other Microcontrollers
  • Connect
    • Embedded Systems/Test Equipment Deals
    • Buy, Trade and Sell
    • The 43oh Store
    • Community Projects
    • Fireside Chat
  • C2000 Technical Forums
    • General
    • Development Kits
    • Code Vault
    • Projects
    • BoosterPacks


There are no results to display.

Found 8 results

  1. Hi, I needed a way to see how much of my C++ stack was being consumed in my MSP application - the traditional way is to "poison" the stack with a known pattern, and then to see how much of it gets burnt away. So I wrote the following - hope folk find it useful: The following code allows you to simply do this and to check at any point how much of the pre-allocated stack was consumed during peak usage, i.e. how close your app got to the bottom of the stack, or indeed, whether it over-ran. The TI CCS documentation is completely wrong in the names it gives for the global symbols that define the size and start of the stack - needs to be updated, Stick this code (or similar) wherever you want to report on/check stack usage <smallest number of byes left free on the stack since initialisation>/<configured size of the stack>. #if defined(STACK_CHECK) std::printf( "Stack: %d/%d\n", stackMinFreeCount(), stackMaxSize() ); #endif and then, in your main code you need to poison the stack as early as possible and then define the reporting routines: // Define STACK_CHECK to include stack usage diagnostics #define STACK_CHECK #if defined(STACK_CHECK) #define STACK_INIT 0xBEEF // Pattern to use to initially poison the stack extern uint16_t _stack; // Start of stack (low address) uint16_t stackMinFreeCount(void); uint16_t stackMaxSize(void); #endif #if defined(__cplusplus) extern "C" { #endif #if defined(__TI_COMPILER_VERSION__) || \ defined(__GNUC__) int _system_pre_init( void ) #elif defined(__IAR_SYSTEMS_ICC__) int __low_level_init( void ) #endif { //... stuff... #if defined(STACK_CHECK) // // Poison the stack, word by word, with a defined pattern // // Note that _system_pre_init is the earliest that we can // do this and that it may not be possible in TI-RTOS // // When we call the __get_SP_register intrinsic (same on IAR & CCS), it will return the address // of the RET address for the caller of this routine. Make sure that we don't trash it!! // register uint16_t *stack = &_stack; // Address of lowest address in .stack section register uint16_t *stack_top = reinterpret_cast<uint16_t *>(__get_SP_register()); do { *stack++ = STACK_INIT; // Poison stack addresses } while (stack < stack_top); // Stop before top of stack to leave RET address #endif return 1; } #if defined(__cplusplus) } #endif #if defined(STACK_CHECK) /** * Check how deep the stack usage has been * * \return \c uint16_t Minimum number of bytes to bottom of stack */ extern uint16_t __STACK_END; // End of data extern uint16_t __STACK_SIZE; // Linker-set size of stack uint16_t stackMinFreeCount(void) { const uint16_t *stack = &_stack; uint16_t freeCount = 0; while (*stack == STACK_INIT && stack++ <= &__STACK_END) { freeCount++; } return freeCount << 1; } /** * Return size of C++ stack * * Set by the linker --stack_size option * * \return \c uint16_t Configued maximum size of the stack in bytes */ uint16_t stackMaxSize(void) { return static_cast<uint16_t>( _symval(&__STACK_SIZE) ); } #endif int main(void) { ... stuff #if defined(STACK_CHECK) std::printf( "Stack: %d/%d\n", stackMinFreeCount(), stackMaxSize() ); #endif ...stuff }
  2. I've been lurking here for awhile... I am a noob to Energia, but have more than a little experience designing and writing interrupt-driven C code for msp430f2013, as well as some time spent with the value line devices. I am working on a personal project with the F5529, connecting to a GPS (the adafruit ultimate BOB), an Iridium 9602 Sat-Comm device (sparkfun RockBlock), and a cap touch TFT LCD (have worked with both the adafruit 2.8" BOB and a version of same). The project is a DIY short-burst-data comm device to let my wife know I've not been eaten by a bear on an upcoming 250 mile hike on the John Muir Trail. Oh, and I'm aware that there are commercial devices available ($600 - $1200 plus subscription fees). I chose the F5529, in part, for the dual hardware UARTs, one connected to the GPS @9600 and the other to the 9602 @19200. The LCD uses SPI for screen management and I2C for the cap-touch interface. While the system is up and running, the different devices will not be running concurrently. I had been thinking of a LPM3 timer interrupt-based system that would capture and communicate position data on an hourly basis during the day, and that I could put into LPM4 at night to conserve battery. The LCD merely provides a UI for mostly menu-driven messages and system-state options, but may include a free text option to send a special message, or read a message from my wife. In C, I have successfully connected to all three devices using both UARTs for the two async devices with both a F5529 launchpad, and also an MSP-FET430U80+F5529. I've been intrigued by Energia as a means to code my project a little more quickly with "trusted" libraries. But on closer inspection, I see that the basic construct for Energia is one focused on Arduino compatibility and not necessarily low power interrupt-driven designs. I've read several discussions on this board regarding using low power modes, and the potential for interfering with the Energia architecture, as well as possible workarounds. I've also looked at pabigot's class libraries, and they look like a solid alternative, but I'm not sure my C/C++ skills are really up to snuff to effectively use the work. I do have some questions regarding Serial, Serial1 and the backchannel UART, but I need to do some more experimenting so I can ask better questions, assuming I can't find my own solutions. TIA for any thoughts, suggestions, etc! Bob
  3. I'm attempting to parse a byte/char array that contains the following data cmd=led&color=red&state=on This data is made available to me in a callback function whose signature looks like this. void callback(char* topic, byte* payload, unsigned int length) { The payload parameter is the one that holds the data I'm interested in. I've tried various ways to parse this string and I've been unsuccessful (I mean besides shear brute force and tons of memory allocations). I eventually resorted with coding a test harness using Visual Studio and C/C++ and I get it where it works but then when I move it to Energia/Code Composer Studio it doesn't work. Also, I'm not sure if what I have is the right/best way to do this. Here is my C/C++ code that works in Visual Studio. Known issues 1. payload variable is declared as a char* while the actual payload parameter is a byte* so I'm not sure how to get past that. I'm guess I can cast the byte* to a char*? 2. I know the strtok function modifies the original. So I need to use something else. Not sure what #include "stdafx.h" #include <string.h> #include <stdio.h> enum Command { Led, Motor, Servo, Ligth }; enum LedColor { red, green, blue }; enum LedState { on, off }; typedef struct RemoteCommand { Command command; LedColor ledColor; LedState ledState; }; char* getValuePart(char* str); bool startsWith(const char *pre, const char *str); int main() { const char parameterDelimiter[2] = "&"; char payload[] = "cmd=led&color=red&state=off"; RemoteCommand remoteCommand; char *token = strtok(payload, parameterDelimiter); if (startsWith(token, "cmd")) { char* separator = strchr(token, '='); if (separator != NULL) { ++separator; } // Parse the LED Command if (strstr(token, "led") != NULL) { remoteCommand.command = Command::Led; // Parse the Color attribute token = strtok(NULL, parameterDelimiter); if (startsWith(token, "color")) { if (strstr(token, "red") != NULL) remoteCommand.ledColor = LedColor::red; else if (strstr(token, "green") != NULL) remoteCommand.ledColor = LedColor::green; else if (strstr(token, "blue") != NULL) remoteCommand.ledColor = LedColor::blue; } // Parse the State attribute token = strtok(NULL, parameterDelimiter); if (startsWith(token, "state")) { if (strstr(token, "on") != NULL) remoteCommand.ledState = LedState::on; else if (strstr(token, "off") != NULL) remoteCommand.ledState = LedState::off; } } } return(0); } char* getValuePart(char* str) { char* color = strchr(str, '='); if (color != NULL) { ++color; } return color; } bool startsWith(const char *str, const char *pre) { return strncmp(pre, str, strlen(pre)) == 0; } Any suggestions to improve this code (less memory allocation, more efficient etc.) are most welcome.
  4. I have Keil uVision version 4. I would like to configure it so that I can compile C++ code as well. I believe I can only compile C at the moment. Can anyone help with that? Thanks
  5. I have an issue when using the Capacitive Sensing Library from Arduino. I used the ver. 5 that allows non-AVR boards to use the library. My problem is when I complied it in Energia, I get these errors: /Users/apple/Documents/Energia/libraries/CapacitiveSensor/CapacitiveSensor.h:94:2: error: 'IO_REG_TYPE' does not name a type /Users/apple/Documents/Energia/libraries/CapacitiveSensor/CapacitiveSensor.h:95:11: error: 'IO_REG_TYPE' does not name a type /Users/apple/Documents/Energia/libraries/CapacitiveSensor/CapacitiveSensor.h:96:2: error: 'IO_REG_TYPE' does not name a type /Users/apple/Documents/Energia/libraries/CapacitiveSensor/CapacitiveSensor.h:97:11: error: 'IO_REG_TYPE' does not name a type I am not that strong in coding and I would like some assistance into how to solve this problem. Thanks. here is the h file where the error is coming from: #ifndef CapacitiveSensor_h #define CapacitiveSensor_h #if ARDUINO >= 100 #include "Arduino.h" #else #include "WProgram.h" #endif // Direct I/O through registers and bitmask (from OneWire library) #if defined(__AVR__) #define PIN_TO_BASEREG(pin) (portInputRegister(digitalPinToPort(pin))) #define PIN_TO_BITMASK(pin) (digitalPinToBitMask(pin)) #define IO_REG_TYPE uint8_t #define DIRECT_READ(base, mask) (((*(base)) & (mask)) ? 1 : 0) #define DIRECT_MODE_INPUT(base, mask) ((*((base)+1)) &= ~(mask), (*((base)+2)) &= ~(mask)) #define DIRECT_MODE_OUTPUT(base, mask) ((*((base)+1)) |= (mask)) #define DIRECT_WRITE_LOW(base, mask) ((*((base)+2)) &= ~(mask)) #define DIRECT_WRITE_HIGH(base, mask) ((*((base)+2)) |= (mask)) #elif defined(__MK20DX128__) || defined(__MK20DX256__) #define PIN_TO_BASEREG(pin) (portOutputRegister(pin)) #define PIN_TO_BITMASK(pin) (1) #define IO_REG_TYPE uint8_t #define IO_REG_ASM #define DIRECT_READ(base, mask) (*((base)+512)) #define DIRECT_MODE_INPUT(base, mask) (*((base)+640) = 0) #define DIRECT_MODE_OUTPUT(base, mask) (*((base)+640) = 1) #define DIRECT_WRITE_LOW(base, mask) (*((base)+256) = 1) #define DIRECT_WRITE_HIGH(base, mask) (*((base)+128) = 1) #elif defined(__SAM3X8E__) #define PIN_TO_BASEREG(pin) (&(digitalPinToPort(pin)->PIO_PER)) #define PIN_TO_BITMASK(pin) (digitalPinToBitMask(pin)) #define IO_REG_TYPE uint32_t #define IO_REG_ASM #define DIRECT_READ(base, mask) (((*((base)+15)) & (mask)) ? 1 : 0) #define DIRECT_MODE_INPUT(base, mask) ((*((base)+5)) = (mask)) #define DIRECT_MODE_OUTPUT(base, mask) ((*((base)+4)) = (mask)) #define DIRECT_WRITE_LOW(base, mask) ((*((base)+13)) = (mask)) #define DIRECT_WRITE_HIGH(base, mask) ((*((base)+12)) = (mask)) #elif defined(__PIC32MX__) #define PIN_TO_BASEREG(pin) (portModeRegister(digitalPinToPort(pin))) #define PIN_TO_BITMASK(pin) (digitalPinToBitMask(pin)) #define IO_REG_TYPE uint32_t #define IO_REG_ASM #define DIRECT_READ(base, mask) (((*(base+4)) & (mask)) ? 1 : 0) //PORTX + 0x10 #define DIRECT_MODE_INPUT(base, mask) ((*(base+2)) = (mask)) //TRISXSET + 0x08 #define DIRECT_MODE_OUTPUT(base, mask) ((*(base+1)) = (mask)) //TRISXCLR + 0x04 #define DIRECT_WRITE_LOW(base, mask) ((*(base+8+1)) = (mask)) //LATXCLR + 0x24 #define DIRECT_WRITE_HIGH(base, mask) ((*(base+8+2)) = (mask)) //LATXSET + 0x28 #endif // some 3.3V chips with 5V tolerant pins need this workaround // #if defined(__MK20DX256__) #define FIVE_VOLT_TOLERANCE_WORKAROUND #endif // library interface description class CapacitiveSensor { // user-accessible "public" interface public: // methods CapacitiveSensor(uint8_t sendPin, uint8_t receivePin); long capacitiveSensorRaw(uint8_t samples); long capacitiveSensor(uint8_t samples); void set_CS_Timeout_Millis(unsigned long timeout_millis); void reset_CS_AutoCal(); void set_CS_AutocaL_Millis(unsigned long autoCal_millis); // library-accessible "private" interface private: // variables int error; unsigned long leastTotal; unsigned int loopTimingFactor; unsigned long CS_Timeout_Millis; unsigned long CS_AutocaL_Millis; unsigned long lastCal; unsigned long total; IO_REG_TYPE sBit; // send pin's ports and bitmask volatile IO_REG_TYPE *sReg; IO_REG_TYPE rBit; // receive pin's ports and bitmask volatile IO_REG_TYPE *rReg; // methods int SenseOneCycle(void); }; #endif
  6. Just wanted to share a project that I got compiling last night (doesn't necessarily work yet). If anyone is curious about it, it's located here.
  7. I never tried this and I could easilly check this for myself. But out of curiosity, I wonder if it is possible to code for the MSP430 in C++. In particular I was thinking of mspgcc which is freely available. Has anyone tried this already? Thanks. -- to
  8. Yet another software only serial class implementation? What makes this one different? C++ template based with asm routines to implement read and write. Works with any pin and port combination. You can mix and match, put read on P2.0 and write on P1.2. Small size even with Energia. Multiple instances allowed. Each instance uses about 12 bytes so you are only limited by the number of pins and memory on your chip. Big plus, doesn't use the timer. Read on if this piques your interest. This code implements a C++ template based software only blocking serial UART class. It doesn't use the timer peripheral so it can be used with other code that might want to monopolize the timer(s). The read/write routines are based on oPossum's CCS msp430 asm based cycle counting serial routines. They have been generalized for use with Energia, C++ templates, msp430-gas abi asm, modified to support any port and pin combination, and will allow for multiple serial instances. The code does use some instance data (~12 bytes) but you can have multiple sw_serial_t class instances. You might find this useful if you have have to interact with more than one serial device. This isn't a library so much as a header file you include in your project. The code weighs in at about 1200 bytes for a typical ASCII table print. A serial.print("Hello World\n") is only about 560 bytes. Useful things can even be done on the MSP430G2231 chip using this code. I've successfully tested output to 230400 baud running the DCO clock at 16MHz. You won't be able to achieve that baud rate running at 1MHz. Note: I did calibrate my DCO clock to be to 16.00MHz before trying to run that fast. I've not stressed the input side so I can't say what the limits are for input. Needless to say, it will all depend on the input and how you attempt to process the input data. You might want to snag a couple of those $3 pl2303x usb modules from ebay. That is what I used to test at high speed. The sw_serial_t template class inherits from the Stream base class. That means that all the normal print() methods are available for use as you would do with any other Serial class implementation. In addition, I've included the Streaming class from This allows C++-style output with the "<<" operator. See the example '.ino' files for information on how to actually instance the sw_serial_t template. Some caveats: 1.) This code uses cycle counting. That means when you use the write() or read() methods, they disable the watchdog timer. Disabling the watchdog in Energia means the millis() count is going to be wrong. I guess an improvement would be to update the millis counter based on the baud rate but I haven't done that. You have been warned! 2.) This code implements blocking routines. If you do a read() it will block until a character arrives. If you do a write() it will block until the bits have been shifted out. I take care of disabling the watchdog timer. However, if you have timer interrupt routines they will break this code. You will have to make sure you disable the timer interrupts while doing serial IO or pick a time when the timer code isn't running. 3.) This code doesn't use a ring buffer. So, expect it to to drop characters if you receive a long stream of characters and you try to do too much in between the read() calls. If you need to do something with a stream of characters, receive each byte and put it in your own buffer then process the buffer when you detect a new line. Some simple solutions to dealing with blocking reads: a.) use a slower host BAUD rate. b.) add extra stop bits from the host side to give yourself more time between received bytes. c.) preface the stream of bytes with a length so your firmware will know how many bytes to receive before it tries to process them. 4.) The more features of the Print class you use the larger your code will grow. If you really only want multiple serial instances then just use the read() and write() methods for the smallest code. Avoid the print() methods and you will acheive the smallest implementation. This code is implemented as templates and doesn't use the Arduino style pin number table runtime lookups. Pin information must be available at compile time so the asm routines can do the right thing. However, using templates reduces the size of this code and makes it more flexible. Look at the ssgpio.h for more information about the pin configuration. It is only setup for P1 and P2. I'm assuming people who want to use this are probably going to use it on the G series DIP chips. You will have to add entries for anything other than that. -rick hosted on github