Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Reputation Activity

  1. Like
    tripwire reacted to bluehash in Have feedback for TI? Please share here.   
    Hello All,
    Here is some feedback. Apologies on the late reply.
    There was approximately an hour to field our questions/requests.
    On a few questions that were not asked, I have an open channel with them.

    - This was my primary focus. I am aware most of you don't care much about it, but there are alot of users coming in from the Arduino world to the TI family.
    A couple of others in the room and myself were concerned about the future of Energia and its support. We were assured that more was being done and we'll know
    more in some time.

    Higher RAM chips on the value line
    - Let them know that higher RAM on the chips shipped with the Launchpad is invaluable. It keeps us from implementing the cooler stuff.

    USB on MSP on the lower end devices
    - Let them know about it. They are aware about the lack of this feature. From my view, low power and USB do not go hand in hand... it may be a challenge.
    EDIT: Just wanted to confirm... that it is my view that USB and low power may be a challenge... not TI's.. They may already have something in the works. I don't know.

    MSP432 DMA
    - Feedback given. They will take this back to the chip architechts.

    - This is becoming mainstream in a lot of their devices and is quite popular. I left this discussion off.

    TI EStore International Shipping
    I was not able to get to the person incharge of the Store. But they do know of the issue. I'll push this again.

    Energy Trace requests
    - The team would like a list. I'd suggest someone start with a list in the forum and build up on it.

    CCS bugs
    - A list would be good. I'll have someone from TI look at it and post it in their CCS forums.

    MSP software
    - More improvements

    - Something new/revamped.
    Other comments. They were interested in how we used the TI site, the forums and social media. They were looking for feedback on their datasheets, block diagrams,examples and newsletters. There was also a chat with the calculator group and the TI-Innovator system.

    If you have an issue with TI's tools, the best place to put them is in their E2E forums. If it is a long list/request list post it here.
  2. Like
    tripwire reacted to Fmilburn in Have feedback for TI? Please share here.   
    Thanks @@bluehash - appreciate the feedback.
    I normally avoid debates on topics like this because they are seldom fruitful but can't help myself today.  Getting started with embedded electronics is difficult for a hobbyist if they don't have the background.  It requires knowledge of software, microcontrollers at the register level, electronics, mechanical interfaces....  Pretty daunting if you don't have at least some background and access to a community of people willing to help you learn.  Energia / Arduino / Wiring has done a lot to give that access.
    I don't think it is any different than gardening, woodworking, or hobbyist astronomers using amateur tools and the skills they have to do something they enjoy.  Besides with that head start you can always dive deeper.  And lots of valuable contributions have been made by enthusiasts using amateur tools in all kinds of fields.
    My thanks to TI for their support - it is much appreciated.
  3. Like
    tripwire reacted to NurseBob in Seeking advice - MSP430F5529 C/C++ vs Energia   
    I found the Energia IDE not very useful. I have worked with IAR and CCS for some time, and immediately ran into the limitations.  However, the HAL approach, which is what I thought I saw, is very appealing.  Thanks!
  4. Like
    tripwire reacted to RobertWoodruff in Seeking advice - MSP430F5529 C/C++ vs Energia   
    My recommendation is to use the Energia Setup()/Loop() construct, And use CCS as the IDE rather than the Energia IDE. CCS is Eclipse and so the its debugger can be used.. Without the debugger progress will be tough.
    LPM3 is encapsulated in Energia by the sleep() methods so you make sleep() calls rather than LP3 directly.
    I have  the MCU to respond to traffic on the UART RX channel while in LPM3 by processing the requests during the RX ISR wakeup.
    Thank you,
  5. Like
    tripwire reacted to Rickta59 in Program won't fit weirdness   
    cdecl.org is your friend here:
  6. Like
    tripwire reacted to terjeio in Program won't fit weirdness   
    MSP430G2553 has only 512 bytes RAM - so not much to play with for storing variables.
    You can change the alpha_num data stucture to const to save RAM if you do not need to change it.
    16KB is the amount of flash memory available.
  7. Like
    tripwire reacted to Fmilburn in [POTM] dAISy - A Simple AIS Receiver   
    Setting up dAISy for use as a shore based AIS station that reports data to MarineTraffic is easy to do with the CC3200 and Energia.  I am still playing with it a bit but have posted working code here. 
  8. Like
    tripwire reacted to chicken in [POTM] dAISy - A Simple AIS Receiver   
    Thanks for shattering my plans for consumer gadget world domination
    Technically the range of AIS is about 50 nautical miles, but that requires an unobstructed view and a properly placed and tuned antenna.
    With my wimpy dipole antenna (two straight hookup wires) and the wrong impedance matching (50 ohm instead of 73 for a dipole) I was able to receive the packets from the base station 11 kilometers away when in line of sight. When I was parked at the waterfront with the antenna laying on my car's dashboard, I was able to receive messages of ships in line of sight about 2.5 kilometers away and 500 meters when obstructed by buildings.
  9. Like
    tripwire got a reaction from spirilis in Compiler optimization traps for the unaware   
    If anything I'd have expected: 5, 4, 1, 3, 2, 0 (sorted by key rather than value or insertion order). That's what you'd get out of a std::map in C++. The C++ standard library designers originally avoided the issue of unspecified map iteration order by only permitting ordered maps, and hash-based maps were not officially included until C++11.
    In terms of performance, it looks like the randomisation in go is a random start offset rather than a complete shuffling of the iteration order. That's just enough to prevent anyone from relying on the order from one iteration to the next.
    They might also have some random input into the hash function which would jumble the ordering between program runs. Apparently that can also be implemented to defeat hash collision DoS attacks when user-provided values are used as map keys.
  10. Like
    tripwire reacted to spirilis in Compiler optimization traps for the unaware   
    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/help/contributed libraries from the open source community at large.  The book that introduced me to the language, "The Go Programming Language", was coauthored by Brian Kernighan (also of Bell Labs and the 'k' in the AWK utility under Unix).  These guys pretty much know what they're doing.  Anyway enough threadjacking
  11. Like
    tripwire reacted to yyrkoon in MSP430G2553 multiple interrupts.   
    I guess I was worried about nested interrupts. But after reading and refreshing my memory I suppose nested interrupts has to be enabled first. I was thinking that I had to disable interrupts every time I was in one . . .
  12. Like
    tripwire reacted to chicken in Display message in LCD with MSP430   
    The code looks pretty straight forward. I'd approach translation to assembly like eating an elephant: one bite after the other.
    Translate each line of C code to it's equivalent in assembler. Put some extra thought into how to pass parameters into functions.
  13. Like
    tripwire reacted to Fmilburn in [POTM] dAISy - A Simple AIS Receiver   
    dAISy Ethernet Adapter

    The dAISy Ethernet Adapter packages a dAISy AIS Receiver in an enclosure with a W5500 Ethernet module and a MSP430G2955 to control it.  With the addition of a marine VHF antenna, power via USB, and an Ethernet connection local marine traffic can be reported to the internet:

    The simplified block diagram below shows the main components:

    The MSP430G2995 was chosen over the more common MSP430G2553 for its additional RAM and was adapted to Energia and an Ethernet library ported.  Relatively large SMD components (e.g. 0805 resistors and capacitors, 38 pin TSSOP microcontroller) were chosen to allow hand soldering if desired.
    The finished product is shown below with the enclosure open:

    The project was a collaboration with @@chicken.
    Links and References
    dAISy 43oh thread: http://forum.43oh.com/topic/4833-potm-daisy-a-simple-ais-receiver/
    dAISy Tindie:  https://www.tindie.com/products/astuder/daisy-ais-receiver/
    MSP430G2955 Energia: https://github.com/fmilburn3/MSP430G2955_EnergiaPinmap
    W5500 Energia: https://github.com/fmilburn3/W5500_Ethernet
  14. Like
    tripwire reacted to spirilis in Compiler optimization traps for the unaware   
    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
  15. Like
    tripwire reacted to Fmilburn in delay() broken on MSP430FR4133? blink doesn't work   
    Some of the microcontrollers in the MSP430 line have limited resources, including timers, and the WDT is used for delay().  Conflicts can occur in the functions used by Energia/Arduino if the underlying hardware registers are modified.
  16. Like
    tripwire reacted to spirilis in Compiler optimization traps for the unaware   
    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 based on consistent undefined behaviors.  As a result you are forced to convert those sorts of things into a list and sort them or whatever ... something better-defined anyhow.
  17. Like
    tripwire reacted to chicken in Compiler optimization traps for the unaware   
    Here's a very interesting presentation about how modern compiler optimization may lead to unexpected results. This goes way beyond the failure of naive delay loops.
    If you ever relied on buffer indices wrapping around (integer overflow), this is a must read. There are many other scenarios discussed.
    For example I'm pretty sure I fell for this trap myself:
    volatile int buffer_ready; char buffer[BUF_SIZE]; void buffer_init() { for (size_t i = 0; i < BUF_SIZE; i++) buffer[i] = 0; buffer_ready = 1; } It probably works today. But it's a bug waiting to happen when I recompile with different optimization settings or a different compiler. (hint: buffer_ready=1 may be moved before the for loop because the loop does not affect any volatile location).
  18. Like
    tripwire got a reaction from Rei Vilo in [FIXED!] JTAG interferes with SensorTag external flash access   
    Good news! This issue is fixed in the TI Emulators package, which contains the version firmware for XDS110.
    TI have added support for 2-wire cJTAG debugging, which only uses the TMS and TCK lines. In the firmware they also stopped the emulator from driving TDO, which was blocking access to the SPI. It looks like 2-wire cJTAG is the default mode now too, so debugging SPI flash code should just work like you'd expect.
  19. Like
    tripwire reacted to enl in RANT: Cloud of this, IoT of that . . .   
    I don't follow that end of the universe at this point. I have worked in facilities with good, though AFAIK wired, network lighting control.
    The consumer technology seems to be predominantly gimmick. Historically, the early adopters drove technology, and by the time it made mass market, there was a reasonable level of reliability and utility achieved from the experience of the early adopters. I don't see that with most of the IoT devices, honestly including the lightbulbs. I see a few uses in the home, and in fact have wireless control (formerly X10, now RF keyfob hanging on the wall by the door) for lights in my basement, as I didn't want to run more wire for the switch. I do not trust a system that requires a smartphone to operate the lights in my house (lose or break the phone and SOL until replaced) via bluetooth (poor security)
  20. Like
    tripwire reacted to yyrkoon in RANT: Cloud of this, IoT of that . . .   
    One of the biggest offenders in my mind is MQTT. Or at least the use of MQTT the way I've seen it demonstrated. It would not take much brainpower to royally screw up someones remote system through that protocol.
    But, if you also occationally watch defcon, or other white,black, grey hat videos. You'll noticed several on hacking just about any wireless protocol out there. Bluetooth is particularly bad. By "particularly bad",  I mean I can not believe people actually endorsed the standard . . .Because the standard is horrendous. Then to compound things even more. Even though BLE is very short range. It does not stop others from "painting" your signal and spying form a greater distance. Which is why I'm glad we're essentially "wrapped in tinfoil" in our house. Which is actually an 80' x 100' steel building.
  21. Like
    tripwire got a reaction from yyrkoon in RANT: Cloud of this, IoT of that . . .   
    That works against remote attacks, but the linux/BSD/non-windows server protecting the wireless device can be bypassed if you're in the vicinity. Then the unsecure wireless device can be exploited to leak your wireless key (for example).
    The scale of that approach is greatly limited by the need to be near the target, but it means you can't assume a secure router will protect you if the devices are unsecure.
  22. Like
    tripwire got a reaction from yyrkoon in RANT: Cloud of this, IoT of that . . .   
    Agreed. That's why I'm not delighted by the prospect of IoT-mania encouraging a proliferation of cheap internet-connected devices.
  23. Like
    tripwire got a reaction from yyrkoon in RANT: Cloud of this, IoT of that . . .   
    So, yeah: "Designing an internet-facing server with security protection can be a very challenging task" is fair enough. It's not so much that the original title implies the world will end if you don't attend, more that it implies the content is somehow specific to IoT when it's not.
    What would be nice is if someone came up with a way to deal with the security holes left in the many internet "things" abandoned by their manufacturers without ongoing firmware updates...
  24. Like
    tripwire got a reaction from yyrkoon in RANT: Cloud of this, IoT of that . . .   
    Or the person making the IoT device *DOESN'T*
    (Yes, this has since been patched out)
  25. Like
    tripwire reacted to chicken in RANT: Cloud of this, IoT of that . . .   
    That's why emails with cloud and IoT in the title usually get deleted unopened.
    That being said, I think the webinar description is pretty clear and level-headed. It's about means for secure communication between the gateway and a node. Probably TLS and some such. Not sure where you got the end-of-the-world and ultimate-security-solution-for-everything vibe from.
  • Create New...