• Content count

  • Joined

  • Last visited

  • Days Won


Clavier last won the day on March 29

Clavier had the most liked content!

About Clavier

  • Rank
    Advanced Member

Recent Profile Visitors

44 profile views
  1. The G2553 chip itself does not have USB support. You can go through the LaunchPad's "application"/"backchannel" UART; you firmware then just needs to write/read the UART. You also need an application on the host PC to read from one COM port and write to another. But why use USB? Why can't you control the solenoid directly from the LaunchPad?
  2. In theory, the function call overhead should have taken care of the one-cycle delay. It appears that in practice, the compiler managed to optimize that away somehow. (I guess your MAP_ functions do not go to ROM but to your own copy of driverlib, and the compiler inlined all of it.)
  3. This sounds like a hardware bug. Can you reproduce it with a program that uses neither Energia nor driverlib?
  4. and But the latest release there is 1.6.8.
  5. Clavier's Short Guide to I²C Slaves on the MSP430x2xx Family Read section of the User's Guide, and the example code. Slave mode is somewhat easier than master mode because you do not have to care about getting the transaction sequence correct; you just react to the master's requests. The slave address is an arbitrary but unique 7-bit number. Just put it into the I2COA ("own address") register; the USCI module will automatically handle transactions to this address. You do not need to configure a clock source; the clock signal is supplied by the master. When the master has written a byte, you get an RXIFG interrupt. Your interrupt handler must read that byte from RXBUF. (You can set the TXNACK bit after reading RXBUF, this will tell the master to stop after the following byte.) When the master wants to read a byte, you get a TXIFG interrupt. Your interrupt handler must write a byte to TXBUF. If your code is slow, the USCI module will automatically stop the bus via clock stretching until you have reacted. You can get notifications when start and stop conditions happen (STTIFG and STPIFG), but that is not always necessary. The I²C protocol itself defines only byte reads and writes. If you have registers, you have to handle the register address yourself. Typically, the first write after a start condition is the register address, and all following writes (and all reads) are from/to the specified register (and often the register address automatically increments). As a slave, you have no control over what the master does; you must react to any write and read requests at any time. (If you really have nothing to read, just send the last byte again, or some garbage byte.)
  6. This is how I do my GPIO initialization. It doesn't handle any later GPIO accesses, but it's a nice table, and smaller and faster than configuring the bits one by one. /* use 0 or 1 to set the output level */ #define OUTPUT 0x00 /* default */ #define INPUT 0x02 #define PULL_DOWN 0x04 #define PULL_UP 0x05 #define REDUCED_DRIVE 0x00 /* default */ #define FULL_DRIVE 0x08 #define GPIO 0x00 /* default */ #define PERIPHERAL 0x10 struct digital_io_init_f5529 { u8 P1[8]; u8 P2[8]; u8 P3[8]; u8 P4[8]; u8 P5[8]; u8 P6[8]; u8 P7[8]; u8 P8[3]; u8 PJ[4]; }; static void init_port(const u8 *init, unsigned int count, uint16_t int base_address) { uint16_t out = 0, dir = 0, ren = 0, ds = 0, sel = 0; uint16_t bit; for (bit = 1; count > 0; init++, bit <<= 1, count--) { if (*init & 1) out |= bit; if (!(*init & INPUT)) dir |= bit; if (*init & PULL_DOWN) ren |= bit; if (*init & FULL_DRIVE) ds |= bit; if (*init & PERIPHERAL) sel |= bit; } HWREG16(base_address + OFS_PAOUT) = out; HWREG16(base_address + OFS_PADIR) = dir; HWREG16(base_address + OFS_PAREN) = ren; HWREG16(base_address + OFS_PADS ) = ds; HWREG16(base_address + OFS_PASEL) = sel; } static void init_ports(const struct digital_io_init_f5529 *init) { init_port(init->P1, 8 + 8, PA_BASE); init_port(init->P3, 8 + 8, PB_BASE); init_port(init->P5, 8 + 8, PC_BASE); init_port(init->P7, 8 + 3, PD_BASE); init_port(init->PJ, 4, PJ_BASE); } void init() { init_ports(&(const struct digital_io_init_f5529){ .P4[4] = PERIPHERAL | OUTPUT, .P4[5] = PERIPHERAL | INPUT, .P7[0] = GPIO | INPUT | PULL_UP, .P7[1] = GPIO | OUTPUT | FULL_DRIVE, /* ... */ }); }
  7. If the Energia libraries do not have support fo the SD16 module, then your only choice is to program the registers directly. Which is what these examples show.
  8. There is a "MSP430F20x3 Code Examples" package on TI's web site
  9. You do not need to add code. The documentation for endTransmission() says: // Originally, 'endTransmission' was an f(void) function. // It has been modified to take one parameter indicating // whether or not a STOP should be performed on the bus. // Calling endTransmission(false) allows a sketch to // perform a repeated start.
  10. Huh? All MSP430 comparator modules are able to raise an interrupt for this.
  11. Many MSP430 models have a comparator. You can find out whether this is the case for your specific model (whatever it is) by looking into the datasheet.
  12. Already answered on E2E.
  13. If you have configured the compiler correctly, i.e., for the G2231, these two headers have exactly the same effect.
  14. Toggling the PxIES bit once has a race condition, when the signal switches again before the interrupt has run. You also have to check the current state of the PxIN bit to ensure that PxIES catches the next edge. But the easiest way to get interrupts for both edges is to route the signal to two pins.
  15. There is no flyback diode in this device. All MOSFETS have a parasitic body diode, but it is no help for you because it is across the source/drain channel, not across the relay. The NXP's BSS138 model has ESD diodes that protect the gate insulation, but again, these does not help you. You cannot avoid putting a separate diode across the relay.