Печально, но %сабж%.
Вызов транзакции по I2C шине, например такой (взят из примера):
ebdat15_07I2C_PUT_DATA(pTransfer);
из обработчика событий в EAT приложении зависает, если устройство с заданным I2C адресом не ответило ACK-ом на SLA-R/W. Модем висит несколько секунд до самого ребута по вотчдогу.
Зависание происходит на втором по счету обращении, если на первое получен NACK, причем наличие ACK на втором обращении ни на что не влияет.
Прошивку дизасмил, нашел и рассмотрел почти все процедуры и2ц, но патч придумать сходу не удалось.

Скажите, насколько реально добиться от китайцев соответствующего фикса? Как и куда обращаться?
Может кто-нибудь сталкивался с этой проблемой?
На форуме ничего такого не обсуждалось? (Поиском не нашел.)

Спасибо.

Я пробовал с пиком по I2C "общаться" (на одной плате), такая же фигня была. Написал сам протокол и все работает. В ЕАТ даже длительности 0 и 1 зависят от того, на сколько занято основное ядро. Поэтому мой Вам совет не мучаться, написать самому свой протокол.

Bit-banging?

А если выключать инты на время лоу-левельных процедур на гпио?

"...А если выключать инты ..." это как?

Софтовый I2C будет сильно греть CPU и жрать батарейку. И скорости может не хватить. Хотя, зависит от того, что передаётся и как часто.

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

Провел некоторые эксперименты.
Задача: сформировать сигналы на ГПИО из пользовательской процедуры с заданными программными задержками, определить:
- факт вклинивания в процедуру вызовов ядра (по изменению задержек),
- кол-во тактов проца на одну итерацию цикла задержки.
В качестве измерителя использовал альтерный ТАР с частотой сэмплирования 3,125МГц.

Код рабочей процедуры:


Код задержкера:
С:

Дизасм:


Снятый график:
http://i.snag.gy/QvNTY.jpg
Актуален сигнал SDA (названия сигналов остались от предыдущих экспериментов).

Картинку наблюдал визуально в режиме Autorun analysis в течение примерно 5 минут. При этом звонил на модем, принимал и отправлял СМС.

Резалты:
Кол-во итераций: 1, 10, 100, 1000
Задержка в отсчетах 3,125МГц: 16, 39, 256, 2416.
Средняя задержка на итерацию в отсчетах 3,125МГц: 2.4
Средняя задержка на итерацию в тактах 156МГц: 120 (!!!)

Выводы:
- все задержки имеют постоянную величину и не прыгают рандомно,
- количество тактов на 2 команды тхумба 120, что зашкаливает мое понимание этой жизни, если конечно ядро не сбрасывает частоту АРМа при входе в ЕАТ процедуры (как раз для экономии батарейки).

Еще поснимал логи работы китайского встроенного I2C:
работает чотко по двум сценариям:

ebdat15_07I2C_GET_DATA():
START
SLA-W
Send DATA (pTransfer->txDataSize bytes)
RSTART
SLA-R
Receive DATA (pTransfer->rxDataSize bytes)
STOP

Ну и ebdat15_07I2C_PUT_DATA() - наоборот.

Т.е. для кастомного сценария обмена по шине не пригодно.

UPDATE
Иногда (редко, но факт) все-таки происходят прерывания работы юзер-приложения основным функционалом модема, что выражается в заметных растягиваниях задержек.
Прошу прощения за неточную информацию.
Следовательно, такие протоколы как 1-wire реализовать нельзя в принципе.

>>>Следовательно, такие протоколы как 1-wire реализовать нельзя в принципе.

Ну тогда 1-wire работающее на ЕАТ у одного нашего клиента будем считать божественным чудом.

В модуле крутится RTOS RTK-E (Philips Real Time Kernel) - ищите доки указаные ниже и там все понятно расписано по процессам и времянкам.
Так что реализация возможна.

RTK-E Introduction.pdf
RTK_cook_CUST User Manual.pdf

