MSP430 I2C read multiple bytes communication problem - c

I'm trying to use a temperature sensor(PCT2075) by MSP430F249
To get a temperature, I get a 2bytes from this sensor.
I wrote a code from this link.
https://e2e.ti.com/support/microcontrollers/msp430/f/166/t/589712?MSP430FR5969-Read-multiple-bytes-of-data-i2c-with-repeated-start-and-without-interrupts
I'm using MSP430F249. so I modified a code from this link.
Howerver, I got just two same value. I think that it is MSByte.
Is there any way to get 2bytes from sensor.
my code here
void i2c_read_multi(uint8_t slv_addr, uint8_t reg_addr, uint8_t l, uint8_t *arr)
{
uint8_t i;
while(UCB0STAT & UCBBUSY);
UCB0I2CSA = slv_addr; // set slave address
UCB0CTL1 |= UCTR | UCTXSTT; // transmitter mode and START condition.
while(UCB0CTL1 & UCTXSTT);
UCB0TXBUF = reg_addr;
while(!(UCB0CTL1 & UCTXSTT));
UCB0CTL1 &= ~UCTR; // receiver mode
UCB0CTL1 |= UCTXSTT; // START condition
while(UCB0CTL1 & UCTXSTT); // make sure start has been cleared
for (i = 0; i < l; i++) {
while(!(IFG2 & UCB0RXIFG));
if(i == l - 1){
UCB0CTL1 |= UCTXSTP; // STOP condition
}
arr[i] = UCB0RXBUF;
}
while(UCB0CTL1 & UCTXSTP);
}

There are two issues ...
The linked to code assumes that the port only needs to read one byte for each output value.
But, based on the sensor documentation you've shown, for each value output to the array, we need to read two bytes (one for MSB and one for LSB).
And, we need to merge those two byte values into one 16 bit value. Note that arr is now uint16_t instead of uint8_t. And, l is now the number of [16 bit] samples (vs. number of bytes). So, the caller of this may need to be adjusted accordingly.
Further, note that we have to "ignore" the lower 5 bits of lsb. We do that by shifting the 16 bit value right by 5 bits (e.g. val16 >>= 5). I assume that's the correct way to do it. Or, it could be just val16 &= ~0x1F [less likely]. You may have to experiment a bit.
Here's the refactored code.
Note that this assumes the data arrives in "big endian" order [based on my best guess]. If it's actually little endian, reverse the msb = and lsb = statements.
Also, the placement of the "STOP" condition code may need to be adjusted. I had to guess as to whether it should be placed above the LSB read or MSB read.
I chose LSB--the last byte because that's closest to how the linked general i2c read is done. (i.e.) i2c doesn't know about or care about the MSB/LSB multiplexing of the device in question. It wants the STOP just before the last byte [not the 16 bit sample].
void
i2c_read_multi(uint8_t slv_addr, uint8_t reg_addr, uint8_t l,
uint16_t *arr)
{
uint8_t i;
uint8_t msb;
uint8_t lsb;
uint16_t val16;
while (UCB0STAT & UCBBUSY);
// set slave address
UCB0I2CSA = slv_addr;
// transmitter mode and START condition.
UCB0CTL1 |= UCTR | UCTXSTT;
while (UCB0CTL1 & UCTXSTT);
UCB0TXBUF = reg_addr;
while (!(UCB0CTL1 & UCTXSTT));
// receiver mode
UCB0CTL1 &= ~UCTR;
// START condition
UCB0CTL1 |= UCTXSTT;
// make sure start has been cleared
while (UCB0CTL1 & UCTXSTT);
for (i = 0; i < l; i++) {
while (!(IFG2 & UCB0RXIFG));
msb = UCB0RXBUF;
while (!(IFG2 & UCB0RXIFG));
// STOP condition
if (i == l - 1) {
UCB0CTL1 |= UCTXSTP;
}
lsb = UCB0RXBUF;
val16 = msb;
val16 <<= 8;
val16 |= lsb;
// use only most 11 significant bits
// NOTE: this _may_ not be the correct way to scale the data
val16 >>= 5;
arr[i] = val16;
}
while (UCB0CTL1 & UCTXSTP);
}

