• Announcements

    • bluehash

      Forum Upgrade   03/11/2017

      Hello Everyone, Thanks for being patient while the forums were being fixed and upgraded. Please see details and report issues in this thread. Thanks!


  • Content count

  • Joined

  • Last visited

  • Days Won


NurseBob last won the day on February 9

NurseBob had the most liked content!

About NurseBob

  • Rank
    Level 1
  • Birthday 09/09/1950

Contact Methods

  • Website URL

Profile Information

  • Gender
  • Location
    St. Helena, CA

Recent Profile Visitors

147 profile views
  1. @Curtis63, I've used both solutions as suggested by @energia, depending on my power choices. One thing to keep in mind if you're using the ADC is what type of battery and the typical discharge curve. Also, you need to think about when and how often you check - right after a power-intensive action may yeld different results than letting a battery recover for some pre-determined time (again, dependent on how the battery responds to loads). My systems are powered by LiPo cells, so the higher voltage output needs at least a voltage divider, and to avoid a slow drain, the ground needs to be through a port or via some other switching device. Batteries are interesting and challenging.
  2. @villekille You might start here for a little background. And as always, Google is a good place to start. FWIW, just entering "bluetooth" in the forum search returns some 20 pages of references. I can't advise you on which '430 to use, but any with a UART and an ADC that meets your needs (again, you don't specify the precision). You may want to do a parametric search on the TI site for '430 mcus that meed your needs.
  3. Events: Such a range of sources. Hardware (internal and external), timers, user-generated, etc. As you alluded to, there's usually a heirarchy of priorities that impact how they are, or need to be, handled. I don't really have any internal association between event-driven and OO; one reflects how things happen, the other is merely one way to define a world view. The PC GUI world is certainly built around the event model and the understanding of the potentially random timing of events coupled with a management of event priority. My fading memory seems to recall that the original implementation of the Windows GUI several decades back was niether OO nor C++, but a loop which handled and/or generated messages. As to my own project, the ISRs are C. The name mangling of C++ led to problems. So, just as TI's C++ libraries do, I define the ISRs as extern C routines. I do spend some time looking at the order and frequency of the case statements in terms of execution, but my implementation spends very little time doing any communication with the sensors, and typically only in response to a sensor-generated interrupt (also rare events), otherwise the app is spending it's time sleeping. I agree, complex code is likely slower to execute. And almost never should reside in an ISR; aside from my TX RX event handlers, my ISRs follow the "set a flag or generate a software interrupt and return" rule. And as much as possible, even the TX RX handlers are setting flags for a main-based while loop to process then go back to sleep where communication timing is not an issue. My knowledge of the C language is probably barely adequate to the task, as well as is my knowledge of C++. However, experimentation is a basis for how my brain works and remembers. I've spent hours in the debugger stepping through both C and disassembled code; fixed problems, and sometimes have even remembered not to create the same problem again. Were it not for Google, code snippets, reference circuits, etc., my little project would have never gotten started, let alone to the point it's reached. Ok, now I'm rambling...
  4. @yyrkoon Understood and agreed. Bob
  5. Typical I2C addresses are the top 7 bits, with the 8th bit determining if the conversation is a read or write. I've been working with a port expander (sx1509) which has 4 possible addresses (determined by pins that are high or low). So multiple addressing for devices is a common theme. I've actually found using binary representation for addressing, or registers, handy. I also found this on implementing an I2C slave from scratch, which proved useful conceptually: http://dsscircuits.com/articles/arduino-i2c-slave-guide While the GPS code is not necessarily relevant, he offers a pretty decent explanation of the communication and setting up of address registers. Re: Davies code - yes, at times he hides implementation via enums, etc, but his long form and ISR versions of an I2C handler are a bit more complete and explanatory than the TI code examples. The "challenge" with the TI code examples is getting past the point that they do nothing useful... Typically they iterate though a defined list of numbers and then restart. The slave code I'm using is focused on the F2013, which is limited to USI. I suspect you want to use the more advanced capabilities in the USCI. My recollection is you're using the G2553? If so, look at the MSP430Ware->Devices->MSP430G2xx->Code Examples->MSP430G2x53- msp430g2xx3_uscib0_i2c_12.c and msp430g2xx3_uscib0_i2c_13.c - the 12 code: USCI_B0 I2C Master TX/RX multiple bytes from MSP430 Slave with a repeated start in between TX and RX operations. and 13 code: USCI_B0 I2C Slave RX/TX multiple bytes to MSP430 Master serve as useful examples of the setup and ISR handlers. Don't omit the pullup resistors - the internal pullups are not sufficient or consistent. Bob
  6. If the device is a commercial part, it's published. If it's your own design, the '430 peripheral code examples will be your guide. Basically, you set up the I2C handler for the slave to respond to its transmitted address. FWIW, the hand-coded examples in Davies' MSP430 Microcontroller Basics(there's a pdf version - google "msp430 microcontroller basics") book on the '430 give a reasonable explanation. If you're designing something to be incorporated with other I2C devices, then you need to pick an address or addresses that aren't in conflict with other devices. I don't know if there's a "registry" for I2C device addresses.... The example code for TI and Davies all use 0x48 and 0x90; for the addresses.
  7. Sound very cool, and I assume, a fair amount of time spent deciphering Logic Analyzer and Oscilloscope traces. Were it not for those two pieces of equipment my aging brain would be on fire (oh, and the 60's rock on pandora helps keep me sane, too)... I have an email-friend in Australia who designs and develops for the '430 and only writes in assembler. Per his comments, it's theoretically possible to use only a blinking LED to figure this all out, but that's far beyond my ken...
  8. I couldn't agree more with the points you make regarding C, C++, complexity and remembering which planet you're standing on... While I've been designing, reflow soldering and developing on custom PCBs, I've been using the inexpensive launchpads to develop much of my initial code; so similar to your approach with TDD, I'm building separate test modules for each of my I2C sensors (often evm boards as well) where I can run code and devices without risk of unexpected or unintended electronic interactions between different elements. Once I have a functioning and tested module, that gets added to the custom board, populated with all the devices, to confirm everbody gets along, which doesn't always happen - in particular the I2C pullups are definitely different on my custom board - pull harder - than my test rigs. I assume this is due to the bus capacitance for a multi-device system and circuitry. (I've spent time reading, digesting and struggling with TI's SLVA689 to sort this out, but ultimately it's been experimentation...)
  9. Well, I don't find any real conflict between OO and event-driven systems; the events just need to be incorporated into the design. I guess I think of hardware events as a variant of messaging. My '430 code tends to have a setup in main that ends in a "forever" while loop structured around an LPM3 statement. Hardware events set state flags and the loop figures out how to handle the event, then goes back to sleep. I know from a '430 standpoint that's pretty much a standard design, but the "fun" has been in figuring out how to code for the ISRs, which live in a C subroutine and then chain back to a C++ class handler. The main concern and complexity for my limited brain is the design of a "generic" I2C ISR to handle the I2C communication for each of my I2C device classes. In essence the design for each I2C device is class-based, but dependent on the one I2C ISR, which uses a state variable and switch/case construct contain the handling of each I2C device's needs. I'll be soon finding out if the overall design is sound as I incorporate the remaining I2C sensors and devices.
  10. C vs C++ ? As @yyrkoon noted, favorites and comfort tend to be strong influences. Personally, I'm challenged not to fall into the "I have a Hammer, everything is a nail" trap. It's been so long since I programmed in either C or C++ as a "professonal" that either choice has the risk of hidden pitfalls. And, there's always the challenge of developing code that can be maintained if the goal is some product with any lifespan. I still remember my shock/surprise to run into someone from EDS who was maintaining code I'd written in Clipper - some ten years product had disappeared from the market... Says something about EDS? (I remember a manager proudly stating we sold solid, tested, trailing-edge technology - though he may have used "tried and true" in place of "trailing-edge") Right now, I have a project where two different msp devices, one with significant memory constraints, the other without, where I'm writing in C for one and C++ for the other. Not as confusing as when my older daughter was studying both French and Spanish simultaneously, but still with moments of "Can I do this? Should I do that?" Personally, I like the object paradigm, which fits the way my brain works better. But C (hopefully well designed and structured) is the better choice for my one limited device. The master device has significantly more complexity to the design, and C++ is likely to allow for a more easily maintained system - again assuming a good design. Bad designs can be implemented poorly in any language, and become rapildy, if not immediately, unmaintainable.
  11. @Dortal, As @Clavier noted, you should be able to fire the solenoid directly from the MSP430G2553, which would eliminate the likely significant communication latency the USB scenario you described would introduce. There are timer examples for the MSP that are analagous to your experiment which should not be too difficult to adapt. Re: USB support - You would need to use one of F5529 launchpads, which have native USB support (not as a as a controller, just as a USB device). There is a USB Developer's library via MSPWare with code examples. Bob
  12. @yyrkoon, One place you might explore is under the "code examples" sections for the G2553. In particular, I'd start with: msp430g2xx3_uscib0_i2c_04.c ( USCI_B0 I2C Master RX single bytes from MSP430 Slave ) msp430g2xx3_uscib0_i2c_05.c ( USCI_B0 I2C Slave TX single bytes to MSP430 Master ) and msp430g2xx3_uscib0_i2c_06.c ( USCI_B0 I2C Master TX single bytes to MSP430 Slave ) msp430g2xx3_uscib0_i2c_07.c ( USCI_B0 I2C Slave RX single bytes from MSP430 Master ) As the examples note, you need the external pullup resistors. These examples will compile under CCS, IAR and GCC and while simplistic, they are a starting point for seeing the I2C comm in the debugger. I've used similar examples for the F2013 and F5529 to get those ICs to talk to each other, and subsequently to write code for the F5529 to talk to an sx1509 port expander (an adventure in reading and understanding docs...). FWIW, I would never have gotten very far without using both my logic analyzer and my oscilloscope... As to the jtag header and spy-by-wire headers (how I build all of my prototypes) - make sure there's the 47k resistor for the reset line (most devices do not need the capacitor placed), and you may want to account for using an external supply instead of the FET. The debuggers generally are limited in their supply capacity to ~50-60 mA. If your circuit is driving other devices, that can lead to failure for the debugger to even start. HTH Bob
  13. > I have used a multimeter and I measure this pin and I get between 1.10 and 1.15V. Is this in reference to the msp432 pin? I thought you were measuring the lm35... So, if you're testing the P5.4 pin, and you have CCS, I'd look in the debugger at the port registers to see if your statements to set P5.4 SEL1 and SEL0 are actually working as intended. Where is the sample code from? Aside from that, I don't have a suggestion.
  14. Do you have another device? I have some lm34s -T092 devices (read F instead of C) and in my home office I'm seeing .70V - or 70 degrees F when attached to the LP 5V tap. My recollection is that it's easy to damage the devices with ESD or if wired wrong... Other than that, I don't have more to offer. Bob
  15. A few questions: What is your power supply? What was the temperature of the environment? The lm35 needs at least a 4V supply. Its output is 10mV/degree C, so at 20 degrees C, the output should be 200 mV.