In the following code I am trying to display clock time, which I get using other functions.
While calling this function from main I am passing addresses in hexadecimal form to this function, and I want to print the time, but it is not printing correctly.
void DS1307_GetTime(unsigned char *h_ptr, unsigned char *m_ptr, unsigned char *s_ptr)
{
I2C_Start(); // Start I2C communication
DS1307_Write(DS1307_ID); // connect to DS1307 by sending its ID on I2c Bus
DS1307_Write(SEC_ADDRESS); // Request Sec RAM address at 00H
I2C_Stop(); // Stop I2C communication after selecting Sec Register
I2C_Start(); // Start I2C communication
DS1307_Write(0xD1); // connect to DS1307( under Read mode) by sending its ID on I2c Bus
*s_ptr = DS1307_Read(); I2C_Ack(); // read second and return Positive ACK
*m_ptr = DS1307_Read(); I2C_Ack(); // read minute and return Positive ACK
*h_ptr = DS1307_Read(); I2C_NoAck(); // read hour and return Negative/No ACK
*s_ptr = bcd_to_dec(*s_ptr);
*m_ptr = bcd_to_dec(*m_ptr);
*h_ptr = bcd_to_dec(*h_ptr);
printf("Time is in ss:mm:hh = %u:%u:%u\n", s_ptr, m_ptr, h_ptr);
I2C_Stop(); // Stop I2C communication after reading the Time
}
I think my problem is in my pointer declaration or printf statement, but I can't figure out exactly what the problem is.
You need to dereference the pointers in printf. Right now you're printing the pointer values (i.e. addresses) of s_ptr, m_ptr, and h_ptr.
printf("Time is in ss:mm:hh = %u:%u:%u\n", *s_ptr, *m_ptr, *h_ptr);
(This is, of course, assuming your other internal time generating functions are working as intended)
Related
Please help! I am using FSMC to connect a STM32F407 MCU with AD7606 to sample voltage value. MCU would send sampled values to PC using USB HS port after 1024 conversions. But when I inspect the values from PC, I found that readings from channel 0 occasionally contains data from other channels. For example, if connect channel 0 to 5v, connect channel 8 to 3.3v, connect other channels to ground. Then the printed value from channel 0 would contain 5v, 0v, 3.3v. The basic setup is as follows:
A 200KHZ PWM single is generated by TIM10 to act as CONVST signal for AD7606.
7606 will then issue a BUSY signal which I used as an external interrupt source.
In the Interrupt handler, An DMA request would be issued to read 8 16bit data
from FSMC address space to memory space. TIM10 PWM would be stopped if 1024
conversions has been done.
In the DMA XFER_CPLT call back, if 1024 conversions has been done, the converted
data would be sent out by USB HS port, and TIM10 PWM would be enabled again.
Some code blocks:
void HAL_GPIO_EXTI_Callback(uint16_t GPIO_Pin)
{
if(GPIO_Pin == GPIO_PIN_7)
{
// DMA data from FSMC to memory
HAL_DMA_Start_IT(&hdma_memtomem_dma2_stream0, 0x6C000000, (uint32_t)(adc_data + adc_data_idx) , 8);
adc_data_idx += 8;
if (adc_data_idx >= ADC_DATA_SIZE)
HAL_TIM_PWM_Stop(&htim10, TIM_CHANNEL_1);
}
}
void dma_done(DMA_HandleTypeDef *_hdma)
{
int i;
int ret;
// adc_data[adc_data_idx] would always contain data from
// channel 1, led1 wouldn't light if every thing is fine.
if (adc_data[adc_data_idx] < 0x7f00 )
HAL_GPIO_WritePin(led1_GPIO_Port, led1_Pin, GPIO_PIN_SET);
if (adc_data_idx >= ADC_DATA_SIZE)
{
if(hUsbDeviceHS.dev_state == USBD_STATE_CONFIGURED)
{
// if I don't call CDC_Transmit_HS, everything is fine.
ret = CDC_Transmit_HS((uint8_t *)(adc_data), ADC_DATA_SIZE * 2 );
if (ret != USBD_OK)
{
HAL_GPIO_WritePin(led1_GPIO_Port, led2_Pin, GPIO_PIN_SET);
}
}
adc_data_idx = 0;
HAL_TIM_PWM_Start(&htim10, TIM_CHANNEL_1);
}
}
It seems that a single USB transaction would take longer than 5us(one conversion time), so I stopped PWM signal to stop conversion...
If I only send the second half of the data buffer, there is no data mixture. It's very strange.
According to your description, I think the processing is correct, and the problem is at the CDC_Transmit_HS(); I have met the problem on the CDC_Transmit_FS(), which can't transmit more than 64 bytes data for original code, and need to modify some code, otherwise the some error occurs. Did you check the number of received data is correct?
Reference:
I can't receive more than 64 bytes on custom USB CDC class based STM32 device
I'm not sure your ADC_DATA_SIZE size; if it's larger than 64 bytes, maybe you can modify to smaller than 64 bytes and try again and check whether or not the data is correct. I am not sure if it is affected by this problem, but I think you can give it a try.
On the other hand, it may also be necessary to GND the ADC IN pins not used by AD7606 to avoid interference between channels.
Or you can try other communication (I2C, SPI, UART...etc) to send the data.
If there is no problem with other communication methods, there is a high chance that it is a problem with CDC_Transmit_HS(). If there are problems with other transmission methods, you may have to check whether there is a conflict between the ADC conversion time or the transmission time.
I am writing a C program on Eclipse to communicate from my ARM Cortex M4-F microcontroller in I2C with its master, another MCU.
In my I2C library, I use a static global variable to store all the parameters of the communication (address, lenghts, data buffers). The issue is that a part (an array containing the data to be transmitted, which are 8 bits integers) of this variable gets modified when the interrupt (Start condition followed by the slave's address on the I2C bus) happens, even before executing the code I put the handler. It gets assigned to 8, whatever the initial value.
I tried to put breakpoints basically everywhere, and a watchpoint on the variable, the changes arises seemingly from nowhere, not in the while loop, and before the call to my_I2C_Handler(), so the interrupt is the cause apparently.
I also tried setting the variable as volatile, but that changed nothing.
I noticed one interesting thing: putting a printf of the array's data during my_I2C_Init() or my_SlaveAsync(), like so:
printf("%d\n", req.tx_data[0]);
corrects this problem, but why? I want to remove all prints after debugging.
#include <stdint.h>
#include "my_i2c.h"
void I2C1_IRQHandler(void)
{
printf("\nI2C Interrupt\n");
my_I2C_Handler(MXC_I2C1); // MXC_I2C1 is a macro for the registry used
}
int main(void)
{
int error = 0;
printf("\nStarting I2C debugging\n");
// Setup the I2C
my_I2C_Shutdown(MXC_I2C1);
my_I2C_Init(MXC_I2C1);
NVIC_EnableIRQ(I2C1_IRQn); // Enable interrupt
my_I2C_SlaveAsync(MXC_I2C1); // Prepare to receive communication
while (1)
{
LED_On(0);
LED_Off(0);
}
printf("\nDone testing\n");
return 0;
}
The structure of the request containing the parameters of the communication is like this:
typedef struct i2c_req i2c_req_t;
struct i2c_req {
uint8_t addr; // I2C 7-bit Address
unsigned tx_len; // Length of tx data
unsigned rx_len; // Length of rx
unsigned tx_num; // Number of tx bytes sent
unsigned rx_num; // Number of rx bytes sent
uint8_t *tx_data; // Data for mater write/slave read
uint8_t *rx_data; // Data for master read/slave write
};
Is declared like so in the beginning of the file:
static i2c_req_t req;
and assigned this way in my_I2C_Init():
uint8_t rx[1] = {0};
uint8_t tx[1] = {12};
req.addr = 0xAA;
req.tx_data = tx;
req.tx_len = 1;
req.rx_data = rx;
req.rx_len = 1;
req.tx_num = 0;
req.rx_num = 0;
Many thanks for your help
I am working on a project in C on the raspberry pi 2 in which the pi is polling a microcontroller via SPI when the microcontroller asserts a particular pin.
There are two functions that are intended to be executed in this fashion. One of the functions - LNK_pollNetwork() - checks to see if the request pin is high and - if it is - then it downloads the data until the pin is low again, then parses. The other function - LNK_generateNetStat() - sends a byte requesting the network status and then downloads data until the pin is low again.
It seems that if I place a 'printf' statement just after the poll byte in LNK_generateNetStat(), everything works fine. If I remove the printf statement, then the program goes haywire and it is clear to me that the other function is executing almost in parallel with this function.
Both functions are on the same thread... or so I believe.
void LNK_generateNetStat(){
uint8_t statusSerialString[(NETSTAT_HEADER_BYTES
+ (MAX_NUM_OF_NODES
* NETSTAT_FIELD_WIDTH_BYTES))];
uint8_t i = 0;
SPI_transfer(0x86);
/* if this printf is executed, all works normally */
if(verbose)
printf("Network status polled");
while(bcm2835_gpio_lev(REQ_PIN) == HIGH){
statusSerialString[i] = SPI_transfer(0xfe);
i++;
}
/* parsing code below this line */
/* ... */
}
The other function simply polls the request pin and, if it is high, then starts pulling data until the pin is low:
void LNK_pollNetwork(){
if(bcm2835_gpio_lev(REQ_PIN) == HIGH){
int i = 0;
uint8_t payload[PAYLOAD_MAX_LENGTH];
SPI_transfer(0xff); // dummy read - allows slave to load the buffer
while(bcm2835_gpio_lev(REQ_PIN) == HIGH){
payload[i] = SPI_transfer(0xff);
i++;
}
/* payload parsing below this line */
/* ... */
}
}
Both of these should be executed sequentially. There is a higher level task manager that executes LNK_pollNetwork() every 1ms and LNK_generateNetStat() every 1250ms.
I know that LNK_generateNetStat() is being pre-empted because I have used different values in the SPI polling routine for each function in order to identify what is going on. The 0x86 executes normally and should begin polling with bytes numbered 0xfe, but I am seeing 0xff bytes in many cases and - sometimes - they are intermixed. I'm using a logic analyzer to observe.
Thoughts?
Trying to read the PS1 values. But as im running the following code it keeps saying on "chip_stat" that its suspended.
main (void){
init(); // Configuration initialization
si1141_init(); // Si1141 sensor initialization
__delay_ms(30); // Delay to ensure Si1141 is completely booted, must be atleast 25ms
si1141_WriteToRegister(REG_IRQ_STATUS, 0xFF); // Clear interrupt source
signed int status;
while(1){
WriteToI2C(0x5A<<1); // Slave address
PutByteI2C(0x30); // chip_stat
ReadFromI2C(0x5A<<1); // Slave address
if((status = GetByteI2C(0x30)) == Sw_I2C_ERROR) // chip_stat
{
return Sw_I2C_ERROR;
}
Stop_I2C();
status++;;
}
}
The code im using to read the PS1 values is the following. Im reading the value 16705. Which keeps being the same on all measurements.
The value should go up and down from 0 - 32767, as it measures more or less movement.
signed int si1141_ReadFromRegister(unsigned char reg){
signed int data;
WriteToI2C(0x5A<<1); // Slave address
ReadFromI2C(0x5A<<1); // Slave address
if((data = GetByteI2C(Sw_I2C_LAST)) == Sw_I2C_ERROR)
{
return Sw_I2C_ERROR;
}
Stop_I2C();
return data;
}
main (void){
init(); // Configuration initialization
si1141_init(); // Si1141 sensor initialization
__delay_ms(30); // Delay to ensure Si1141 is completely booted, must be atleast 25ms
si1141_WriteToRegister(REG_IRQ_STATUS, 0xFF); // Clear interrupt source
signed int PS1;
while(1){
PS1 = si1141_ReadFromRegister(REG_PS1_DATA0) + (256 * si1141_ReadFromRegister(REG_PS1_DATA1)); // Proximity CH1
}
}
I linked the files for the i2c communication.
https://www.dropbox.com/s/q41vw444gjvj0qa/swi2c.c?dl=0
https://www.dropbox.com/s/1mshyz88o15hz8c/swi2c.h?dl=0
Rule out I2C errors first. Your software I2C library is no help at all.
Make sure you read registers PART_ID, REV_ID, SEQ_ED first and that the values match the data sheet resp. your expected values. This is to rule out I2C errors.
You have to take quite a few steps to get a single reading to get started.
Reset the Si114x. Program the HW_KEY. Program PS_LED21 to a sensible value. The ANs tell you how. Do not program a higher value than what your components can handle and what your design can support. This might destroy something if done incorrectly. Do not get any funny ideas about PS_ADC_GAIN either, or you will fry your device. Read the AN. Do not program PS_ADC_GAIN at this point.
Clear PSLED21_SELECT -- only PS2_LED, keep PS1_LED set for LED1, obviously -- and PSLED3_SELECT. This is probably optional, but the datasheet tells you to do it, so do it.
Next, program CH_LIST to PS1_EN, then send a PS_FORCE command.** Now read PS1 data from PS1_DATA0 and PS1_DATA1. Done.
It may be easier to test with ALS first to rule out saturating your sensor with some stray infrared (think setting sun as you work through the night).
** For the command protocol, you have to implement the command/response protocol laid out in the datasheet. I suggest you test with reset and nop first to verify your code.
I'm facing a weird issue. I've always used bit bangin I2C functions on my PIC16F1459, but now I want to use the MSSP (SPI,I2C Master Slave Peripheral). So I've started writing the functions according to the datasheet, Start, Stop, etc. The problem I have is my PIC won't ACK the data I send to the I2C EEPROM. It clearly says in the datasheet that the ACK status can be found at SSPCON2.ACKSTAT. So my guess was to poll this bit until the slave responds to my data, but the program hangs in the while Loop.
void vReadACK (void)
{
while (SSPCON2.ACKSTAT != 0);
}
And here's my write function, my I2CCheck function and I2C Master Initialization function
void vI2CEcrireOctet (UC ucData, UC ucRW)
{
vI2CCheck();
switch (ucRW)
{
case READ:
SSPBUF = ucData + 1;
break;
case WRITE:
SSPBUF = ucData + 0;
break;
}
vReadACK();
}
void vI2CCheck (void)
{
while (SSPCON2.ACKEN); //ACKEN not cleared, wait
while (SSPCON2.RCEN); //RCEN not cleared, wait
while (SSPCON2.PEN); //STOP not cleared, wait
while (SSPCON2.SEN); //Start not cleared, wait
while (SSPCON2.RSEN); //Rep start not cleared, wait
while (SSP1STAT.R_NOT_W); //TX not done wait
}
void vInitI2CMaster (void)
{
TRISB4_bit = 1; //SDA IN
TRISB6_bit = 1; //SCL IN
SSP1STAT.SMP = 1; //No slew rate
SSP1STAT.CKE = 0; //Disable SMBus inputs
SSPADD = 0x27; //100 KHz
SSPCON1 = 0b00101000; //I2C Master mode
SSPCON3 = 0b00000000; //Rien de slave
}
Just so you know, 24LC32A WriteProtect tied to VSS, A2-A1-A0 tied to GND, so adress 0xA0. 4k7 pull-ups are on I2C line. PIC16F1459 at 16MHz INTOSC.
I'm completely stuck. I've went through the MSSP datasheet 5 to 6 times without finding any issue. Can you guys help?
And here's my logic analyzer preview (removing the while inside vReadAck() )
Well it looks like I've found the answer to my question. What I was doing was the exact way of doing this. The problem seemed to be the Bus Free Time delay required for the slave to respond. At 16Mhz, my I2C was probably too fast for the EEPROM memory. So I've added a small Delay function right after the stop operation, so the write sequences are delayed and BAM, worked.
Bus free time: Time the bus
must be free before a new
transmission can start.
Despite the fact you "totally know" know "PIC won't ACK the data I send to the I2C EEPROM" because it's not supposed to, you still seem to misunderstand how I2C acknowledgements are supposed to work. They're called acknowledgements because they can be both positively (ACK) and negatively (NAK) acknowledged. If you look at the the analyzer screen shot you posted you'll find that its quite clearly labelled each byte being sent as having been NAK'ed by the transmitter.
To properly check for I2C ACKs you should be polling the trailing edge of the ACKTIM bit, and then checking the ACKSTAT bit to find out whether the slave transmitted an ACK or a NAK bit. Something like this:
int
vReadACK() {
while(!SSPCON3.ACKTIM);
while(SSPCON3.ACKTIM);
return SSPCON2.ACKSTAT;
}
As for why your slaved device is apparently NAKing each byte it isn't clear from the code you've posted, but there's a couple of notable omissions from your code. You need to generate start and stop conditions but you've shown no code to do this.