Добрый день, есть функция чтение температуры из термодатчика Lm75ad во время ожидания ожидания флага передаю управления другому процессу portYIELD(); Так вот если замкнуть линии I2C то процесс чтения температуры зависает, а остальное все работает. Так вот как по феншую сделать отработку зависания ? Пока только одна идея перед каждый ожидание засекать время, и в диспетчере смотреть больше оно таймаута или нет, но мне это не нравиться тем что это надо прятать в дефайны, что не айс, или код "загромождать". Если другие способы определения ?


uint8_t OS_Lm75ad_Read(short unsigned int* dataout,const unsigned char addr){
static short unsigned int tmp[2];
static short unsigned int* dataout_temp;
//------------------------------------------------------------------------------------
LED_DEBUG_ON
dataout_temp=dataout;
while(I2C_GetFlagStatus(I2C_LM75AD, I2C_FLAG_BUSY)){portYIELD();};
LED_DEBUG_OFF
//------------------------------------------------------------------------------------
I2C_GenerateSTART(I2C_LM75AD, ENABLE);
/* check start bit flag */
while(!I2C_CheckEvent(I2C_LM75AD, I2C_EVENT_MASTER_MODE_SELECT)){portYIELD();};
LED_DEBUG_ON
//----------------------SEND_ADDR_Write-------------------------------------------------------
I2C_Send7bitAddress(I2C_LM75AD,(addr), I2C_Direction_Transmitter);
while(!I2C_CheckEvent(I2C_LM75AD, I2C_EVENT_MASTER_TRANSMITTER_MODE_SELECTED)){portYIELD();};
//----------------------POINT------------------------------------------------------------------
I2C_SendData(I2C_LM75AD,LM75AD_ADDR_REG_Temp); //Регист Temp(температура)
while(!I2C_CheckEvent(I2C_LM75AD, I2C_EVENT_MASTER_BYTE_TRANSMITTED)){portYIELD();};
LED_DEBUG_ON
//----------------------RE-START-------------------------------------------------------------------
I2C_GenerateSTART(I2C_LM75AD, ENABLE);
/* check start bit flag */
while(!I2C_CheckEvent(I2C_LM75AD, I2C_EVENT_MASTER_MODE_SELECT)){portYIELD();};
LED_DEBUG_OFF
//-------------------Send_addr_read------------------------------------------------------
I2C_Send7bitAddress(I2C_LM75AD, (addr), I2C_Direction_Receiver);
while(!I2C_CheckEvent(I2C_LM75AD, I2C_EVENT_MASTER_RECEIVER_MODE_SELECTED)){portYIELD();};
LED_DEBUG_ON
//------------------------------------------------------------------------------------------
while(!I2C_CheckEvent(I2C_LM75AD, I2C_EVENT_MASTER_BYTE_RECEIVED)){portYIELD();};
LED_DEBUG_OFF
tmp[0]=I2C_ReceiveData(I2C_LM75AD);
//------------------------------------------------------------------------------------------
while(!I2C_CheckEvent(I2C_LM75AD, I2C_EVENT_MASTER_BYTE_RECEIVED)){portYIELD();};
LED_DEBUG_ON
tmp[1]=I2C_ReceiveData(I2C_LM75AD);
//------------------------------------------------------------------------------------------
I2C_GenerateSTOP(I2C_LM75AD, ENABLE);
/*stop bit flag*/
I2C_AcknowledgeConfig(I2C_LM75AD, ENABLE);
while(I2C_GetFlagStatus(I2C_LM75AD, I2C_FLAG_BUSY)){portYIELD();};
LED_DEBUG_OFF
//------------------------------------------------------------------------------------------
*dataout_temp=(tmp[0]<<8)|tmp[1];
NOP;NOP;NOP;NOP;NOP;
LED_DEBUG_ON
//------------------------------------------------------------------------------------------
}

Cчeтчик с условием таймаута можно запрятать в функцию portYIELD, возвращать 0, если надо продолжать попытки, или не 0 если таймаут. Вызывать, например, так:

while ( !(!I2C_GetFlagStatus(I2C_LM75AD, I2C_FLAG_BUSY) || portYIELD()) );
//Если I2C_GetFlagStatus вернет 1, будет вызываться portYIELD. Цикл будет повторяться, пока portYIELD возвращает 0.

while( !(I2C_CheckEvent(I2C_LM75AD, I2C_EVENT_MASTER_MODE_SELECT) || portYIELD()) );
//Если I2C_CheckEvent вернет 0, будет вызываться portYIELD. Цикл будет повторяться, пока portYIELD возвращает 0.

А где перезапустить счетчик ? Что бы для последующих ожиданий флагов был новый отсчет таймаута.

B начале функции чтения температуры, чтобы после появления неисправности остальные циклы не выполнялись. А в конце функции проверять был ли достигнут таймаут, т.е. наличие неисправности.

firew0rker, спасибо за помощь примерно то что я и хотел.

Только теперь возникла другая проблема, как можно повторно узнать о наличии аварии точнее о переходе из аварии в норму ?

