SIM900: кривая реализация I2C для Embedded AT Опции

[HDL]

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

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

Спасибо.

[Romashki]

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

[HDL]

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

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

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

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

Код

ebdat6_04WriteGpio(PIN, TRUE);
fl_wait(1);
ebdat6_04WriteGpio(PIN, FALSE);
fl_wait(1);
ebdat6_04WriteGpio(PIN, TRUE);
fl_wait(10);
ebdat6_04WriteGpio(PIN, FALSE);
fl_wait(10);
ebdat6_04WriteGpio(PIN, TRUE);
fl_wait(100);
ebdat6_04WriteGpio(PIN, FALSE);
fl_wait(100);
ebdat6_04WriteGpio(PIN, TRUE);
fl_wait(1000);
ebdat6_04WriteGpio(PIN, FALSE);
fl_wait(1000);
ebdat6_04WriteGpio(PIN, TRUE);

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

Код

void fl_wait(int n)
{
    volatile v;
    while (n--) v;
}

Дизасм:

Код

ROM:904005C4 fl_wait                        ; CODE XREF: fl_entry+112j
ROM:904005C4                 SUBS    R0, R0, #1
ROM:904005C6                 BCS     fl_wait
ROM:904005C8                 BX      LR

Снятый график:
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() - наоборот.

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

Сообщение отредактировал HDL - Sep 20 2013, 20:19