Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by pabigot

  1. It's really unfortunate that there's no quality consumer-level solution for energy monitoring. I loved my TED5000 for whole-house usage, but it took one too many power surges and died. I can't really justify buying another one; it doesn't appear The Energy Detective is very active. I did get a Belkin Wemo Insight for per-outlet usage, but put it on the shelf after I found that it won't turn on the downstream power when it wakes up after an outage. (Imagine having that on a refrigerator then going on a two week vacation. Ick.) It also provided very poor resolution (half-hour averages)
  2. Four years ago I had a wireless network that would lock up nodes randomly, usually after a day or two (or three) running. That was isolated to a similar race condition due to a change in state that occurred between machine-level instructions. That experience is part of why I'm so anal about checking things, and why I don't like coding to special cases that depend on assumptions that might change during evolution of the product. At any rate, after folks have had a chance to review this and point out any flaws I've missed, I'll put a final version of it in Code Vault. (Robustly detecti
  3. Alright, the problem's been identified and we're now down in the weeds. Rather than point out issues in solutions-in-progress, below is my explanation of the flaw and how I'm solving it. Please point out anything that seems wrong or doesn't satisfy the requirements as stated. Those who want to keep trying should not read this post yet. The key phrase, as is so often the case, is: "race condition" The MSP430 features that impact it are (1) the PxIFG register records only edge transitions, not signal level, and (2) disabling interrupts only delays notification of a detected event, it doe
  4. @@spirilis That's the idea, though the lost transitions aren't necessarily transient. @@David Bender That's a better identification of the problem, but your solution needs some tuning. That you're affecting the interrupt status of other pins on the same port could be fixed, but fundamentally there are still gaps. You might simplify the code by using PxIN instead of trying to sample the current state via PxIES+PxIFG, which could make the gaps more obvious. addendum: there is no need to emit events during initial configuration; we just need to know the state.
  5. Concrete is good, but then people tend to focus on details that make the solution useful only in limited cases (like the ability to change the hardware). I'm aiming for a problem description that captures only the most general requirements. Unless I'm mistaken, the problem with my original solution is also present in your code.
  6. Getting warmer. But [as] you described the concern it's not a violation of the stated requirements: it's perfectly OK to start in a "high" state. In the radio application in some situations that might be expected. For example, one solution to sleepy nodes in a wireless sensor network is to have nodes periodically wake up looking for carrier: if it's absent, go back to sleep, but if it's present somebody has something to say, so stay in receive mode until the packet is transmitted (which is conveyed by a separate signal).
  7. @@spirilis From your solutions I'm not sure I conveyed the problem correctly. Does it change your understanding of the problem if I note that (1) under normal operating conditions the signal is low for seconds or minutes at a time and is high for somewhere between 500 us and 500 ms, and (2) the misbehavior in the naive implementation will happen under normal conditions? If anybody else wants to play, I'll post the explanation of what's wrong with the naive implementation and a solution that does work tomorrow morning.
  8. Hah. Full points, and the clarifications in the first post updated to disallow this solution. Remember, I'm a software guy: I don't get to change the hardware so the radio pins show up in multiple places.
  9. It should be possible to solve this without using a timer at all. (Timers are precious, devoting one to this is unacceptable in the context of the real application.) If you want, assume the signal is debounced: I only mentioned transients because I didn't want people to get hung up on attempting to detect them.
  10. Though I didn't specify clearly so you could get full points, a useful solution cannot be captive. I'm not sitting a loop waiting for carrier sense, I'm doing all kinds of other things, including entering LPM. "emit event" is essentially setting a bit in a volatile global and ensuring wakeup from LPM. I should point out that the 20 cycles is notional; the point is "transient" meaning relatively short. Correctness is the priority, not size of code: the original state must be correct and thereafter the current state must be consistent with the original state after application of all receive
  11. I'm putting this in General rather than Code Vault because it's pedagogical: it amuses me more to present this as a problem to be solved than it would to just give the answer, or to keep it to myself. I don't think this has been discussed on 43oh at this level of abstraction before. After giving folks a day or two to think about it, I'll provide my solution and entertain critiques of it. Problem: A digital signal is presented to an MSP430 pin. You need to record the initial state (level) of that signal and be notified of rising and falling edges in that signal. You need to know at all time
  12. I also like that because the source is available I keep multiple versions installed if necessary, something that's probably hard to make CCS do. I'm a bit concerned by the comment somebody made somewhere that the original EXP430FR5969LP would not work with the latest MSPDebug stack that fully supports energy trace, which suggests the new EXP430FR5969LP might not work with the old MSPDebug stack. I too am looking forward to trying this new platform.
  13. That error comes from the MSPDebug stack. There are three locations in the latest release that error is produced. Since it's open source, I'd download and build that locally, reproduce the problem with mspdebug, then instrument the source code to figure out what conditions cause it to occur. Should be a clue in there somewhere.
  14. AT&T's tool only handles English and Latin American Spanish, based on the selected voice. It won't understand IPA symbols, so the j will sound like "jay" with the default English voice. The Spanish voices seem to read it out character-by-character, including some numerical substitution. A quick google failed to reveal a usable IPA-to-sound converter.
  15. I would guess a rev 2.0 board is not covered, but you could ask, if you ordered it before June. Fortunately I was able to request a code from the TI folks by sending them my order number from back in February. Good support from the eStore folks.
  16. So, as best I can reconstruct: Russian ???????, English Energia, IPA /??n?r?ij
  17. Since we're not using IPA here (though the site supports unicode so we probably could): is that what I would write as "eh ner JEE ah", i.e. accent on the "gee"? (Ok, that's just pathetic.)
  18. I occasionally find myself people who want to do low-power stuff and don't want to fuss about at the level of BSP430 or direct programming towards Energia. I stumble on a simple issue: How do y'all pronounce that word? I assume it's not the Spanish pronunciation (neither South American nor European Spanish), because that's just adding gratuitous complexity. Is it "eh NER jee ah" or "EN ner Jee a" or "eh NERJ ya" or something else?
  19. The panstamp NRG is not shown as an option on the page I'm seeing. Maybe it's not available in the US?
  20. Yeesh. I'd never looked at that attachment as the github ones cover my needs; I sure hope they don't continue that case-sensitive distinction in the official release. It'd work for me, but the Windows users will be unhappy. Indeed. You might be interested in BSPACM, which does a lot with the existing CMSIS headers but is mostly on hold until the official ones come through.
  21. I don't have CCS 5.4 on this machine, but CCS 5.5 has no files that contain svd in their name. I'm well aware of the old LM4F headers, have and use those, and have done the comparison with the replacement TM4C123 chips as exposed through the speters github repo (which also has TM4C129). IIRC the difference is enough to avoid cross-use where possible (they work in most cases, and will produce bizarre results in a few corner cases). AFAIK TI has not yet officially released SVD files for any Tiva products (I take attachments to forum postings as not official releases). The material
  22. I'm resurrecting my RF infrastructure (though I'm using BSP430 not Energia) and panstamp NRG would be a lot more compact than EXP430F5529LP+AnarenBoosterpack, though for a few cases I'll probably need the larger code capacity of other MSP430s. The panstamp store has a page, but no "buy here" button. Google's failed me; can anybody provide a status update or link to same? Cost, estimated date of availability, other pertinent information? Thanks.
  23. For those like me and this person who aren't using TM4C because the CMSIS headers aren't available: per this one of the TI folks has stepped up to shepherd the material through a release. It would/will be nice to be able to use these devices with real vendor-approved headers. I do hope they make them available to all customers.
  24. Huh. Never got my notification. Mine's the rev 1.6 board with the slashes on the silkscreen.
  25. Never got into buying rack-mount hardware: too expensive. I still have a 48" four-shelf wheeled restaurant rack that holds six+ desktop chassis plus switch and UPS in the "computer room" but it's down to only one always-on server. I'm probably going to consolidate it with the stuff in the comms closet in the next infrastructure reorg. The office installation is smaller (but still on a wheeled rack with UPS). I do also have a 66-block that would support four phone lines if the folks who wired the house for me had bothered to connect the last two pairs, and a 12-port patch panel supporting
  • Create New...