Я знаю, что извращенцев везде полно. Вон, некоторые даже жабку пытаются в МК запихать. И им пофиг, что вместо одного килобайта их код десятки килобайт занимает!
Ардуйня — такая ардуйня…
Ну, для начала приведу очень удобное: «все есть файл». Т.е. все равно, подключен у вас МК по RS-232, RS-485 или USB (в режиме CDC) — вы просто открываете файл устройства, делаете нужные ioctl, и работаете обычными read/write. Т.е. код один и тот же вне зависимости от подключения!
Модули ядра тоже разрабатывать значительно проще, чем в игропрошивке «драйвера» писать.
Документация удобная: набрал man что-то → получил.
Да и просто баш с coreutils — как вы там без них существуете? Кактусы грызете?
Зря. Я не представляю, как люди в виндах программированием занимаются. Это ж как на одноколесном велосипеде с квадратными колесами ехать, одновременно на ходу его ремонтируя!
Тем более — работа с железом. Все-таки, прошивка для игровых приставок очень плохо выполняет роль операционной системы общего назначения!
Кстати, посмотрел упомянутую библиотечку по работе с радиомодулями. Впечатлило. Я как раз такие хотел использовать, думал, придется неделю-две тратить, чтобы свой интерфейс реализовать. А тут готовое.
Удобно.
Надо будет только с С++ на С переписать и вынести аппаратно-зависимые интерфейсы отдельно, чтобы базовый код можно было как на одноплатнике, так и на микроконтроллере применять.
Жаль, для работы с ЖК-экранами до сих пор не встречал приличных библиотек. Там уже стырить готовенькое не получится ☹
Ну, я и сам поспешил. Увидев до боли знакомую delay(), решил, что код для микроконтроллера. Потому как в glibc для этих целей используется usleep или select.
Вы подключаете радиомодуль по SPI → как только что-то туда написали, так сразу получили ответ.
Вывод: отдельный поток должен постоянно опрашивать радиомодуль на наличие новых данных. Т.е. в отличие от UART'а, здесь просто нужно в цикле писать в SPI данные, затем проверять ответ. Вот в этом потоке пишите свои задержки в каком угодно количестве — на выполнение основного потока они не повлияют!
На «малинке» линукс стоит. Он позаботится о прерываниях. Ваша задача — реализовать несколько потоков и синхронизовать их.
Скажем, как происходит работа с UART? Да элементарно: при помощи select (ну, на любителя: кому-то может eselect больше нравиться, а кому-то poll) проверяем, есть ли данные в буфере порта. Если есть, считываем их и заполняем промежуточный циклический буфер. А его уже обрабатываем: если нужно построчно читать, не принимаем данные, пока не появится конец строки; если посимвольно — считываем очередной символ и обрабатываем.
Можно вообще запихать работу в отдельный поток, который будет блокировать ввод-вывод. Но на работе основного цикла в main() это никак не скажется.
В данном случае, на мой взгляд, «малинка» избыточна. С другой стороны, т.к. цена на нее вполне вкусная, зачастую проще ее использовать, а не городить что-нибудь свое, скажем, на каком-нибудь STM32F407.
А вот если нужно много GPIO, то уже придется выбирать: либо к «малинке» или «кубиборде» подключать микроконтроллеры, либо сразу взять микроконтроллер с нужными интерфейсами.
Графически можно найти, что действительных корня три, лежат они в районе: x=-1.8 первый, x=-1.6 — второй и x=1.25 — третий.
Можно простой линейной интерполяцией прикинуть, чему будут равны корни. Навскидку, x₁=-1.802, x₂=-1.618, x₃=1.247.
Но, думаю, ардуйне это не понять.
Ардуйня — такая ардуйня…
Ē-моē, там еще и C++! Вы б еще пхытон запихали на микроконтроллер! Жуть!!!
Модули ядра тоже разрабатывать значительно проще, чем в игропрошивке «драйвера» писать.
Документация удобная: набрал man что-то → получил.
Да и просто баш с coreutils — как вы там без них существуете? Кактусы грызете?
Тем более — работа с железом. Все-таки, прошивка для игровых приставок очень плохо выполняет роль операционной системы общего назначения!
Удобно.
Надо будет только с С++ на С переписать и вынести аппаратно-зависимые интерфейсы отдельно, чтобы базовый код можно было как на одноплатнике, так и на микроконтроллере применять.
Жаль, для работы с ЖК-экранами до сих пор не встречал приличных библиотек. Там уже стырить готовенькое не получится ☹
Вывод: отдельный поток должен постоянно опрашивать радиомодуль на наличие новых данных. Т.е. в отличие от UART'а, здесь просто нужно в цикле писать в SPI данные, затем проверять ответ. Вот в этом потоке пишите свои задержки в каком угодно количестве — на выполнение основного потока они не повлияют!
Скажем, как происходит работа с UART? Да элементарно: при помощи select (ну, на любителя: кому-то может eselect больше нравиться, а кому-то poll) проверяем, есть ли данные в буфере порта. Если есть, считываем их и заполняем промежуточный циклический буфер. А его уже обрабатываем: если нужно построчно читать, не принимаем данные, пока не появится конец строки; если посимвольно — считываем очередной символ и обрабатываем.
Можно вообще запихать работу в отдельный поток, который будет блокировать ввод-вывод. Но на работе основного цикла в main() это никак не скажется.
А вот если нужно много GPIO, то уже придется выбирать: либо к «малинке» или «кубиборде» подключать микроконтроллеры, либо сразу взять микроконтроллер с нужными интерфейсами.
Можно простой линейной интерполяцией прикинуть, чему будут равны корни. Навскидку, x₁=-1.802, x₂=-1.618, x₃=1.247.
Прерывания для кого придумали? Реализуйте конечные автоматы, а не черт-те что!