Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by spirilis

  1. IIRC, it does, but only under sleep() and sleepSeconds() mode. Higher resolution is available via DCO which is why it uses it. Just not necessarily the best accuracy I guess...
  2. That is true, millis only updates when the ISR fires, so your sketch may be pulling the millis value some time "after" the last tick. For the purpose of getting a super-accurate clock, I would look into making your "own" millis-style API using one of the Timer_A peripherals and include a direct-read of the TAxR register to compensate for between-ISR timing. You should have free access to declare one of the Timer_A interrupt vector entries in your own sketch without Energia getting in the way. Just be sure you're not using a PWM output pin that happens to use that same Timer_A instance or
  3. Not too terribly accurate as you've found. It would require modifying the Energia core quite a bit to change millis() as it uses the Watchdog timer. Jitter and drift will be caused by the main oscillator (DCO) mostly. It's not known to be all that accurate but can be trimmed. At least with the F5529 there is an FLL driven by the 32.768KHz XTAL to auto-trim it.
  4. Yeah Go really goes about it a bit differently, the "implicitly satisfied interfaces" becomes your rough method of inheritance and class-ishness I guess. It's working well enough for me so far.
  5. What kind of errors? I have Windows 10 Professional (laptop came with it preinstalled though) and no problems, but I will note I made sure to install all the TI drivers in signature-ignore mode (i.e. hold Shift while clicking the Restart menu option under Start>Power, select reboot to options menu, select option 7 after the reboot for booting with no driver signature verification, then install drivers in that special mode). I did the same thing when I installed CCSv6 too.
  6. The Energia framework itself doesn't really play well with the MSP430 USB API from what I recall. There is a "USBSerial" example shipping with Energia but it's mostly a hacked up example using an old version of the MSP430 USB API (pre-driverlib if I'm not mistaken). With straight CCS C/C++ you can use the MSP430 USB descriptor tool to generate custom USB setups.
  7. Fwiw Go is actually compiled. With a bit of a binary runtime that "tags" along and manages the threading subsystem + garbage collection... but the Go compiler actually has its own assembler & linker and circumvents the use of any "C" code whatsoever. The compiler used to be built as a C program for quite a while but around 1-2 major releases back, they ditched the C portion and it's now written entirely in Go from what I read Mind you, Go is written by Rob Pike (think Plan9), Ken Thompson (think UNIX) formerly of Bell Labs... and their team of folks at Google along with other input/h
  8. Well yeah one fun thing about the example I gave is that I specifically assigned the entries in a logical order ... but the point here is, that iteration doesn't necessarily make sense in the case of a map because things can be deleted and re-added arbitrarily and the order can be a bit "undefined" and difficult to ascertain. E.g.: myMap := make(map[string]int) myMap["ten"] = 10 myMap["nine"] = 9 myMap["zero"] = 0 myMap["one"] = 1 for k, v := range myMap { // One might "assume" to see 10, 9, 0, then 1 here fmt.Printf("Value: %d\n", v) } myMap["three"] = 3 for k, v := range myM
  9. I personally find it a good thing, in that this is creating a programming environment where the likelihood of mental blindspot-like errors is low. Combining Go with an IDE that actively syntax-checks, like Visual Studio Code (the javascript side project of the M$ VS team), I've found that I can write Go code that usually works pretty much perfectly as expected ... sometimes on the first compile. I'm quite pleased with what Google and the Go team are doing here. Alas, to each his own
  10. Lol reading this presentation is almost nauseating! As a side note, one thing about the "Go" programming language I found amusing is how they intentionally break a few undefined behaviors, such as: myMap := make(map[string]int) myMap["zero"] = 0 myMap["one"] = 1 myMap["two"] = 2 myMap["three"] = 3 myMap["four"] = 4 myMap["five"] = 5 for k, v := range myMap { fmt.Printf("Value: %d\n", v); } This code will not produce a neat order of 0, 1, 2, 3 .... It will be shuffled/randomized. The Go designers did this intentionally to break programmers' code when they try to rely on assumptions ba
  11. I do know the CC3200 peripherals are different from the TM4C123's. I personally liked the TM4C123 peripherals. CC3200 peripherals suck, and the MSP432 just uses a jacked version of the old MSP430 peripherals which suck compared to the TM4C123's too. Luckily, the newer SimpleLink CC26xx (BLE/2.4GHz 802.15.4 ZigBee-et-al type of crap) and CC13xx (sub-1GHz) ARM chipsets appear to borrow the TM4C123 peripherals from what I can tell... (and throw power consumption metrics down even further than the MSP432). They also have a digital I/O switch matrix that lets you route any peripheral's funct
  12. Have a peek at <energia install location>\hardware\<platform>\libraries BTW... e.g.: C:\energia-0101E0017\hardware\msp430\libraries Some stuff might be in the core, which is also fun to peruse: C:\energia-0101E0017\hardware\msp430\cores\msp430
  13. Yes delete the SPI folder from C:\Users\tgkann\Documents\Energia\libraries\ Just #include <SPI.h> in your sketch and Energia will "automatically" include it.
  14. It's been a rare incident when I've needed a quick prototype PCB "that" quickly.... and mostly for quick Christmas gifts 1 week before ;-)
  15. Energia ships with an SPI library for each of its platforms. Delete the one you just installed in your local copy; it's designed for Atmel AVR chips, not the TI chips.
  16. Yeah the G2 LP emulator is likely the reason. I don't recall what library in Windows supports the G2 emulator but the MSP Debug Stack (libmsp430.so, MSP430.dll in Windows) doesn't seem to in Linux IIRC.
  17. Good catch. @@energia minor documentation fail! Although the method is related to the one accidentally described, but it should have been rewritten for clarity IMO. Plus the capitalization in the link down below for Stream.SetTimeout looks weird... though I can't corroborate if that's correct on my phone right now.
  18. There's a bunch of /etc/udev.d/rules entries you should have that might "grease the skids" for Energia FET updates. Unfortunately I don't have them handy anymore (blew away my Linux install and went with a new Windows 10 laptop...) edit: Are you using Energia as a normal user or as root? This is important, what those "udev rules" I mentioned do is allow normal users (or users in the "dialout" group usually) to have write access to the USB VID/PID of the FET's USB bootstrap loader.
  19. Ahh nevermind... I should've checked the datasheet/schematic Yeah no idea what to do there. I mean strips of 50mil pins are available (just cut to length)... I am happy they improved this in the later XDS110 LP's like CC2650 & CC1310.
  20. Read the link I posted above- http://www2.keil.com/coresight/coresight-connectors/
  21. OK maybe that's it! FYI- I ordered some 50mil 2x5 cables from Tag-Connect recently ( http://www.tag-connect.com/ ), although the 2x5 connectors themselves (for your own external board) aren't sold by all distributors... More info on that connector: http://www2.keil.com/coresight/coresight-connectors/ - first one Mouser.com doesn't sell Samtec products but Digikey does: http://www.digikey.com/product-search/en?keywords=FTSH-105-01 - I haven't looked but they might sell the 10-pin F-F patch cables too. Mouser didn't seem to... My plan will be to use the 6 pin Tag-Connec
  22. Yes remove the jumper block and attach a suitable cable ... IIRC (don't have mine in front of me) there is an ARM Cortex SWD header on the board, 2x5 pin 50mil (1.27mm) pitch header, that can be used with a suitable jumper cable to program another MSP432 project externally. Remove the jumpers from the jumper block of course so the XDS110 JTAG programmer (top 1/3rd of the launchpad board) isn't trying to program the launchpad's own MSP432 of course. edit: hmm, I might be wrong about this, the 2x5 header on the MSP432 launchpad might only be for attaching external JTAG tools to the MSP432 o
  23. Although thinking about it a bit more, PIN.h might just be an intermediate generated file from XDC provided as such because the RTOS might be partially in ROM. Hmm...
  24. Oh man. What's worse though, is when TI blatantly ignores the XDC system and tosses an "XDC-lookalike" API in place instead... C:\ti\tirtos_cc13xx_cc26xx_2_16_01_14\products\tidrivers_cc13xx_cc26xx_2_16_01_13\packages\ti\drivers\PIN.h being a fantastic example. All the right object names, such as "PIN_Handle", but typedef'd inside one huge .h file instead of properly implemented using XDC code. Not even sure where some of the functions live since they're declared extern inside the .h file while some of the "methods" are declared static with code present inside the header. What a
  25. Well the function naming convention does have a method to its madness. It's just a poor man's C way of defining namespaces. Power_init() is probably best thought of as "Power.init()" ... Spi_Handle (or any Modulename_Handle) is just the inevitable pointer to an object's internal variables that you need to carry around when referencing objects; C++ does this for you implicitly but under the hood the same damned thing basically happens (look at the generated ASM from a C++ program's object's method calls, you'll find a pointer to the object's internal struct loaded into one of the argument
  • Create New...