Related

what would be the value stored after '&' operation

In the Code below
void I2C_Write(uint8_t v_i2cData_u8)
{
uint8_t i;
for(i=0;i<8;i++) // loop 8 times to send 1-byte of data
{
SDA_PIN = v_i2cData_u8 & 0x80; // Send Bit by Bit on SDA line
i2c_Clock(); // Generate Clock at SCL
v_i2cData_u8 = v_i2cData_u8<<1;// Bring the next bit to be transmitted to MSB position
}
i2c_Clock();
}
in the statement: SDA_PIN = v_i2cData_u8 & 0x80; it is told that data will be sent bit by bit,if data is sent bit by bit then what will be stored in SDA_PIN,will SDA_PIN have the value = 0x80 or 1?
SDA_PIN will be assigned either 0x80 (128) or 0 depending on the high order bit of v_i2cData_u8 in that loop. If you want to insure a 0x01 byte is written, you would need to do this:
SDA_PIN = (v_i2cData_u8 & 0x80) ? 1 : 0;

How to read/write into specific bits of a unsigned char

I want to read and write from/to an unsigned char according to the table below:
for example I have following variables:
unsigned char hsi_div = 0x01; /* HSI/2 */
unsigned char cpu_div = 0x05; /* Fmaster/32 */
I want to write hsi_div to bits 4,3 and cpu_div to bits 2,1,0 (imagine the whole char is named CLK_DIVR):
CLK_DIVR |= hsi_div << 4; //not correct!
CLK_DIVR |= cpu_div << 2; //not correct!
And lets say I want to read the register back to make sure I did it correct:
if( ((CLK_DIVR << 4) - 1) & hsi_div) ) { /* SET OK */ }
if( ((CLK_DIVR << 2) - 1) & cpu_div) ) { /* SET OK */ }
Is there something wrong with my bitwise operations!? I do not get correct behaviour.
I assume CLK_DIVR is a hardware peripheral register which should be qualified volatile. Such registers should be set up with as few writes as possible. You change all write-able bits, so just
CLK_DIVR = (uint8_t)((hsi_div << 3) | (cpu_div << 0));
Note using fixed width type. That makes mentioniong it is an 8 bit register unnecessary. According to the excerpt, the upper bits are read-only, so they are not changed when writing. The cast keeps the compiler from issuing a truncation warning which is one of the recommended warnings to always enable (included in -Wconversion for gcc).
The shift count is actually the bit the field starts (the LSbit). A shift count of 0 means "no shifting", so the shift-operator is not required. I still use it to clarify I meant the field starts at bit 0. Just let the compiler optimize, concentrate on writing maintainable code.
Note: Your code bit-or's whatever already is in the register. Bit-or can only set bits, but not clear them. Addiionally the shift counts were wrong.
Not sure, but if the excerpt is for an ARM Cortex-M CPU (STM32Fxxxx?), reducing external bus-cycles becomes more relevant, as the ARM can take quite some cycles for an access.
For the HSIDIV bit fields you want:
hw_register = (hw_register & 0x18) | (hsi_value & 0x03) << 0x03;
This will mask the value to 2 bits wide then shift to bit position 3 and 4.
The CPUDIV fields are:
hw_register = (hw_register & 0x7) | (cpu_value & 7);
Reading the register:
hsi_value = (hw_register & 0x18) >> 3;
cpu_value = hw_register & 0x07;
Just
CLK_DIVR |= hsi_div << 3;
CLK_DIVR |= cpu_div << 0;
Since hsi_div is a 2-digit binary, you have to move it three positions to skip the CPUDIV field. And the cpu_div is already at the end of the field.

Parallel Verilog CRC algorithm from C-like reference

