Второе ядро Raspberry Pi 2040

[Dryundel]

Второе ядро Raspberry Pi 2040
Набор блоков для запуска части программы на втором ядре Raspberry Pi 2040

3.jpg

5.jpg

[spoiler=Размещение блоков в проекте]

4.jpg

[/spoiler]
[spoiler=Описание применения]START_CORE2 for Raspberry Pi 2040
Стартовый блок для запуска части программы на втором ядре Raspberry Pi 2040
- Разместить блок на отдельной перед кодом выполняемым на втором ядре

END_CORE2 for Raspberry Pi 2040
Финишный блок для запуска части программы на втором ядре Raspberry Pi 2040
- Разместить блок на отдельной плате сразу после кода выполняемого на втором ядре

Все что размещено на платах между блоками
START_CORE2 for Raspberry Pi 2040 и END_CORE2 for Raspberry Pi 2040
будет работать на втором ядре Raspberry Pi 2040.[/spoiler]
.
Актуальная версия

Второе ядро Raspberry Pi 2040.ubl

- Исправлен баг #Пост23
Разработано в соавторстве с [ref=#808080]Phazz[/ref].
.
.
История версий:

Второе_ядро_Raspberry_Pi_2040_(Code_-_Basic).ubi

.
ВНИМАНИЕ! Работает только на библиотеке контроллера Raspberry Pi Pico by Earle F.Philhower

Описание контроллеров Raspberry Pi 2040 берем здесь. Спасибо [ref]DrMario[/ref].
[spoiler=Библиотеку контроллера устанавливаем эту.]

1.jpg

[/spoiler]

[ecoins]

Хорошее решение, буду пользоваться, спасибо.
---------
А для ESP32 простого решения использования другого ядра не найти?

[Phazz]

[ref]ecoins[/ref], Есть блок но использование delay для переключения все убивает (

[ecoins]

ecoins, Есть блок но использование delay для переключения все убивает (

Это по ESP32? Посмотреть бы...

[Dryundel]

А для ESP32 простого решения использования другого ядра не найти?

Думаем. Но там все слишком запутано и простых решений совместимых с FLProg пока не вижу. ESP32 хоть и не плохой контроллер, но создатели ядра под него как то не особо заботятся о совместимости. Слишком много отклонений в стандартных функциях. Это слегка напрягает и разочаровывает.
============
Еще думаю есть ли смысл разделять Setup() в ПБ для RPi. В основном влияет только на скорость загрузки. Однако появились идеи разделять конфигурацию и проверку на выход в рабочие параметры на одном ядре, а старт выполнения на другом. Но это пока только бурные фантазии.

Вижу что пока публике не зашло второе ядро RPi. Мало кто скачивает.
Либо мало у кого есть данный контроллер, либо осознание прелести простого использования сразу двух ядер еще не достигла общественного сознания.

Первые впечатления от Raspberry Pi Pico
При своей стоимости, характеристики весьма впечатляют.
Из минусов - не много специфических библиотек и примеров для данного процессора под Arduino IDE.
Однако развитие идет семимильными шагами. Контроллеры весьма перспективные.

[ecoins]

При своей стоимости, характеристики весьма впечатляют.
Из минусов - не много специфических библиотек и примеров для данного процессора под Arduino IDE.

Пока удалось укомплектоваться библиотеками.
-------

Еще думаю есть ли смысл разделять Setup() в ПБ для RPi. В основном влияет только на скорость загрузки. Однако появились идеи разделять конфигурацию и проверку на выход в рабочие параметры на одном ядре, а старт выполнения на другом. Но это пока только бурные фантазии.

При построении своих библиотек мы практически отказались от setup(). А есть ли простой способ добавления setup1() с учетом FLProg?

При своей стоимости, характеристики весьма впечатляют.

Да, конечно. Но как ни странно STM32F411 раза в 2 быстрее.
Но с ним сложнее работать, у него одно ядро. И он дороже...

[Dryundel]

А есть ли простой способ добавления setup1() с учетом FLProg?

А где в FLProg используется setup()? Его просто нет в открытом доступе. Все setup() только в блоках. А что мешает при создании ПБ поступить аналогичным образом. Просто вставляем в секцию } void setup1() { и пишем дальше то, что хотим сетапить на втором ядре.
Я так думаю. Хотя и не пробовал. Ведь в этом случае setup1() окажется перед loop(), а не перед loop1(). Короче надо пробовать.

Да, конечно. Но как ни странно STM32F411 раза в 2 быстрее.

Ну и что? Если умножить скорость на два ядра, получим тот же результат, но с разделением на важные(быстрые) и прочие задачи. Так что здесь можно поспорить об общем быстродействии.

[ecoins]

Я так думаю. Хотя и не пробовал. Ведь в этом случае setup1() окажется перед loop(), а не перед loop1(). Короче надо пробовать.
ecoins писал(а): ↑24 минуты назад
Да, конечно. Но как ни странно STM32F411 раза в 2 быстрее.
Ну и что? Если умножить скорость на два ядра, получим тот же результат, но с разделением на важные(быстрые) и прочие задачи. Так что здесь можно поспорить об общем быстродействии

Да, конечно.
У Raspberry Pi Pico - много достоинств. С ним почти также просто работать, как с MEGA2560 - быстро компилируется, быстро грузится.
Из недостатков - логика 3.3в.
Для i2c мы эту проблему решаем просто - изготовили конверторы.

i2c_5v_3v.jpg

В них есть два дополнительных канала.

[Phazz]

ecoins, Есть блок но использование delay для переключения все убивает (

Это по ESP32? Посмотреть бы...

viewtopic.php?f=194&t=7566

[ecoins]

ecoins писал(а): ↑Вчера{, 17:15}
Phazz писал(а): ↑Вчера{, 16:59}
ecoins, Есть блок но использование delay для переключения все убивает (
Это по ESP32? Посмотреть бы...
viewtopic.php?f=194&t=7566

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

[Dryundel]

ecoins, Есть блок но использование delay для переключения все убивает (

Выкиньте этот delay из закрывающего блока вместе с параметром. И дело с концом.
Он там вообще не нужен.
С другой стороны, этот delay практически не мешает выполнению другого кода, кроме того который между блоками.

Отправлено спустя 9 минут 31 секунду:

Посмотрел. Спасибо.

Что увидели?
Что то среднее между вашим планировщиком и FreeRTOS.Не правда ли?
[ref]ecoins[/ref], а может вам посмотреть в сторону FreeRTOS и его внедрением в FLProg? Там все гораздо интереснее. Очереди, семафоры, мьютексы...

[Phazz]

[ref=#ff8000]Dryundel[/ref], там рекомендован delay 1ms, а это очень много

[Dryundel]

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

В случае с RPi и loop1() вообще никаких проблем не вижу пока. Просто куски кода выполняются на разных ядрах и все.
Единственный затык в том, как например там Serial.print в один порт будет с разных ядер выполняться. Не будут ли мешать друг другу подобные функции.
На ESP32 их xTaskCreatePinnedToCore похоже учитывает и планирует задачи в соответствии с приоритетом и параметрами.
В RPi тоже есть подобная система. Вот только инфы пока мало. В основном все ориентировано на Питон.

[Dryundel]

Dryundel, там рекомендован delay 1ms, а это очень много

Где рекомендован? Можно инфу? Я как то не заметил проблем без delay.
С другой стороны, даже если и будет этот delay в функции (задаче). Как я уже писал ОН НЕ МЕШАЕТ ВЫПОЛНЕНИЮ ОСТАЛЬНОЙ ПРОГРАММЫ!
Функции которые в блоке являются частью этакой своей FreeRTOS от создателей ядра для ESP32.
Вы можете создать десяток каких задач (надо только слегка блок допилить). В каждой задаче свой delay хоть на 5секунд. Запустить все задачи на одном ядре и они не будут друг другу мешать.
Вот пример - Три разных блинка c delay() на одном ядре (0).

3_Task.ino

Наслаждайтесь FreeRTOS от ESP32

[artemka19]

эта rtos как мнимум для esp32
для той же нано/уно порт rtos носил развлекательный
характер.

[spoiler]
"...Пробовал я FreeRTOS на нане. Помигал диодиком. Вывел на экран ПРИВЕТ МИР. Здесь память кончилась. Ничего больше из задач добавить не получилось. Ушёл на STM32. Там получилось поднять 6 задач. В том числе сеть и CD карту и тачь. Меги у меня нет. Про неё ничего не скажу, но на более мелких FreeRTOS это игрушка..."

[/spoiler]

Отправлено спустя 6 минут :
простой пример:
-вывод в юарт
-две задачи
-в rtos для Каждой задачи нужно будет запускать Свой экземпляр Serial.begin

Отправлено спустя 4 минуты 3 секунды:
*ну и сам факт переписывания всех библиотек arduino под rtos не добавляет оптимизма)))

[Dryundel]

эта rtos как мнимум для esp32

Да ладно! Вы тоже это заметили?
А о чем мы здесь еще по вашему?

*ну и сам факт переписывания всех библиотек arduino под rtos не добавляет оптимизма)))

Прям таки всех? Класс! А зачем? Что изменилось то?

[artemka19]

ecoins, а может вам посмотреть в сторону FreeRTOS и его внедрением в FLProg

вот тут нет ничего про esp

Отправлено спустя 1 минуту 31 секунду:

Прям таки всех? Класс! А зачем? Что изменилось то

когда будет пример - обсудим.
Теорию с uart я уже привел выше.

Можно попробовать с spi)))) подожду результата тестов...

