Jump to content


  • Content Count

  • Joined

  • Last visited

About Shiv

  • Rank

Contact Methods

  • Website URL

Profile Information

  • Interests
  1. @roadrunner84, thanks for this struct returning sample. I understand all of the issues you've cited in this approach. I certainly feel that the original is the way to go since it seems "normal" in the C world. I'd rather not mix paradigms and have yet one more ball up in the air that I have to keep track of. I also appreciate the explanations and suggestions in your previous post.
  2. @roadrunner84, this is good stuff. I appreciate everyone's participation here tremendously! To be honest, it takes me quite a while to wrap my head around all of the code presented here. I've tried all of the code presented here and they all would work (obviously) and within each of the answers there are nuggets or artful pointer manipulations that have taught me how to handle other things that I've been struggling/confused with. At the end of the day, (the way I see it) string/char manipulation/parsing is a big component of code that most noobs are going to have to learn/master so I'm confident this thread will help others who struggle with C/C++. I have a general (best practice) kind of question. In the world I come from (Delphi, C# etc.) even though we have pointers, we don't really know them to be pointers and we also don't use them like I see being done here. So when a method needs to return multiple parameters, we favor defining a struct or class and return it, over using the input parameters as "out" parameters like I see here. Of course in C/C++ do as the C/C++ folks do! So my questions are: 1. Is this a best practice in general C/C++ programming or more of an embedded system area of practice? 2. When I'm trying to digest these functions I feel like I'm having to juggle multiple balls and as I go deeper into the function more balls are being added. In my Delphi/C# code I don't feel like that at all . Do you do the same (albeit way more naturally)? 3. What is a good book for me to revise/learn and get a good grasp of pointer manipulation? I remember starting out (eons ago) teaching myself C with Kernighan and Ritchie's book. I know I'm not suddenly going to morph into a hardcore C/C++ programmer and do tricks like I see here overnight
  3. @abecedarian, thank you for confirming the issue and well as logging the bug report. That was going to be my next question/post on this thread. Yes, you're correct that the pin doesn't go high from low.
  4. @Fmilburn and @abecedarian, My apologies for not providing code that reproduces. Essentially the code I eventually wrote to confirm my findings is similar to what @Fmilburn posted. I tried this code as well and I see the behavior that led me to start this post. That is the red led comes on for split second and goes off (really fast so if you're not concentrating on it you'll never notice it). I'm using the MSP432 Launchpad with the CC3100 booster pack. I even tried with the booster pack removed to confirm that the booster pack was not forcing this behavior. The Serial output is "1" as expected (each time I upload or reset the board). If I don't read the state of the pin the LED remains On as expected. Just now, I even tried with the same code but with an external LED connected to pin 5 (and changed code to suit), same behavior.
  5. So let's say I'm using the RED_LED here. pinMode(RED_LED, OUTPUT) . . . . . digitalWrite(RED_LED, HIGH); . . . int state = digitalRead(RED_LED); The value of the "state" variable will be 1 or HIGH, however, the RED_LED turns off when this call is made. Am I missing something?
  6. @spirilis and @Clavier, thank you so much for all of your ideas, code and suggestions! Really appreciate it. It will take me time to digest all of this, try out your suggestions etc. All this is a lot of help, so thank you both. ?Yes the original "payload" parameter should not be modified. I believe the socket reuses this buffer at the time publishing. It's not multi-threaded but I'd rather be working/manipulating my own copy. ?Ok, lots to do now! I'll be back.
  7. Have you looked at/tried de-bouncing using an RC network? If you're looking to implement this only in software, try, increasing the de bounce period (debounceDelay) to around 30-50 milliseconds.
  8. @yyrkoon, Thanks for your reply. Yes, the only reason I brought up MQTT is just in case someone else has done something similar for their needs. I guess simple and complex can be moved around depending on ones design and style. The protocol chosen here is intentional and is not up for discussion I'm afraid. Given that the protocol is what it is, any help on parsing would be apprecaited.
  9. 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.
  10. Hello, I'm not sure of what the update cadence for Energia is. However, I did find that the Wire.h library in Arduino has been updated since the Energia version. The Arduino's Wire.h library have a method - Wire.setClock() that allows setting the I2C bus speed. By default I believe it is 100KHz. On an Arduino Zero board I was able to bump it up to 3MHz (limited by the I2Cdevice I'm using) and the performance is incredible. However, since in Energia we don't have this method, the performance of the I2C device is extremely slow. So I'm wondering when/if there is a plan to upgrade the Wire.h library in Energia with the latest version. Also using the MSP432 I believe there is a hardware I2C option. Will this be faster? I used pins 9 & 10 on my MSP432 but the Wire.h library was included.
  11. Hello All, I've been visiting this site for a few days since embarking on using the MSP432 launch pad with the CC3100 booster pack. I'm really impressed with the energy and brain power of the folks here and hope to imbibe some of that smartness and in time help others that join here. I currently also use various Arduino and Netduino boards and having spent some time looking at the C/C++ source code I have come to realize (sadly) that my C/C++ skills (if one could call it that) are atrophied terribly. My interests lie in developing a bunch of "projects" using various MCUs and to eventually start working on some IoT products. I have a background in electronics and feel comfortable there (at least to the extent of the kinds of things I'd like to build). Most times, I struggle with wondering why I need to use an MCU (besides internet connectivity, configuration, parameterize) as most of what I do and would like to do is also easily done with just electronics. But I've been a software developer for many years with most recent experience in C#/.NET, so I can see where I can/should use an MCU as well. The MSP432 is really interesting because of the multi-tasking and RTOS. But I figure it will be a while before I really get into these areas. Energia of course makes these launch pads accessible to a lot of folks like me (whose C/C++ has corroded over the years). So I look forward to interacting with folks here.
  • Create New...