[HDL 0]

Печально, но %сабж%.

Вызов транзакции по I2C шине, например такой (взят из примера):

ebdat15_07I2C_PUT_DATA(pTransfer);

из обработчика событий в EAT приложении зависает, если устройство с заданным I2C адресом не ответило ACK-ом на SLA-R/W. Модем висит несколько секунд до самого ребута по вотчдогу.

Зависание происходит на втором по счету обращении, если на первое получен NACK, причем наличие ACK на втором обращении ни на что не влияет.

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

 

Скажите, насколько реально добиться от китайцев соответствующего фикса? Как и куда обращаться?

Может кто-нибудь сталкивался с этой проблемой?

На форуме ничего такого не обсуждалось? (Поиском не нашел.)

 

Спасибо.

[Romashki 0]

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

[HDL 0]

Написал сам протокол

Bit-banging?

В ЕАТ даже длительности 0 и 1 зависят от того, на сколько занято основное ядро.

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

[Romashki 0]

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

[fk1 0]

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

[HDL 0]

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

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

А вызывать оно их может только прерываниями.

 

Провел некоторые эксперименты.

Задача: сформировать сигналы на ГПИО из пользовательской процедуры с заданными программными задержками, определить:

- факт вклинивания в процедуру вызовов ядра (по изменению задержек),

- кол-во тактов проца на одну итерацию цикла задержки.

В качестве измерителя использовал альтерный ТАР с частотой сэмплирования 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() - наоборот.

 

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

Изменено 20 сентября, 2013 пользователем HDL

[HDL 0]

UPDATE

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

Прошу прощения за неточную информацию.

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

[CADiLO 11]

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

 

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

 

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

Так что реализация возможна.

 

RTK-E Introduction.pdf

RTK_cook_CUST User Manual.pdf

[HDL 0]

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

[Romashki 0]

Подскажите, где можно скачать эти документы:

-RTK-E Introduction.pdf

-RTK_cook_CUST User Manual.pdf

По гуглу что-то не нахожу....

[CADiLO 11]

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

 

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

Иначе читать только в онлайне.

 

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

 

[HardEgor 66]

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

[HDL 0]

Подскажите, где можно скачать эти документы:

Скачать увы не нашел, а почитать:

http://www.docin.com/p-54136233.html

[Romashki 0]

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

[HDL 0]

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