Jump to content
Forum sending old emails Read more... ×

JRDavisUF

Members
  • Content Count

    39
  • Joined

  • Last visited

  • Days Won

    5

JRDavisUF last won the day on July 23 2017

JRDavisUF had the most liked content!

About JRDavisUF

  • Rank
    Advanced Member

Recent Profile Visitors

509 profile views
  1. JRDavisUF

    Implications of changing compiler version

    I just stumbled across one big difference when I use the newer compiler...which, as a nice side note, seems to explain my ctime issue issue as well. When I use the newer compiler, time_t now gets defined as a 64bit variable (versus the 32bit one I was getting using the older compiler), which I believe is why the ctime function once again works correctly(see my other changelist-related post). Unfortunately, with ctime a 64 bit long long, Serial.print() no longer works, because output of a 64bit number isn't supported ... but one problem at a time...
  2. JRDavisUF

    Energia/board upgrade changelist?

    OK, I think I know the problem now. It looks like time_t variable expected by ctime has changed from a 32 bit number to a 64 bit one (long long). (see my related compiler change post) In time.h ($USER\AppData\Local\Energia15\packages\energia\tools\arm-none-eabi-gcc\6.3.1-20170620\arm-none-eabi\include) If I make the following change: char *_EXFUN(ctime, (const time_t *_time)); to char *_EXFUN(ctime, (const long long *_time)); The the ctime function works correctly.
  3. JRDavisUF

    Energia/board upgrade changelist?

    FWIW, I'm able to get ctime to work correctly if I switch from the default GNU 6.3.1 compiler supplied with energia to the GNU 7.2.1 compiler supplied with CCS8...not sure the implications of this change...so I started a new topic to talk about that
  4. [MSP432][Windows10][Energia 21][Board file 5.23.1] Recently I've been struggling with a run-time error in a very simple program (converting time=0 to 1/1/1970 fails using ctime...granted it's not really an Energia thing, but it's available for use in my CCS builds of energia projects) using the latest code composer, energia and board file (BTW, I don't have this problem with the previous board file) for my msp432. I've figured out a way to "fix' my problem, but it's unclear to me what the implications of this change might be. By default, when I create a new project in CCS, the project is setup to use the GNU v6.3.1 compiler by default. If I use this compiler, my program compiles, but it's operation fails. In looking into the properties of the project, I notice that I have 5 (2 TI and 3 GNU - 1 GNU older than the default and 1 GNU newer) compiler choices in the tool chain. As such, I started changing the compiler to see what would happen with my non-functioning code. First, I started with the TI compilers. If I select either of them, I get a notice about the need for "manual" intervention in the compiler config. As such, I gave up on those. I then selected the oldest version of the GNU compiler (4.8.4). Switching to this version and my compilation fails. Once again, I have up on that one. As a last attempt, I changed to the newer version of the GNU compiler (7.2.1) and lo-and-behold, not only does my problem compile, but ctime now works correctly. Newer things are always better, right? The default (non-working one) and older (non-compiling) versions of the GNU compiler appear to be shipped with Energia while the newer (working) one appears to be shipped with CCSv8. As such, although I've fixed my problem, I'm wondering if switching is just going to lead to other problems as I'm assuming energia was vetted with the default 6.3.1 compiler. Anyone have positive/negative experiences with changing the compiler tool chain? As my program runs with the previous board file (but using the latest Energia 21 otherwise), might I just be better to switch to the older board file (and wait for a board file/compiler update with energia) but leave the compiler as the default 6.3.1 version? jrd
  5. JRDavisUF

    Energia/board upgrade changelist?

    So I've narrowed my code down to what is below. Using the latest Windows 10 Code Composer, the code works using Energia 21 / 5.6.3 but not with Energia 21/ 5.23.1...It kind of feels like a heap/stack size issue. Maybe the newer board file needs more memory for something...Any code composer experts out there? There used to be some obvious places to change such things...but I don't see them any more... #include<time.h> void setup() { // put your setup code here, to run once: Serial.begin(38400); // Thu Jan 1 00:00:00 1970 time_t time1=0; Serial.println(ctime(&time1)); } void loop() { } (I'll also note that if the time_t and Serial.println lines are moved to the loop, the code runs fine.)
  6. JRDavisUF

    Energia/board upgrade changelist?

    Downgraded Energia from 21 to 18 and the problem still exists. Downgraded the board file from 5.23.1 to 5.6.3 and problem goes away ...
  7. JRDavisUF

    Energia/board upgrade changelist?

    I don't really get it, but if I change my declaration of time1 and time2 in my example to include "static": static time_t time1, time2; Then time2 gives the correct answer at least... Thu Aug 1 14:43:24 -1920291 Fri Jul 31 20:41:48 2015
  8. JRDavisUF

    Energia/board upgrade changelist?

    Lots more digging and it looks there is a time_t related issue. While trying to debug the problem, I tried running this example: https://github.com/rei-vilo/DateTime_Library/blob/master/Examples/Date_String/Date_String.ino These particular lines; // Fri, 31 Jul 2015 20:41:48 GMT myEpochRTC = 1438375308; Serial.print("Using default local time = "); Serial.println(convertDateTime2String(myEpochRTC)); Output this: Using default local time = Sat Jan 6 19:29:16 -1905047 which is consistent with the problem I am seeing in my test code that outputs the incorrect dates: Fri Mar 5 12:50:20 -1920835 Wed Sep 8 05:11:40 -848351 //test code #include "time.h" #include "RTC_Library.h" void setup() { // put your setup code here, to run once: Serial.begin(38400); time_t time1, time2; String result1, result2; // Fri, 31 Jul 2015 20:41:48 GMT time1 = 1438375308; result1 = convertDateTime2String(time1); Serial.println(result1); // Fri, 31 Jul 2015 20:41:48 GMT time2 = 1438375308; result2 = (String)ctime(&time2); result2.trim(); Serial.println(result2); } void loop() { // put your main code here, to run repeatedly: }
  9. JRDavisUF

    Energia/board upgrade changelist?

    I'm using the MSP432 Launchpad (red). I2C seems to be working ok as I've got a oled display connected via the same I2C pins and that is working just fine. I've also tried swapping out the RTC module with an identical one and it's showing the same behavior, so it looks like some kind of software-related issue at this point. And FWIW, both the internal (on the msp itself) and external RTC (I2C) are showing the same behavior.
  10. I've a code I've been working on a while that has worked fine with an older version of the Energia and the board file. When I recently upgraded Energia to 21 and the MSP432 board to 5.23.1 a bunch of things broke. I was able to determine one set of problems was caused by the SPI Mode0/1 bug being corrected. That is, since spi mode0 and 1 were switched, I switched them in my code. When the bug got fixed everything spi-related broke until I switched the modes back (to what they should have been in the first place). My latest problem is that my usage of the RTC no longer works. Attempts to read/set the clock (internal and an external DS3231) are not working correctly. Setting the time to unix time 0, yields "Thu Apr 23 19:16:16 198054" Something funky with the year for sure. (as an aside, anyone have ideas on this problem?) So this led me down the path of trying to figure out what changes were made in the upgrades of Energia and the msp432 board file. However, I've not been able to find a good source of the changelist-type information relating to these two things. Can someone point me to this? I'm guess this might be in github somewhere, but it wasn't really clear to me how to get at this info. For example, figuring out where/when the SPI modes got corrected. Also, I think it would be helpful to have some kind of "upgrade guide" that people could reference. That is, for example, saying things like: "If upgrading from an earlier version of XXX, you will need to swap anything related to SPI Mode0 and SPI Mode1", etc.
  11. JRDavisUF

    strptime not declared

    I tried editing the platform.txt file, but it didn't seem to do anything....that is, I could never see the -D.. appearing anywhere during the compilation process. I did try changing my compiler settings to directly include the -D... so that I could see where it was being used, but it didn't seem to make any difference and the error I mentioned still showed up. I did realize that the routine that uses strptime isn't used by my code, so I commented it out that whole routine and my stuff works fine...so at least for now, I can punt on this issue...thanks for trying though...
  12. JRDavisUF

    strptime not declared

    I'm using Rei Vilo's RTC Library: https://github.com/rei-vilo/DateTime_Library Under Code Composer 7.4 / Energia 18 / MSP432 Red Board 4.9.1 this library compiles works fine. When I switched to Code Composer 8.0 / Energia 18 / MSP432 Red Board 5.6.1, "strptime" seems to have disappeared. Anyone have any ideas on what happened? Libraries/RTC/subdir_rules.mk:9: recipe for target 'Libraries/RTC/RTC_Library.o' failed ../Libraries/RTC/RTC_Library.cpp: In function 'uint8_t convertString2DateTime(String, String, tm&)': ../Libraries/RTC/RTC_Library.cpp:88:59: error: 'strptime' was not declared in this scope if (strptime(charDateTime, charFormat, &_timeStructure) == NULL) ^ thx. jrd
  13. JRDavisUF

    Simultaneous SPI and SPI1

    Simultaneous SPI and SPI1 works! I've an SD card on SPI and a ADC breakout board on SPI1. I've a small code to stream data from the ADC to the SD card and all looks good.
  14. JRDavisUF

    Simultaneous SPI and SPI1

    Thanks for the patch. SPI1 now works standalone. I'll try simultaneously SPI and SPI1 next.
  15. JRDavisUF

    Simultaneous SPI and SPI1

    Thanks for the patch. SPI1 now works standalone. I'll try simultaneously SPI and SPI1 next.
×