RTL87xx Arduino

[Pilnikov]

@Pilnikov, ну тогда им сутьба быть вечным конструктором

Чем бы дитё не тешилось, лишь бы денег не просило.

Безупречный код только свой в чужом всегда сплошные изъяны.

Зато своё, зато родное!

поздравляю с выбором идеальной платформы

А вот моё присутствие в этой ветке обусловлено как раз таки желанием эту самую платформу поменять (будь оно неладно)

 

[vad7]

Creep, ну а я о чем, просто надо понимать, что это не SDK, и быть готовым к нежданчикам и рассчитывать свои силы.
Вот у меня уже 4 месяца без сбоев и перезагрузок пашет, управляя вентиляцией, доработанный вебсервер:

И еще парочка работает по другим задачам. Правда приходилось не только софт, но еще и аппаратно разные примочки навешивать, чтоб устойчиво работало.

 

[Creep]

надо понимать, что это не SDK

а что такое SDK в Вашем понимании? в чем его отличительные особенности? чем отличается SDK в Вашем понимании от того "набора переработанных текстов" который производит @pvvx?

 

[nicelight]

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

Будь моя воля, я бы тоже с удовольствием ушёл от ардуино иде, но блин...время.Где его брать? К сожалению у меня на основе библиотек ардуиновских уже более двух лет работают разные проекты, в том числе коммерческие.последние пол года клиенты вообще перестали на глюки жаловаться. Просто потому что стараюсь обходить глючные моменты, складывая их в стопку. Пользуюсь тем что проверено и стабильно. Конечно сама концепция ардуины это адский костыль. Но как быть по другому если за не именем времени у тебя выбор или не сделать ничего или сделать что то, что нужно клиенту, пускай него кпд 20% от реальных возможностей железа, но оно работает и клиент доволен. Тут речи быть не может о массовом производстве качественной продукции. Это больше для себя друзей или единичные эксклюзивные заказы.
Если нет времени учить C++, но есть глючный python(предположим что он сильно глючный). То очень приятно хотя бы пользоваться тем что более менее работает в пайтоне, чем облизываться на си но так и не выучить его. И таких вот костыледелов оказывается много. И я благодарен создателям ардуино, что они хотя бы дали возможность костылить что то и радоваться миганию светодиода в два клика, потому что появляется мотив постепенно изучив пайтон учить си. Появляется мотив творить. Появляется возможность делать хоть что то не тратя время.
Если говорить за себя, то я бы и сам рад поскорее уйти с ардуины. Научить не кому, научиться самому не хватает клепки и времени =)

 

[nicelight]

Еще хочу сказать что не смотря на характер @pvvx и его подход к делу, я благодарен ему за все что он делает, за его труды которым бы цены не было если бы их систематизировать и по полочкам разложить хоть с минимальным описанием.
От имени телепузиков говорю спасибо! Вы делаете нашу жизнь немного счастливее

 

[Creep]

ну вот собственно и объяснение почему "телепузикам" никогда не стать гуру - время отводимое на программирование катастрофически сжато.
ну а претензии/пожелания "чтобы все было хорошо и нам за это ничего не было", к сожалению, мимо кассы. по своим юношеским воспоминаниям даже курсовик на сях в черновике писался за неделю, а потом еще неделю-две из него тоннами выгребал ошибки и обрабатывал эксепшины. турбоси, конечно, с эклипсом и в-студией не сравнить, но и программы требуются не "два байта переслать". варианты решения проблемы для нас: объединятся и делить задачу - возможно будет получить несколько относительно рабочих библиотек для общественного пользования, а pvvx подключить на шеф-монтаж. альтернатива молиться богам или самостоятельно "не ожидая милостей от природы" (с)
"

 

[nicelight]

