|
>>> Особых косяков не обнаружено, а что касается UART, то там вопрос только к буферу - многим он не нужен, поэтому переписывают работу без него прямо через API.
тогда такой вопрос, какое API нужно использовать используется?
скажу сразу, то что проверяется 1 строчкой кода:
1. функция eat_uart_get_free_space не работает, все время возвращает 2048 (буфер пуст) даже если вызывать сразу после записи в порт. Если записывать не ориентируясь на свободное место, UART повисает, и больше не выдает данные.
2. EAT_EVENT_UART_READY_WR никогда не приходит. это к пункту 1 вопрос когда же можно записывать следующую порцию данных что бы UARt не повис.
3. уже не 1 строчкой кода. Если при установленном TCP соединении, включенным EAT_EVENT_UART_SEND_COMPLETE и низкой скоростью (проверял на 1200 бит/с, с 115200 работает) отправить данные то модуль перезагружается (стек около 5 вхождений - переполнение маловероятно, запись в UART производилась в callback от сокета, можно попытаться завернуть на очередь сообщений , но все это не очевидно , идем по граблям). это к пункту 2, EAT_EVENT_UART_READY_WR этим способом заменить не получится.
Остается только 1 функция - eat_uart_get_send_complete_status которая еще работает (пока не выявил в ней косяков, но это еще не последнее слово). Как переписать без буфера, он не отключается, записывать по 1 символу и в цикле ждать eat_uart_get_send_complete_status? модуль уйдет по своим делам и жди межсимвольный интервал по 5 мс.
По поводу SMS, ADC проблем пока не выявлено , но я пока еще его особо не тестировал. GPIO тож нормально за исключением пина SIM_DET, если его настроить как EINT то при изменении состояния модуль перезагружает.
для конкретной задачи, EAT оптимальное решение.
|
могут ли какие-нибудь модули отправлять SMS без управления процессором
Feb 9 2018, 05:44
