[esaulenka 5]

6 hours ago, jenya7 said:

это не ошибка. при AUTOMATIC RETRANSMITTION у меня шина засирается нипадецки.

Для надёжности надо провода перерезать, чтоб уж точно ничего не засиралось.

Нормально функционирующий CAN-передатчик с установленным флажком auto retransmit передаёт в шину ровно ОДНО сообщение, получает подтверждение и замолкает, пока его не попросят передать что-то ещё. Пока нет этого банального понимания функционирования шины (и механизма разрешения коллизий в этой самой шине), разговаривать дальше смысла немного...

[jenya7 0]

1 hour ago, esaulenka said:

Для надёжности надо провода перерезать, чтоб уж точно ничего не засиралось.

Нормально функционирующий CAN-передатчик с установленным флажком auto retransmit передаёт в шину ровно ОДНО сообщение, получает подтверждение и замолкает, пока его не попросят передать что-то ещё. Пока нет этого банального понимания функционирования шины (и механизма разрешения коллизий в этой самой шине), разговаривать дальше смысла немного...

а если не получает подтверждение?

[adnega 10]

6 минут назад, jenya7 сказал:

а если не получает подтверждение?

Значит кто-то другой с более высоким приоритетом начал передачу, а ваш узел потерял арбитраж.

Это не страшно, т.к. тот узел успешно все передаст, а ваш должен повторить попытку в следующее освобождение шины.

Большая беда возможна лишь когда два узла передают с одним и тем же ID.

[jenya7 0]

1 hour ago, adnega said:

Значит кто-то другой с более высоким приоритетом начал передачу, а ваш узел потерял арбитраж.

Это не страшно, т.к. тот узел успешно все передаст, а ваш должен повторить попытку в следующее освобождение шины.

Большая беда возможна лишь когда два узла передают с одним и тем же ID.

я смотрел на скопе. мастер если не получил подтверждение шлет без остановки с установленным  auto retransmit.

[adnega 10]

47 минут назад, jenya7 сказал:

я смотрел на скопе. мастер если не получил подтверждение шлет без остановки с установленным  auto retransmit.

Если подтверждение это ACK-бит, то все верно - должен слать сплошняком.

Но если на шине есть хоть одно устройство, то оно выставит ACK-бит и ретрансмит остановится.

[jenya7 0]

вобщем решил для начала поставить терминатор с другого конца. и все. нет пропусков. день гонял.

есть куча алгоритмических ляпов. но это уже другая история :)

[jenya7 0]

Вот какая проблема.

Мастер посылает слейву запрос и ждет ответ от него. Если в течении определенного времени не приходит ответ - мастер вполне резонно решает что связи со слейвом нет и выдает ошибку.

uint32_t MASTER_GetRunTimeParams(uint32_t mot_idx)
{   
    if (motor_rt_params[mot_idx].ena == 0)
        return MOT_NONE;
    else
    {
        //send request
        CAN_TX(motor_rt_params[mot_idx].mot_id, MASTER_COM_GET_ALL, master_data, 0);
        
        master_time_stamp = TIM_GetTimeStamp_ms(TIM6);
        slave_timeout = master_time_stamp + SLAVE_TIMEOUT_RESPONSE;
        
        master_ack = 0;
                
        while (master_ack == 0)
        {
            master_ack = CAN_RX_Master();
                
            if (master_ack) //we got response from a slave
            {
                return MOT_PASS;              
            }
            else  //no response
            {
                master_time_stamp =  TIM_GetTimeStamp_ms(TIM6);
                if (master_time_stamp > slave_timeout)
                    return MOT_FAIL;
            }     
        }      
    }
    
    return MOT_FAIL;
}

сколько времени требуется на запрос -ответ? 100 мили? 200 мили? однако если я ставлю  SLAVE_TIMEOUT_RESPONSE меньше 4000 я попадаю в условие master_time_stamp > slave_timeout и return MOT_FAIL;

этого не может быть так как я вижу постоянное обновление данных а не каждые 4 секунды. очевидно проблема в коде но не могу понять где я косячу.

Изменено 20 июня, 2019 пользователем jenya7

[adnega 10]

А

TIM_GetTimeStamp_ms

не переполняется?

[jenya7 0]

1 hour ago, adnega said:

А

TIM_GetTimeStamp_ms

не переполняется?

счетчик таймера 32 бит

void TIM6_DAC_IRQHandler (void)
{
    added_val += 0xFFFF;
    
    TIM6->SR = (uint16_t)~TIM_IT_Update;
}

uint32_t TIM_GetTimeStamp_us(TIM_TypeDef * TIMx)
{
    return (TIMx->CNT + added_val) / 10;
}

ой. счетчик то 16 бит.

 

тогда надо так

static uint32_t timer_counter = 0;
static uint32_t added_val = 0;

uint32_t TIM_GetTimeStamp_ms(TIM_TypeDef * TIMx)
{
    uint16_t time_stamp = TIMx->CNT;
    
    timer_counter = (time_stamp + added_val) / 10;
    
    return timer_counter;
}

 

 

 

 

Изменено 20 июня, 2019 пользователем jenya7

[jenya7 0]

Что то не все слава богу с таймаутом по времени. пришлось переделать.

uint32_t MASTER_GetRunTimeParams(uint32_t mot_idx)
{   
    if (motor_rt_params[mot_idx].ena == 0)
        return RES_MOT_NONE;
    else
    {
        //send request
        CAN_TX(motor_rt_params[mot_idx].mot_id, MASTER_COM_GET_ALL, master_data, 0);
        
        no_ack = 0;
        
        master_ack = 0;
                
        while (master_ack == 0)
        {
            //here the motor parameters updated
            master_ack = CAN_RX_Master();
                
            //we got response from a slave
            if (master_ack) 
            {
                no_ack = 0;
                return MOT_PASS;              
            }
            else  //no response
            {          
                no_ack++;
                if (no_ack > MAX_NACK_TIMES)
                    return MOT_FAIL;
            }     
        }      
    }
    
    return MOT_FAIL;
}

так хоть MAX_NACK_TIMES можно настроить нормально.

Изменено 23 июня, 2019 пользователем jenya7