ну вот собственно и объяснение почему "телепузикам" никогда не стать гуру - время отводимое на программирование катастрофически сжато. ...
Варианты решения проблемы для нас: объединятся и делить задачу - возможно будет получить несколько относительно рабочих библиотек для общественного пользования, а pvvx подключить на шеф-монтаж. альтернатива молиться богам или самостоятельно "не ожидая милостей от природы" (с)
"

Если ты не можешь быть гуру, это еще не повод чтобы не быть ни кем вообще))
Давайте объединяться и пилить исходники. Я только за, но пока что мало волоку.. Будут глупые вопросы.
Опыт ковыряния и правки библиотеки от адафрут был. Сильно не хватает понимания структуры всей системы ардуИДЕ и принципов взаимодействия. Что то типа HOW IT WORKS?)

 

[Pilnikov]

Если ты не можешь быть гуру, это еще не повод чтобы не быть ни кем вообще))
Давайте объединяться и пилить исходники. Я только за, но пока что мало волоку.. Будут глупые вопросы.
Опыт ковыряния и правки библиотеки от адафрут был. Сильно не хватает понимания структуры всей системы ардуИДЕ и принципов взаимодействия. Что то типа HOW IT WORKS?)

Тут ведь вот какое дело. Дурина на то и дурина, что она для быстрого старта. Как среда - это редактор (убогий), компилятор с настроенными опциями (линковка, мемори мап и т.д. и.т.п.), и загрузчик (несколько). Все настройки прописываются в .txt или .ini.
Но вот для "ковыряния и правки" SDK (чем собсно и занят pvvx) Дурина сильно не подходит. Для сдк нужен многооконный интерфейс для отслеживания связей между отдельными компонентами.
И "эффект" от копания сдк - не совсем то, что мы, "телепузики", привыкли получать. Сдк - это же "кирпичики", а вот "дом" - эта наша пользовательская прога. И все вопросы тут от нас - это не какого цвета(формы) выбрать кирпич, или как его, кирпич сделать из овального прямоугольным, а о том как построить дом, пускай и из овальных кирпичей.

 

[Creep]

активный участник сообщества @vad7 что-то пропал, а мне все-таки хотелось бы понять что он понимает под термином СДК.
@Pilnikov, желания и возможности "телепузиков" очевидны, другой вопрос: возможно ли извлечь из этого практическую пользу для их сообщества. мой опыт участия в проектах в группах (до 30-40 чел) по интересам говорит, что неимоверные усилия пары тройки координаторов + энтузиазм остальных могут дать определенный выхлоп в краткосроке и затем выпустить из своей среды от 2 до 4 понимающих в теме, к сожалению, остальные ничего кроме разочарования не получат. срач, ротация кадров и потерянное время в комплекте.
не говорю, что объединяться нет смысла, но входной ценз обязателен, группа до 3-4 чел чтобы обойтись без больших руководящих расходов, ну и дальше - коллективная разработка со всеми ее прелестями. на этом можно начать "тесать кирпичи" до нужной формы. сколько таких людей на форуме? для РТЛ это ...правильно - 2,5 человека, и только один из них видит ради чего, он это делает ибо есть хоть какой-то план применения, остальных устраивает то что есть, ибо тропинки уже протоптаны.

 

[Pilnikov]

@Creep не поленитесь, создайте тему "Эклипс для чайников" с примером настройки среды под RTL и ESP. По крайней мере я буду вам очень благодарен за это. Да и к pvvx'y вопросов станет меньше (я надеюсь

 

[Creep]

@Creep не поленитесь, создайте тему "Эклипс для чайников" с примером настройки среды под RTL и ESP. По крайней мере я буду вам очень благодарен за это. Да и к pvvx'y вопросов станет меньше (я надеюсь