Отправлено спустя 3 минуты 14 секунд:
ну и не стоит забывать, что некоторые библиотеки Прямо запрещают использование прерываний.

т.е. не переписывая эти библиотеки - ни о каком rtos не может быть и речи в среде ардуино ide

Отправлено спустя 2 минуты 31 секунду:
поэтому система от ecoins наиболее жизнеспособна в рамках ардуино ide (а значит и флпрог)

***ИМХО конечно

[ecoins]

Что то среднее между вашим планировщиком и FreeRTOS.Не правда ли?
ecoins, а может вам посмотреть в сторону FreeRTOS и его внедрением в FLProg? Там все гораздо интереснее. Очереди, семафоры, мьютексы...

Собственно первые наметки начал делать.
На новых контроллерах ESP стало нормой устанавливать адресный светодиод типа ws2812.
Библиотеки управления все основаны на FreeRTOS. И это понятно в силу особенности управления такими светодиодами.
Как бы полезно было бы сделать штатно такую функцию. Это в планах.
На STM32, RP2040 схожая ситуация, freertos присутствует.
-------------
Когда несколько лет мы начали изучать проблему почему тормозят проекты на FLProg мы начинали с рассматривания системы реального времени.
После того как появилось управления выполнения по платам по условиям, появилось то, что мы назвали значимо "Диспетчер задач", которая фактически является достаточно удачным переключателем между задачами.
Появление "Диспетчера" не решило проблемы, поскольку любая "тормозящая" задача может свести на нет результаты оптимизации по времени - например АЦП, почти все библиотеки работы с внешними устройствами, и даже алгоритм преобразования
float в int от FLProg в ModBus и пр.(последнее в контроллерах AVR очень тормозит).
Большинство библиотек от Arduino IDE написано с удобной для пользователя логикой - одна функция (строка) сразу приносит желаемый результат.
А внутри delay(), обмен через коммуникации, иногда громоздкие вычисления и прочие "плюшки", приводящие к задержкам.
Были разработаны методы проектирования библиотек - все библиотеки от ecoins построены на микрооперация - законченное конечное действие, после которого можно вернуть управление внешнему диспетчеру, сейчас это "Диспетчер задач".
Методы достаточно отработаны и уницифированы в том числе с учетом некоторых особенностей проектирования на FLProg.