Дело вот в чем, помимо термодатчика на I2C у меня еще подключен LCD через расширитель порта(только линия DATA), управляющие выводы идут напрямую от процессора, так вот в момент замыкания происходит следующее:
1) в момент замыкания (при маленьком таймауте 2-5ms) на расширитель идет полная фигня, по этому он выдает на выходе нули т.е на LCD приходит Data=0,а так как управляющие выводы работают от процессора то LCD их и принимает, и выводит "корябозябру".

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

PS: Флаг BERR и BUSY не помогают. BUSY ставиться только при замыкании на ноль, а BERR вообше не разу не выставился сколько бы не замыкал линию.

BERR – ошибка шины. Устанавливается при обнаружении сигнала start или stop в ”неуместном” месте. Для сброса BERR необходимо записать в него 0.

Подключите линию Е через расширитель. При КЗ на линии Е будет 0 и ЖКИ не среагирует.

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

"Подключите линию Е через расширитель. При КЗ на линии Е будет 0 и ЖКИ не среагирует."
Все линии там уже заняты. =(

Повторный опрос это только с датчиком =(

Если ваш ЖК-модуль на основе контроллера HD44780, то в DDRAM символы с кодами 00...07 - это переопределяемые символы. При инициализации занулите их, т. е. сделайте пробелами, чтобы при получении кода 0 выводился пробел а не крякозабра.

Что надо обнаруживать: наличие и исправность датчика, или КЗ на I2C?

так и есть в 0 ячейка стоит символ градуса, по нему и сужу что там 0 на дате приходит =))


Что бы вся периферия на I2C работала гарантированно и после КЗ что бы нечего не зависало, и в случае какой либо помехи,её не было заметно.
Но вообще хочу сделать по полной и наличие датчиков на линии тоже, и в случае выхода одного из строя что бы все остальное работало.
(над последним пока ещё думаю как это сделать,пока останавливаюсь на том что, если много раз зависал в одной функции то перейти на более медленный опрос этой функции раз в 10 секунд, или вообще выключить её опрос)

(1) если датчик закоротит одну из линий I2C - то естественно, "ляжет" вся шина. И с этим ничего не сделаешь.
Шина I2C - внутрисхемный интерфейс, и если датчик висит на проводе более 10 см - готовьтесь к проблемам.
Чтоб ОНО таки работало, проверьте подтягивающие резисторы I2C. Они должны быть (для надежной рабты периферии, в соотв-ии с миним. требованиями стандарта)
R = 4.7 ... 10 кОм. ОНО будет, конечно, работать и на 100к, но помехоустойчивать будет приближаться к 0.
Снижать вниз R нельзя, можно попалить выходные узлы как мастера, так и слейвов.
Экранируйте провод линии - если они внешние для прибора.
Для работы с длинной внешней шиной I2C есть спец. микросхемы-драйверы.
(2)
не используйте

лучше так

Завесы при работе с периферией I2C вполне возможны. slave может войти в "ступор" (ожидание) и ваш софт получит коллизию - навечно, до второго пришествия
Reset. Вывести шину из этого состояния софтово можно принудительной подачей 9 clk (узел I2C отключить. ногодрыг SCK)

Вообще, если что-то не работает или "глючит" - 99 проц. - вина аффтара софта и железа
Не устраняйте последствия, найдите и устраните причину сбойной работы.

Согласна с написанным k155la3 и ещё добавлю: чтобы освободить шину от зависшего slave, может быть мало 9 импульсов CLK (a может быть и много). Лучше после каждого проверять уровень на линии (slave отпустил — хватит дёргать). И ещё несколько раз сформировать СТОП-условие на шине.
Можно предусмотреть сброс всех, или только глючных устройств шины по питанию. Если у них есть вход "reset", то дергать им, если нет - то подавать питание через ключ и выключать его при зависании.

Т.е. - заменить автора?

С этим понятно я имел ввиду то что он по адресу не будет отвечать.

Да да автор виноват ибо нефиг пинцетом в шину тыкать, да на землю и питание её замыкать.

Клоки есть, но надо ещё сделать проверку уровня на линии после клока как посоветовал firew0rker.

Нет. Пока мы тут "бухтим как косм. корабли бороздят Большой Театр" ОН должен "расти на собой".
Это не к ТС или к кому либо


При холодном старте
1. Проверка на "залипший" слейв. Если залипло - попытка сброса залипа. Если неудачно - LCD_Display("I2C fault", __LINE__);
2. Проверки на наличие и исправность всх имеющихся на шине slave

3. Надежность работы конечно зависит от типа-марки-произовдителя slave. Мне пока достаточно I2C_SlaveIsConnect( ADDR )
так как небыло необходимости.
4. Таймауты готовности slave (в смысле его внутреннего состояния). К примеру если это EEPROM в том или ином виде - то надо при последоватьельной записи
потока данных выдерживать таймауты, пока в EEPROM пройдут внутренние операции (собственно запись). В вашем случае - время оцифровки. Пред любой операцией
- читать регистры статуса напредмет готовности.

ps - "Так вот если замкнуть линии I2C то процесс чтения температуры зависает, ... "
Это понятно, на шине любое изменение (фронт, спад) отслеживается автоматами как master так и slave.
Можно завесить все - если при этом вошел в коллизию (фактически из-за помехи) автомат master-а, или "зависнет" какой либо слейв - ожидая неизвестно чего,
напр. после ложного "старта".
Проверяйте HW - если глючек в нем, то копаться в софте бессмыслено.