I have a set of c-like snippets provided that describe a CRC algorithm, and this article that explains how to transform a serial implementation to parallel that I need to implement in Verilog.
I tried using multiple online code generators, both serial and parallel (although serial would not work in final solution), and also tried working with the article, but got no similar results to what these snippets generate.
I should say I'm more or less exclusively hardware engineer and my understanding of C is rudimentary. I also never worked with CRC other than straightforward shift register implementation. I can see the polynomial and initial value from what I have, but that is more or less it.
Serial implementation uses augmented message. Should I also create parallel one for 6 bits wider message and append zeros to it?
I do not understand too well how the final value crc6 is generated. CrcValue is generated using the CalcCrc function for the final zeros of augmented message, then its top bit is written to its place in crc6 and removed before feeding it to the function again. Why is that? When working the algorithm to get the matrices for the parallel implementation, I should probably take crc6 as my final result, not last value of CrcValue?
Regardless of how crc6 is obtained, in the snippet for CRC check only runs through the function. How does that work?
Here are the code snippets:
const unsigned crc6Polynom =0x03; // x**6 + x + 1
unsigned CalcCrc(unsigned crcValue, unsigned thisbit) {
unsigned m = crcValue & crc6Polynom;
while (m > 0) {
thisbit ^= (m & 1);
m >>= 1;
return (((thisbit << 6) | crcValue) >> 1);
}
}
// obtain CRC6 for sending (6 bit)
unsigned GetCrc(unsigned crcValue) {
unsigned crc6 = 0;
for (i = 0; i < 6; i++) {
crcValue = CalcCrc(crcValue, 0);
crc6 |= (crcValue & 0x20) | (crc6 >> 1);
crcValue &= 0x1F; // remove output bit
}
return (crc6);
}
// Calculate CRC6
unsigned crcValue = 0x3F;
for (i = 1; i < nDataBits; i++) { // Startbit excluded
unsigned thisBit = (unsigned)((telegram >> i) & 0x1);
crcValue = CalcCrc(crcValue, thisBit);
}
/* now send telegram + GetCrc(crcValue) */
// Check CRC6
unsigned crcValue = 0x3F;
for (i = 1; i < nDataBits+6; i++) { // No startbit, but with CRC
unsigned thisBit = (unsigned)((telegram >> i) & 0x1);
crcValue = CalcCrc(crcValue, thisBit);
}
if (crcValue != 0) { /* put error handler here */ }
Thanks in advance for any advice, I'm really stuck there.
xoring bits of the data stream can be done in parallel because only the least signficant bit is used for feedback (in this case), and the order of the data stream bit xor operations doesn't affect the result.
Whether the hardware would need a parallel version depends on how a data stream is handled. The hardware could calculate the CRC one bit at a time during transmission or reception. If the hardware is staged to work with 6 bit characters, then a parallel version would make sense.
Since the snippets use a right shift for the CRC, it would seem that data for each 6 bit character is transmitted and received least significant bit first, to allow for hardware that could calculate CRC 1 bit at a time as it's transmitted or received. After all 6 bit data characters are transmitted, then the 6 bit CRC is transmitted (also least significant bit first).
The snippets seem wrong. My guess at what they should be:
/* calculate crc6 1 bit at a time */
const unsigned crc6Polynom =0x43; /* x**6 + x + 1 */
unsigned CalcCrc(unsigned crcValue, unsigned thisbit) {
crcValue ^= thisbit;
if(crcValue&1)
crcValue ^= crc6Polynom;
crcValue >>= 1;
return crcValue;
}
Example for passing 6 bits at a time. A 64 by 6 bit table lookup could be used to replace the for loop.
/* calculate 6 bits at a time */
unsigned CalcCrc6(unsigned crcValue, unsigned sixbits) {
int i;
crcValue ^= sixbits;
for(i = 0; i < 6; i++){
if(crcValue&1)
crcValue ^= crc6Polynom;
crcValue >>= 1;
}
return crcValue;
}
Assume that telegram contains 31 bits, 1 start bit + 30 data bits (five 6 bit characters):
/* code to calculate crc 6 bits at a time: */
unsigned crcValue = 0x3F;
int i;
telegram >>= 1; /* skip start bit */
for (i = 0; i < 5; i++) {
crcValue = CalcCrc6(unsigned crcValue, telegram & 0x3f);
telegram >>= 6;
}

ADC LPC1768 simple