чуть позже попробую. надеюсь, за пару-треху недель приедет подсветка для ноута - започиняю его, буду его точить под "Эклипс с RTL". ESP если честно не очень, на первый взгляд все просто и красиво, но кроме как познакомиться, боюсь, он не потянет. по цене ртл от есп принципиально не отличаются, а вот близость архитектуры/начинки/исходников к стм, арм и прочим аббревиатурам внушает оптимизм, хула pvvx на есп даже если и преувеличена то все равно имеет достаточные основания. "а раз не видно разницы - зачем платить больше?" (с) надо понимать, что у меня достаточно специфический опыт в области микропроцессорной техники: по образованию инженер-системотехник, диплом был на PIC14000, а потом пару десятков лет админства... то есть что и как происходит внутрях в общих чертах я в курсе, писать на сях тоже чутка обучен, инглиша не очень боюсь, но на круг имею знаний и опыта в работе с МК меньше чем любой из здесь присутствующих. посмотрим чем кончится

 

[Юрий Ботов]

Продолжу тему RAK Creator pro.
Наконец ее получил... Первые впечатления.
Прикололо то, что они собрали приличный SDK для arduino:

https://github.com/RAKWireless/CREATOR-Arduino-SDK/raw/master/release/package_rakwireless.com_creator_index.json

и то что в нем много рабочих примеров.
Lpc действительно прошита DAP.
Намучился с тем, что для перевода в режим программирования надо нажать на кнопку N/R хотя про это нигде как то не написано... нажал случайно.
При подключении к вин10 появляется диск с прошивкой lpc-шки. А после нажатия на N/R, диск подменяется содержимым rtl-ки.

 

[pvvx]

Продолжу тему RAK Creator pro.
Наконец ее получил... Первые впечатления.
Прикололо то, что они собрали приличный SDK для arduino:

https://github.com/RAKWireless/CREATOR-Arduino-SDK/raw/master/release/package_rakwireless.com_creator_index.json

и то что в нем много рабочих примеров.

С отключенной программно большей частью внутренних устройств и даже части GPIO для RTL8710AF...

Lpc действительно прошита DAP.

Угу и исходников MBED не имеет (как и версия самого MBED на RTL серию "A"). Десяток бинарников от Ameba прошивок DAP-Link с разными ошибками... Перекинуть и ускорить в два раза на STM32F... не выйдет.
На платках от MJIOT-AMB-DEBUG-01 Lpc тоже стоят, хотя RTL8195A имеет свой USB2.0 c режимами Host и Device, а Lpc у китайцев дороже STM и для STM есть другие варианты прошивок JTAG, включая SEGGER...
RAK пора уже заготавливать платки под серию RTL "В" (Ameba-Z) - она дешевле и более подходит для Arduino и MBED.
Есть ещё одна беда - с RTL8711AM у Ameba Arduino совсем плохо - все порты UART и прочего не совпадают в примерах с имеющимися выводами из чипа... RAK придется все их поправлять, т.к. Ameba имеет платы только с RTL8710AF и RTL8195AM (и готовит к выходу с RTL871xBN).

 

[A.V]

В RtlDuino для модуля RTL00:
UART2 SoftwareSerial mySerial2(0, 4)

Ковырялся тут в 1-wire через Serial в качестве исследования новой для себя железки и набрёл на потенциальную багу для телепузиков.

Согласно "всезнающему гугелю", Serial.begin() можно вызывать несколько раз подряд для, например, смены скорости порта. В текущей же реализации мы получаем как минимум утечку из-за безусловного "malloc(sizeof(serial_t))" и, вероятно ещё какие-нить глюки из-за повторного вызова listen().

Для себя пока поправил begin(), чтобы проверялся указатель до вызова malloc и вывел дополнительный метод "setBaud", дабы не передёргивать всю связку. Потому как последовательный вызов .end() и .begin() не только лишние тормоза, но ещё и подгаживает, а задержек делать неохота...

ЗЫ: Скорей бы уж въехать в новую железку и отказаться от дурины...
ЗЫЫ: Да! С наступающим всех! %)

 

[pvvx]

Ковырялся тут в 1-wire через Serial в качестве исследования новой для себя железки и набрёл на потенциальную багу для телепузиков.

