• 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!

NurseBob

Members
  • Content count

    120
  • Joined

  • Last visited

  • Days Won

    12

Everything posted by NurseBob

  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.
  16. You might also explore the software for one of TI's older experimenter boards which had the ability to record and play back audio for both specs and firmware. Not energia-friendly, but still instructive.
  17. While I2C is not my strongest area, I'm wondering about the clock in the two situations. Stepping through Energia's wire implementation I have this vague memory that it defaults to a 400k clock??? Could that play a role? And, as often can be the case, could pulldown resistors be playing a role??? Bob
  18. @bluehash Thank you for the hard work. I've had enough experience with running sites to know how time-consuming, and frustratiing, it can be. Bob
  19. One last note - The driverlib example runs at 100kHz and it appears that the Wire.cpp code sets the clock to 400kHz. I believe that the pullup resistors may need to be of lower values with the faster clock, but that's probably not all that's happening.
  20. Danial, I suspect the issues are more with Energia and the Wire library, rather than the board/mcu. Unfortunately, I don't have the time or skills to really delve deeply into the Wire/Energia code to better understand what is, or is not, happening. The fact that the driverlib code works under CCS indicates it's not the hardware. Bob
  21. On further investigation, I've managed to migrate a pair of msp432 driverlib examples from their P1/EUSCI_B0 to a P6/EUSCI_B1 implementation. The code examples selected were: msp432p401x_eusci0_i2c_10 (master) and msp432p401x_eusci0_i2c_11 (slave) Basically, a find/replace of all "EUSCI_B0" instances with "EUSCI_B1", as well as editing the interrupt enable from "EUSCIB0_IRQn" to "EUSCIB1_IRQn", and the interrupt handler from "EUSCIB0_IRQHandler" to "EUSCIB1_IRQHandler". Finally, the port assignments need to be updated from: // Configure GPIO P1->OUT &= ~BIT0; // Clear P1.0 output latch P1->DIR |= BIT0; // For LED P1->SEL0 |= BIT6 | BIT7; // I2C pins To: // Configure GPIO P1->OUT &= ~BIT0; // Clear P1.0 output latch P1->DIR |= BIT0; // For LED P6->SEL0 |= BIT4 | BIT5; // I2C pins As before, 2k2 pullups.
  22. I found I could get the test code to run with a pair of msp430f5529s after importing the energia project to CCS 6.1.3, recompiling and uploading. However, that approach was not successful with the '432 devices. I see the communication attempts with the '432 in the logic analyzer all followed by NAK, rather than an ACK. The successful comms are with the '430s. I note that I could not get the code to work when compiled and loaded with Energia 18. I haven't tried 17... I'm using a pair of 2k2 resistors for the pullups. The setup in both cases is the same, except for the LP boards. SCL is to P6.5 on the '432 and P4.2 on the '430, and SDA is on P6.4 on the 432 and P4.1 on the '430, which is the BP standard.
  23. 1) The "weird" display could be a serial comm mismatch between your PC serial port and the serial output from the boards. So, first check that your serial display is set to the same baud rate as the sketch. 2) I2C requires pullup resistors. While some sketches will use the internal resistors available on some msp devices, those internal resistors are often too "weak" - around 30K to work effectively, if at all. Typically, 1K - 10K work well. Further, I would use the 3.3V supply for your pullups. The msp ports are not 5V tolerant, as they are natively 3.3V devices. The 5V pin is coming off of the USB connection. 3) Posting the actual code you are running is always important and useful to help others sort out issues. Regarding I2C pullups - I wish that TI would offer a LP board with pads where I could add an "optional" pair of resistors. Tying-in external resistors is a pain...
  24. @@curtis63 I think you'll find what you're looking for in this zip file: here or go to this page http://www.ti.com/lsds/ti/microcontrollers_16-bit_32-bit/msp/tools_software.page - scroll down to "Code Examples for MSP Microcontrollers" and click on Show More to see all the examples This is a zip file of plain C or Assembler code, for both CCS and IAR Kickstart as well as a GCC make file. You'll want to look at the set of files named msp430g2xx3uscib0_i2c_01 - _13. I've found similar for the F2013 very, very useful. A couple of days ago I set up a master->Slave multibyte read/write. Since the F series devices share a very similar code base, "porting" the master code to a F5529 is pretty clean. BTW - typically the example use the internal pullup resistors. This approach is risky at best. Use a set of real pullup resistors (1k - 10k range) and comment out the pullup resistor code. HTH Bob Oh, BTW, I usually start the slave first, then the master, seems to be more reliable with the code examples. They are not robust regarding connecting, and on my system the voltage swings when starting the debuggers is often "seen" by the slave, putting the state machine into an incorrect state to connect. Also, I'm not trying any of this in Energia or with the launchpads at this time (I have connected a 5529LP to an F2013 via I2C in the past, just not now) - I use a pair of the FETs and run two instances of IAR to watch the debuggers in both windows. I don't think CCS supports running multiple instances unless you set up separate workspaces.
  25. >As per the hard copy provided by TI with board they say that all the pins are interrupt enabled If you review the user guide for the F5529 page 3 fig. 1-1, you will find that only ports 1 and 2 support interrupts & wakeup (from LPM4), further documented in table 4-1 Terminal Functions Also, posting the code you're running is the only way for others to evaluate what's happening or not happening...