По поводу семафоров и пр. - по моему мнению лучше всего этого избегать, иначе сложность управления этими процессами сами по себе поглощают ресурсы, в том числе и по быстродействию.
Могут возникать и конфликты - например при попытки нескольких задач одновременно использовать одну и ту же шину i2c.
К слову в непростой библиотеке LCD ecoins используется механизм блокировки вывода по флагу занятого дисплея.
---------------------
Тема очень интересная - если от разных участников форума будут локальные тестовые наработки, их можно будет объединить в универсальный результат.
При это все и по отдельности, и в связке будет полезно - "Диспетчер задач", многоядерность (там где она присутствует), и FreeRTOS.
------------------
Всем желаю успехов в развитии такой тематики.
Со своей стороны примем посильное участие.

[Dryundel]

Могут возникать и конфликты - например при попытки нескольких задач одновременно использовать одну и ту же шину i2c.
К слову в непростой библиотеке LCD ecoins используется механизм блокировки вывода по флагу занятого дисплея.

Ну так это же практически в чистом виде мьютексы.
Снова изобретаем велосипед?

[ecoins]

Ну так это же практически в чистом виде мьютексы.
Снова изобретаем велосипед?

Прекрасно, когда присутствует теоретик, который все может объяснить... мьютекс...

Это как к старику-пастуху лектор приезжает и читает лекцию "Как пасти баранов".
Старик слушает, удивляется обилию нового и значимости своего дела, лектор уезжает и пастух продолжает пасти баранов - а это шерсть, мясо, кюрдюк, копыта для хаша(холодца), навоз и прочее, прочее полезное в практическом смысле...

О мьютексе... Раньше не использовал этот термин. Посмотрел...
В наших проектах нет потоков, соответственно и мьютексов...

Прослушал как-то в youtube несколько лекций по программированию из Физтеха.
Услышал и много полезного, а в целом вывод - "Как же Вы далеки от народа" и от текущей реальности...
------
Примечание: никого обидеть не хотел и не хочу.
------
Подпись: Программист ну очень с большим стажем... из очень из разных эпох... пытается держать руку на пульсе времени.