this is my code
#include "LPC17xx.h" // Device header
#include "GPIO_LPC17xx.h" // Keil::Device:GPIO
uint32_t voltag1 = 0 ;
uint32_t voltag2 = 0 ;
volatile uint32_t adstat;
int blink=1;
int main()
{
//Config timer
LPC_TIM1->MCR=2;
LPC_TIM1->MR0=20000000; //Match Resgister
LPC_TIM1->TCR=1;
LPC_TIM1->EMR = 0x00000030 ;
//Config ADC
LPC_PINCON->PINSEL1 |= (1 << 14) | (1 << 16); // connect pin to ADC
LPC_SC->PCONP |= ((1 << 12)); //enable power of ADC
LPC_ADC->ADCR = 0x06202001; //initialaze ADC
LPC_ADC->ADINTEN = 0x00000100; // global interup
NVIC_EnableIRQ(ADC_IRQn);
GPIO_SetDir(3,25,GPIO_DIR_OUTPUT);
while(1) {}
}
void ADC_IRQHandler(void)
{
adstat = LPC_ADC->ADSTAT; /* Read ADC clears interrupt */
blink++;
GPIO_PinWrite(3,25,blink%2);
voltag1 = (LPC_ADC->ADGDR >> 4) & 0xFFF;
//voltag2 = (LPC_ADC->ADDR1 >> 4) & 0xFFF;
}
when i use LPC_ADC->ADGDR it work fine but when i use LPC_ADC->ADDR1 its not working , why?
i used MAT for ADC interup
and when i use LPC_ADC->ADGDR everything works fine
but when i use LPC_ADC->ADDR1 for reading its not working and not change with MAT edge
There are way too many magic numbers in your code. Please use the corresponding defines for all those bits. This code is unreadable as is.
There is a wrong comment in your code, the interrupt flag for ADGDR is not cleared on ADSTAT read. Only a read of ADGDR clears it, and thats why your code does not work with ADDR1.
Had you used the definition to set ADINTEN, you might have spotted your error sooner. That flag is named ADGDINTEN and corresponds to the flag in ADGDR only.
You should enable IRQ of ch1 by:
LPC_ADC->ADINTEN = 1 << 1; //0x0002

Speed up code for serial protocols using bitbanging

I'm wondering if there are any particularly fast ways to read or write a serial protocol (such as SPI) using GPIO calls (bitbanging) on a microcontroller. What is fastest may be somewhat architecture-specific, but a smaller number of operations is likely to be faster on any architecture. It is fair to assume port read/write and any bitwise integer operations happen in a single cpu clock; compare and jump may be a few clocks.
For a simple example, think of writing a byte using conventional SPI, given a port (register) with bitmasks for serial clock, miso (input), mosi (output) pins. To output a 1 bit on the falling edge of the clock port |= CLOCK|OUTPUT; port &= ~CLOCK; and writing a byte would consist of doing this for every bit in that byte (outputting either 0 or 1), in a loop.
Something like this:
uint8_t data;
// for each bit, msb first
for (i = 7; i >= 0; i--)
{
if ((data >> i) & 0x01)
{
// set output pin to 1
port |= OUTPUT;
}
else
{
// set output pin to 0
port &= ~OUTPUT;
}
// strobe clock
port |= CLOCK;
port &= ~CLOCK;
}
Some optimizations of this are obvious, eg unroll loops.
Some optimizations may be not so obvious: is it possible to switch based on the byte to be written (or just a part of it), and so avoid shifting and masking every bit? How to make this branch free? How to take advantage of runs of zeros or ones? (In which case there is no need to change the output, just the clock) How about changing the output and clock in one operation?
An example that uses some of these tricks (change output and clock in one operation when possible, unroll loops, but not branch-free):
https://github.com/FastLED/FastLED/blob/master/fastspi_bitbang.h
SPI clocks the data every other edge. Including an edge of the clock with your data is probably faster (same OR but saves one assign)
port = CLOCK
for (i = 7; i >= 0; i--)
{
if ((data >> i) & 0x01)
{
// set output pin to 1
port |= OUTPUT | CLOCK;
}
else
{
// set output pin to 0
port &= OUTPUT;
port |= CLOCK;
}
// strobe clock
port &= ~CLOCK;
}

Resources