Согласно "всезнающему гугелю", Serial.begin() можно вызывать несколько раз подряд для, например, смены скорости порта. В текущей же реализации мы получаем как минимум утечку из-за безусловного "malloc(sizeof(serial_t))" и, вероятно ещё какие-нить глюки из-за повторного вызова listen().

От слов Serial.begin и всякие Wire из Arduino меня всегда начинает подташнивать...
Обычно всё, что открывается, инициализируется в Arduino не имеет обратного хода - деинсталлов и т.д.. Всё одноразовое и никогда (в 80% классов и объектов) не предполагает повторных вызовов инициализации и отсутствуют процедуры закрытия-деинсталла-удаления.
Где-то, для какого-то контроллера, кто-то может и исправил описанную ситуацию, но это не есть общий градус по больнице Arduino.
Тут все энти либы wire/serial писала Ameba под концепцию Arduino, а мне они вообще не нужны.
Данная ситуация уже начинает переползать и на оф. сборки SDK и либ у Ameba и других производителей...
Большая часть различий между rtlDuino и Ameba Arduino именно в исправлениях по описанным проблемам - дополнение деструкторов классов и изменении инициализирующих процедур для возможности закрытия с очисткой занимаемых ресурсов. К примеру WiFi дров. А вот с USB дровами так и не удалось сделать ни деинасталла с освобождением ресурсов, ни повторной инициализации. Так описаны сами дрова у Ameba - не запоминают занимаемые ресурсы и не имеют доступа к ним (объявлены локальными в либах).
Без этого в малой памяти не выполнить многие задачи...

СHГ!

 

[A.V]

Где-то, для какого-то контроллера, кто-то может и исправил описанную ситуацию, но это не есть общий градус по больнице Arduino.
Тут все энти либы wire/serial писала Ameba под концепцию Arduino, а мне они вообще не нужны.

Видать, они и не предполагали, что кто-то полезет дальше простого Hello World! К слову, в "оригинальном" softSerial действительно нет ничего опасного, потому как под древнюю атмегу с глобальными буферами писано :/

Всё к тому, что надо побыстрее "закапывать бабушку" и заводить сборку с СДК из консоли (ну не нравится мне эклипс...)


[offtop]... Да что ж у меня Firefox так офигевает с форума-то? Два ядра под 140%... Майнеров явно не видно...[/offtop]

 

[pvvx]

Видать, они и не предполагали, что кто-то полезет дальше простого Hello World! К слову, в "оригинальном" softSerial действительно нет ничего опасного, потому как под древнюю атмегу с глобальными буферами писано :/

Спрос у общества потребления работает по галочкам. У товара с большим кол-вом галочек и спрос больше. Совсем не важно, работает ли описанная галочная функция или нет. Даже если она имеет просто надпись, то этого достаточно для "телепузиков". Так-же сами "телепузики" пишут свои либы без каких-либо забот, как их потом использовать. Стартует и делает переключение пина - светодиод загорается - что ещё надо? Они никогда не учились программированию и сборке каких-либо проектов. И в таком стиле с их (c) описаны 99% либ для Arduino.
Эту ситуацию давно уже не переломить. Если вы скажите, что то-то там не работает, то тысчи "телепузиков" вам напишут, что у них всё "работет". У них уже своё понятие "рабочий". Под это понятие уже настроены сотни производителей... Какие удивления при этом об общей деградации качества кода? Совсем грубые ошибки исправляются потом, путем вечного обновления на ходу устройств...

[offtop]... Да что ж у меня Firefox так офигевает с форума-то? Два ядра под 140%... Майнеров явно не видно...[/offtop]

Много доп.подгрузок и трасса до сервера часто тупит...

 

[pvvx]

Как-бы итоги года по Arduino на RTL-ках:

А давайте мы действительно краудфандинг попробуем организовать, для тех кто может найти на это время и просто может запилить поддержку чипов realtek ардуиновской средой, с портом некоторых основных библиотек. Пускай костыльную, но все же.. . я бы поддержал рублем точно! )
Ну и готов был бы перенять опыт, чтобы далее принимать участие в проекте и портировать оставшиеся либы и пр. самостоятельно.

@nicelight - и где описанное? Что-то не так в филармонии Arduino?
За год вышло более десятка dev-board разных производителей с набортными модулями c RTL WiFi-SoC (в основном серии "A").
Проекты финансировались разными конторами (Ameba от Reatek, WizNet WizFi310, RAK, MXCHIP, ...)
Mbed не затормозил, поддержку выпустил для разных вариантов - для прямой работы кода С++ в RTL-ках и с помощью "AT" (для модулей WizNet WizFi310). А в Arduino ничего не сдвинулось и на шаг. Только деградировало ещё ниже и код стал хуже качеством.
RAK дублировал Ameba Arduino с мелкими изменениями конфигов для своих dev-board, но ничего в самом коде Arduino не доделывал и не исправлял.
По поводу других вышедших за год модулей WiFi-SoC - поддержка Arduino в них самого низкого качества и с тенденцией скатиться ещё ниже, с ограничением доступного набора команд-функций в пару шт. Всё это как-бы говорит о том, что Arduino и её поклонники не могут освоить и перейти на современные SoC, которые имеют RTOS и/или прочие многопоточные решения для поддержки многоядерности и массы набортных контроллеров. Ту-же ситуацию показывает и Очень медленное развитие-переход Arduino IDE ESP8266 -> ESP32, хотя в данном процессе идет и финансирование и работа толпы энтузиастов. По сравнению с ними, я всего один ковырялся в rtlDuino пару вечеров и до сих пор не вижу чего-то, что не решить в лоб на уже имеющейся rtlDuino, пусть и не доделанной до отдачи в красивой упаковке... И это не в тему хвастовства, а про то, что в RTL уже изначально было заложено информации значительно больше в сам чип и его первых SDK, по сравнению с ESP, что позволяет делать любые маневры, безусловно если у вас есть знания и/или желание разбираться...

 

[Simon]

Интересный момент. RTL00 в режиме Station. При пинге его маленькими пакетами(у меня до 2048)



При пинге пакетами от 2048, либо при одновременном пинге маленькими из двух окон:


rtlduino или AT SDK 4.0, без разницы. Может быть, это какая-то особенность wifi, но я такого никогда не видел.
Суть в том, что риалтаймовый очень легкий TCP поток заметно подлагивает в station и чисто работает, когда модуль как AP.
Других сетей, кроме моей, рядом нет(дом в лесу). Остальные хосты в сети таких странностей не имеют(2-3мс в среднем любыми пакетами).
Модулей много, ведут себя одинаково.

 

[pvvx]

Интересный момент. RTL00 в режиме Station. При пинге его маленькими пакетами(у меня до 2048)
...
rtlduino или AT SDK 4.0, без разницы. Может быть, это какая-то особенность wifi, но я такого никогда не видел.
Суть в том, что риалтаймовый очень легкий TCP поток заметно подлагивает в station и чисто работает, когда модуль как AP.

Поглядите всякие отключалки экономии энергии. По умолчанию они включены на Station во всех стандартных примерах Arduino/rtlDuino/AT/примеры_SDK/... *wakelock*() всякие...
И пинг на нижнем приоритете или ещё что-то - почему-то у него всегда 1..2 мс - т.е. он оттикивает по таймеру RTOS (1 мс). Для Arduino и всяких socket() так-же - они стробируются шагом RTOS и быстрее 1 мс (+1 при раз-синхронизации) на запрос не отвечают. Web-свалка сделана по событиям от LwIP, а его дергают по событиям приема/прерывания по приему пакета в WiFi (что дает ответ и быстрее чем шаг RTOS), но это имеет свои нюансы...
Крутите Priority у задач и делайте семафоры, да т.д. Но Arduino для этого не очень-то катит.