объясните как оно работает...
- Войдите на сайт для отправки комментариев
Ср, 07/02/2018 - 17:30
в общем столкнулся с таким кодом (библиотека TinyGPS.h)
for (unsigned long start = millis(); millis() - start < 1000;) { while (skgps.available()){ char c = skgps.read(); if (gps.encode(c)) newData = true; } }
в общем оно работает нормально - НО при этом всё остальное виснет намертво.... тоесть если кроме этого запроса есть еще код с лупе - он тупит неимеверно
я попробовал заменил его на простой вызов по таймеру
if(tm5>interval5) { timer5=tm; /* Каждую секунду парсим GPS данные*/
while (skgps.available()){ char c = skgps.read(); if (gps.encode(c)) newData = true; }
}
так весь код в лупе работает нормально, НО теперь данные с жпс не идут - они тупят дико и получает 1 раз из 20 информацию....
вот теперь я както в замешательстве...
это получается 1й вариан висит пока всё не сделает сам... а во втором он просто не успевает сделать что требуется?...
подскажите решение, как забирать и парсить ЖПС и при этом не тормозить остального......
всё сам разобрался
неудачный пример использовал - оно тупо зациклено долбило порт пока не получала данные и продолжала долбить - вот и жрало всё.... переписал немного - теперь хоть не вешает так дико, хотя есть небольшие тормоза
надо както менять алгоритм чтобы она не ждала, когда в порте чтото появится , а отправляла запрос ЖПС приемнику на отдачу даннх и получала их сразу... вот только как это сделать - кто может подсказать библиотеку или пример как работать с ЖПС приемником в режиме запрос-ответ
//пс приемник полноценный, с компа можно настройки менять как удобно
первый пример - абсолютный бред (неужели из библиотеки)?
Второй вариант - по таймеру - много лучше. Чтобы не терялось, надо просто интервал делать поменьше, скажем 50мс. При неблокирующем коде частый опрос ничего тормозить не будет.
Я тоже как-то мучался с TinyGPS.h. Пока низкий апгрейд рейт, как у Вас в коде - 1сек, то можно было терпеть. Проапгрейдил приемник - стал получать 5Гц, да и бодрейт поднял, - пришлось отказаться от этой библиотеки, и писать свой парсер. Там ничего сложного, надо просто разобраться в формате предложений RMC и если нужна высота, то GGA. Остальное поотрубать нафиг.
первый пример - абсолютный бред (неужели из библиотеки)?
Мне пришлось вообще отдельный микропроцессор ставить на обработку ЖПС, но зато получил бонус в виде получения данных по i2c.
да не, в первом примере он при кажом входе читает порт и парсит всё, что есть
и если удачно - тода дает на выход результат
и судя по логу - он это делает раз 20 с векунду (328й столько успевает пройти раз)
и только с 15-25й прохода он видимо получает с порта верную последовательность (полный набор данных) и тогда дает 1 секунду отдыха....
вот в этом и проблема - ведь я же не знаю, когда в порт придет полный пакет нужных данных, чтобы его считать весь и сразу а не бесконечно ждать и парсить....
первый пример - абсолютный бред (неужели из библиотеки)?
Мне пришлось вообще отдельный микропроцессор ставить на обработку ЖПС, но зато получил бонус в виде получения данных по i2c.
а можно по подробней об этом...
а то у меня валяется кучка айтюни13 - я думаю её же хватит жпс читать и парсить... былобы очень удобно по i2c или spi получать готовый результат - и нагрузки на основной проц не будет )
а то у меня валяется кучка айтюни13 - я думаю её же хватит жпс читать и парсить... былобы очень удобно по i2c или spi получать готовый результат - и нагрузки на основной проц не будет )
ТОлько чего рассказывать не знаю :) Все просто как борщ: мониторим сериал, пришли данные, определяем что за предложение и парсим в зависимости от того. Свежими данными заполняем структуру данных, куда включены все координаты. Выставляем флаг что есть новые данные. Основной проц идет в своем лупе, смотрит - флаг на ноге висит, забирает данные по ай2си. Данные ушли - снимаем флаг. Усе. :)
да не, в первом примере он при кажом входе читает порт и парсит всё, что есть
и если удачно - тода дает на выход результат
и судя по логу - он это делает раз 20 с векунду (328й столько успевает пройти раз)
если судить по тому коду. что у вас приведен - все СОВСЕМ не так.
в лупе запрос
вне лупа функция запроса
ну и лог частоты вызовов и результата
а где же вот это:
хотелось бы посмотреть в глаза тому. кто встроил сюда FOR.
Это не вы. случайно?
не, я с инета код взял первый попавшийся
только начал с жпс разбираться
ELITE, в том коде, что вы привели в #9 - никакого криминала нет, его частые вызовы программу вряд ли нагруэают - они только проверяют наличие данных от GPS и при отсуствии - сразу отваливаются. Если надо сделать вызовы пореже - достаточно в первый из кодов вставить буквально одну строку...
только начал с жпс разбираться
да тут не в GPS надо разбираться - это стандартный обмен по сериал, как любой другой.
Так все-таки непонятно - откуда взялся код с FOR ? Раньше вы писали, что это из библиотеки, теперь приводите куски. где FOR нет...
Так все-таки непонятно - откуда взялся код с FOR ? Раньше вы писали, что это из библиотеки, теперь приводите куски. где FOR нет...
ELITE, в том коде, что вы привели в #9 - никакого криминала нет, его частые вызовы программу вряд ли нагруэают - они только проверяют наличие данных от GPS и при отсуствии - сразу отваливаются. Если надо сделать вызовы пореже - достаточно в первый из кодов вставить буквально одну строку...
это код из другого источника и работает куда лучше, чем из примера библиотеки
но и он создает задержки при выполнении
подскажиче какую строчку можно дописать, дабы улучшить работу?
подскажиче какую строчку можно дописать, дабы улучшить работу?
например, для опроса не чаще 50мс
спасибо, работает, но тормоза в работе запроса то весьма большие
обработка почти 200 мс длится
хотя не, не работает - то нормально то 3-4-5 и более секунд не может получить данные...
чем быстрее и чаще идет опрос порта - тем стабильнее получает данные с приемника
может быть буфер порта переполняется?...
//и да, если фажно, использую SoftwareSerial для подключения приемника на портах А0 А1 мк 328й
спасибо, работает, но тормоза в работе запроса то весьма большие - обработка почти 200 мс длится
Ну, это я не трогал. Зато после запроса - 1 секунда паузы. Если данные не обязательно обновлять раз в секунду - можете паузу после чтения данных поставить и побольше.
хотя не, не работает - то нормально то 3-4-5 и более секунд не может получить данные...
чем быстрее и чаще идет опрос порта - тем стабильнее получает данные с приемника
Попробуйте менять интервал опроса - вместо 50мс поставьте 30 или 20. Чаще нет смысла. Да и вообще, не думаю, что это связано. Если вы возьмете свой лог из сообщения #9 - у вас тоже были паузы по 20-40мс
я попробовал смотреть что идет с порта (байты)
и выяснил, что он ищет байт конца строки (10) и после него берет весь блок и дешифрует
но приемник то шлет 10 строк в секунду (по мануалу на мой 10гц)
при этом буфер порта всё время полный и идет со сдвигом
в результате при запросах с интервалом есть моменты, когда конец строки уже потерян или сдвинут и нет полной строки для считывания - вот на этом и проблема
думаю, что если както ощичать буфер перед каждым поиском нужного байта
но приемник то шлет 10 строк в секунду (по мануалу на мой 10гц)
хотя щас без задержек попробовал - выдает 5-7 ответов в секунду.
наверное надо делать реально uart-i2s на 13 тюньке и с неё забирать готовые данные
... бум учить как это теперь сделать )
хотя щас без задержек попробовал - выдает 5-7 ответов в секунду.
наверное надо делать реально uart-i2s на 13 тюньке и с неё забирать готовые данные
... бум учить как это теперь сделать )
Структура занимает 19 байт. На приемной стороне надо сформировать такую же структуру, ну и обращаться к ней соответствующе. Будут вопросы - спрашивайте. Я считал, что она на 10Гц работать должна, но все сериал.принт надо выкинуть.
Так же впервые столкнулся с gps, и целый день почти потратил на разбор того, почему данные читаются как бог пошлет. Посылал далеко и на долго. Чтение проходило один раз из 100-1000. Оказалось, что взял за основу неудачный пример криворукого блоггера.
Как и в одном из примеров ELITE, переменная для поиска начала строки была типа int.
Что интересно как часы вполне работает, т.к. все ресурсы МК тратятся на работу с gps и переодически фазы луны и мк совпадаю