О, спасибо, почитаю.

Подскажите, где можно скачать эти документы:
-RTK-E Introduction.pdf
-RTK_cook_CUST User Manual.pdf
По гуглу что-то не нахожу....

Наверно у нас Гугли разные

Поэтому гугль > китайские форумы > регистрируемся, договариваемся и качаем.
Иначе читать только в онлайне.

У меня есть полный комплект по RTK-E, но к сожалению дать не могу - обещал не раздавать.

Вообще I2C тактируемый протокол и для слэйвов можно простой кнопочкой настукивать команды, а вот мастер должен контролировать задержки от слэйва(чтобы не ждать зависшее устройство) и видимо где-то в программе SIM900 этот контроль некорректно пересекается с более приоритетными прерываниями и блокирует всю.

Скачать увы не нашел, а почитать:
http://www.docin.com/p-54136233.html

Подскажите, кто нибудь проверял в ЕАТ скоростя по ebdat9_09ChangeMainUartBaudRate ? У меня на 115200 обмен идет, а вот на 9600 уже одни нули в терминале вижу...

А покажи пожалуйста свой код - соберу и проверю у себя.

ebdat7_00EnterDebugMode();
ebdat9_03SetModemdataToFL(TRUE);
ebdat9_04SetUartdataToFL(TRUE);

void init_uart(void)
{
FlMainUartDataFormat uartdataformat;
FlMainUartFlowControlStruct uartflowcontrol;

uartflowcontrol.dcebydte = FL_MAIN_UART_NO_FLOW_CONTROL;
uartflowcontrol.dtebydce = FL_MAIN_UART_NO_FLOW_CONTROL;

uartdataformat.uartFormat = FL_MAIN_UART_8N1_FORMAT;
uartdataformat.uartParity = FL_MAIN_UART_ODD;

// while(ebdat9_09ChangeMainUartBaudRate(115200)!=FL_OK){};
while(ebdat9_09ChangeMainUartBaudRate(9600)!=FL_OK){};
while(ebdat9_11ChangeMainUartDataFormat(uartdataformat)!=FL_OK){};
while(ebdat9_13ChangeMainUartFlowControl(uartflowcontrol)!=FL_OK){};
}

Я подозреваю, что могло не правильно отображаться в программе терминала (я в хексе отправляю данные).... вечером попробую текст просто отправить в порт

Разобрался! У меня на этом порту стоит ADM485 с ногой RX/TX, так вот на 115200 работает так:

if(ebdat9_05GetSerialPortTxStatus()!=TRUE)return 0;
ebdat6_04WriteGpio(pin_SW_RX_TX, 1);
ebdat05_09delay(1000);
ebdat9_02SendToSerialPort((char*)pBuff, LenBuff);
ebdat05_09delay(10000);
ebdat6_04WriteGpio(pin_SW_RX_TX, 0);

а вот на 9600 приходила только третья часть буфера....пришлось сделать так и только тогда заработало (в смысле буфер полностью доходил):

if(ebdat9_05GetSerialPortTxStatus()!=TRUE)return 0;
ebdat6_04WriteGpio(pin_SW_RX_TX, 1);
ebdat05_09delay(1000);
ebdat9_02SendToSerialPort((char*)pBuff, LenBuff);
ebdat05_09delay(20000);
ebdat6_04WriteGpio(pin_SW_RX_TX, 0);

Да, собсно в коде инициализации я ниче такого и не увидел.
Поздравляю! )

Эх, жаль, но EAT/OCPU далеко не realtime. Задержка отрабатывается весьма приблизительно (а также и начало реальной выдачи в UART после выполнения SendToSerialPort), и если ее установить с запасом, то часть ответа теряется (например, при опросе ДУТ). Мне кажется, без простенького внешнего МК (типа PIC10), управляющего режимом RX/TX в засисимости от старт-бита, тут никак не обойтись. Возможно, кто-то решил проблему по другому?

В принципе можно поставить adm с автоопределением и не трогать эту ногу вообще.