А когда пишешь на ардуино, подругому и не отладишь, Serial.write и всё.
Или вообще приходится мигать лампочками-ледиками.
Логику работы программы можно отладить и не в ардуине. А работу с периферией отлаживаешь при помощи осциллографа.
мажор с осциллографом в треде!
Он в любой лабаратории и сервис центре должен быть как расходный материал. Ты о чём?
Мажор как расходник?
А ты живёшь в лаборатории или в сервисном центре?
USB приставка с полосой в 20 мегагерц на два канала стоит 3к на алиэкспрессе.
Логический анализатор для МК поудобнее будет.
Попробуй отладить синхронизацию потоков.
Ардуино зло и должно умереть.
Для ардуино клепают очень много периферии с обвязкой, которую можно без особого труда подключить к чему угодно, не паяя при этом какую-нибудь ужасную мелкашку с ножками «снизу». Монополию они не создают, привлекают больше людей (тем самым удешевляя остальные материалы и давая набить «шишки» сообществу с новыми периферийными чипами). Не понимаю твоей ненависти.
Потому что она плодит ардуинщиков.
Потому что там стоят древнючие контроллеры которым место на свалке.
Потому что большая часть ардуиновой периферии - жуткое говно.
Потому что мне приходится за ардуинщиками разгребать этот пиздец.
Кстати, ничего жуткого в чипах с "ножками снизу" нет. Единственный страшный формат - BGA.
Потому что там стоят древнючие контроллеры которым место на свалке.
Потому что большая часть ардуиновой периферии - жуткое говно.
Потому что мне приходится за ардуинщиками разгребать этот пиздец.
Кстати, ничего жуткого в чипах с "ножками снизу" нет. Единственный страшный формат - BGA.
Про периферию. Есть такие драйверы семисегментников TIM1637, который по i2c позволяет подключить эти самые семисегментники. В ардуине есть аппаратный i2c.
Что делают в ардуине? Правильно, делают специальную библиотеку которая ПРОГРАММНО реализует i2c в библиотеке tim1637.h.
Занавес.
А контроллеры хорошие для учебных целей. Только учить надо не через dighitalwrite(), а через ассемблер. Впрочем для такого метода пойдет почти любой контроллер.
Что делают в ардуине? Правильно, делают специальную библиотеку которая ПРОГРАММНО реализует i2c в библиотеке tim1637.h.
Занавес.
А контроллеры хорошие для учебных целей. Только учить надо не через dighitalwrite(), а через ассемблер. Впрочем для такого метода пойдет почти любой контроллер.
Скорее ООП для МК зло. А ардуино это просто игрушка для детей, из чего следует сделать вывод что освоив игрушку не стоит лезть в серьёзные проекты.
но ведь лезут же
Значит отсеивают плохо, либо задачи ставят не по способностям.
что за вы тут хардкорные ребята. Сами что на МК в асемблере всё пишете?
И вообще ардуино не ООП, он его поддерживает, но можно писать и на чистом Си. И всё будет компилиться и работать как чистое Си.
https://arduino.stackexchange.com/questions/816/c-vs-the-arduino-language
Если на Си всё работает зачем замарачиватся с асемблером?
А ещё на ардуино очень удобно создавать набросок, а потом уже и лепить финальную улучшеную версию на нужный МК, используя ардуино для того что бы прошить чип. Я вот сейчас начал осваивать Attiny13a и отлично пилю говнокод на ардуине для тестов, а потом пилю финальную упрощённую версию и запиливаю в Attiny.
И вообще ардуино не ООП, он его поддерживает, но можно писать и на чистом Си. И всё будет компилиться и работать как чистое Си.
https://arduino.stackexchange.com/questions/816/c-vs-the-arduino-language
Если на Си всё работает зачем замарачиватся с асемблером?
А ещё на ардуино очень удобно создавать набросок, а потом уже и лепить финальную улучшеную версию на нужный МК, используя ардуино для того что бы прошить чип. Я вот сейчас начал осваивать Attiny13a и отлично пилю говнокод на ардуине для тестов, а потом пилю финальную упрощённую версию и запиливаю в Attiny.
Запись в последовательный интерфейс для отладки? Довольно странный способ, кмк, тем более, что аж целую периферию занимать (ног и так мало + мало места для дорожек, если плата не отладочная), запитывать (если речь об arm) и обрабатывать (возможно ещё и периферийными устройствами вроде кольцевых буферов), да ещё и питание согласовывать (особенно между 3.3 у платы и 12 у rs-232). Есть же ST для STM32 и JTAG для всего остального (софт openocd + gdb-remote), он и stdout нормальный даст.
PS: ардуино я рассматриваю как железо, их средства для разработки я не трогал, но хочется верить, что JTAG у них есть в нормальном виде. Если это не так, то мне жаль ардуинщиков — без отладчика чипы кажутся адом.
PS: ардуино я рассматриваю как железо, их средства для разработки я не трогал, но хочется верить, что JTAG у них есть в нормальном виде. Если это не так, то мне жаль ардуинщиков — без отладчика чипы кажутся адом.
Если брать ардуину в чистом виде, то там есть только маня-C и штука которая эту фигню шьет в ардуину.
Отладки нету, пины отладчика заведены кто куда (один из - точно на светодиод).
ЧСХ на ардуну можно и нормальные программы писать, но отлаживать все равно придется через uart, т.к. на ардуинах разъем под программатор/отладчик не распаян (хотя никто и не мешает люто-бешено внедрится программатором).
Вот как раз с ногами и периферией на современных контроллерах проблем не возникает. Особенно на этапе первоначальной разработки. У, наверное, самого распространенного контроллера современности (STM32F103C8T6 - полтора бакса на али за Blue Pill) аж 9 штук комуникационно периферии на борту (USB, 3x USART, 2x I2C, 2x SPI) (ДЕВЯТЬ, КАРЛ!) из которых одновременно можно, емнип, вывести 5.
Отладки нету, пины отладчика заведены кто куда (один из - точно на светодиод).
ЧСХ на ардуну можно и нормальные программы писать, но отлаживать все равно придется через uart, т.к. на ардуинах разъем под программатор/отладчик не распаян (хотя никто и не мешает люто-бешено внедрится программатором).
Вот как раз с ногами и периферией на современных контроллерах проблем не возникает. Особенно на этапе первоначальной разработки. У, наверное, самого распространенного контроллера современности (STM32F103C8T6 - полтора бакса на али за Blue Pill) аж 9 штук комуникационно периферии на борту (USB, 3x USART, 2x I2C, 2x SPI) (ДЕВЯТЬ, КАРЛ!) из которых одновременно можно, емнип, вывести 5.
Ну у старших говномег есть JTAG, хотя нафига лезть в эти 8 бит, у которых плюсов кроме того, что они от +5в умеют работать (и то, не ясно, плюс ли это) нету, особенно если с STM32 сравнивать.
Пфф. Дебажил проект exception'ами.
Исключения позволяют отловить известные и предсказуемые баги.
Писал на сях сервер стриминга видео с камеры в MJPG (где каждый отдельный кадр - самостоятельная картинка, пожатая жопегом). Сервер должен был работать на raspberry pi, так что ресурсов не ахти: четыре слабеньких армовых ядра. После того, как выяснилось, что сжатие большой картинки в 1080p занимает целых 0.2 секунды, стало ясно, что больше, чем 5 фпс, в таком режиме из сервера выжать не получится. Надо занять все ядра: читать данные из камеры с опережением, и пока одно ядро занимается сжатием предыдущего фрейма, давать другому ядру уже следующий фрейм. Несложно понять, что нельзя просто так взять, и давать читать фреймы подряд и сразу отправлять их на сжатие, нужно выбрасывать промежуточные фреймы, для сжатия которых нет ресурсов. Причем нужно вычислять, сколько фреймов выбросить, на основе среднего времени работы всех потоков сжатия на каждом ядре. Алгоритм реализован, но картинка выглядит слегка дерганной, будто между отдельными сжатыми жопегами проходит неравный интервал.
Что сделал бы нормальный человек? Вставил бы принты в каждом потоке с номером оного потока и дампом времени исполнения, построил бы график, да курил бы лог. Что сделал я? Добавил код, который выводит логический 1 или 0 на GPIO (аппаратные пины пая) для каждого потока, когда он работает, плюс чередование 1 и 0 когда приходит фрейм с камеры. Итого 5 пинов. Затем прицепил логический анализатор осциллографа и увидел в реальном времени картинку - вот красивый ровный прямоугольный сигнал, описывающий данные с камеры; вот два пина показывают, что воркеры работают, вот еще два пина для двух других воркеров - что они поработали, а потом стали пинать хуи.
Быстро, просто, эффективно.
Что сделал бы нормальный человек? Вставил бы принты в каждом потоке с номером оного потока и дампом времени исполнения, построил бы график, да курил бы лог. Что сделал я? Добавил код, который выводит логический 1 или 0 на GPIO (аппаратные пины пая) для каждого потока, когда он работает, плюс чередование 1 и 0 когда приходит фрейм с камеры. Итого 5 пинов. Затем прицепил логический анализатор осциллографа и увидел в реальном времени картинку - вот красивый ровный прямоугольный сигнал, описывающий данные с камеры; вот два пина показывают, что воркеры работают, вот еще два пина для двух других воркеров - что они поработали, а потом стали пинать хуи.
Быстро, просто, эффективно.
Закончилось все тем, что я перенес сжатие с процессорных ядер на гпу, и все стало еще быстрее. Однако сам алгоритм распределения фреймов остался прежним. Итого получилось аж 25 фпс fullhd.
Нормальное решение, чо.
Хинт: если на время выполнения какого-то периодического процесса поднимать пин в единицу а остальное время держать в нуле - загрузку процессора выполнением данного процесса можно смотреть даже не осциллом/анализатором, а тупо стрелочным показометром через RC-интегратор.
Тепло, лампово, наглядно :)
Хинт: если на время выполнения какого-то периодического процесса поднимать пин в единицу а остальное время держать в нуле - загрузку процессора выполнением данного процесса можно смотреть даже не осциллом/анализатором, а тупо стрелочным показометром через RC-интегратор.
Тепло, лампово, наглядно :)
Оно так и работает. Надо будет попробовать прицепить, с капом мелким еще, чтобы сглаживало метания стрелки.
> Писал на сях сервер стриминга видео с камеры в MJPG
> Что сделал бы нормальный человек?
Взял бы готовый mjpg_streamer наверно, или поискал еще какие-то аналоги, полюбому они есть. В крайнем случае собрал бы троллейбус. Четырехядерная малина вышла в 2015, а этот проект был уже в 2013. Да и ты знаешь о нем, даже коммитил в него год назад.
> Что сделал бы нормальный человек?
Взял бы готовый mjpg_streamer наверно, или поискал еще какие-то аналоги, полюбому они есть. В крайнем случае собрал бы троллейбус. Четырехядерная малина вышла в 2015, а этот проект был уже в 2013. Да и ты знаешь о нем, даже коммитил в него год назад.
Как ты думаешь, а почему я в итоге сел писать свое, раз даже знал об аналогах и в один из них коммитил? Я просто понял бесполезность этого занятия. Если посмотришь в код mjpg_streamer`а, то у тебя волосы дыбом встанут. Работает он примерно так же как и выглядит: виснет и течет. Он абсолютно ненадежен, содержит тонну легаси и странного кода из бородатых времен. Научить его в многопоточное сжатие не представлялось возможным, не говоря уже о сжатии на гпу. Я коммитил туда поддержку изменения разрешения на лету по сигналу с устройства захвата hdmi, и это само по себе оказалось полной трешаниной, поэтому проще было написать свой собственный сервер, чем исправлять чужие косяки: https://github.com/pikvm/ustreamer. По ссылке есть подробнее о мотивации и тех фичах, которые я в итоге сделал. Других проектов на эту тему нет. Много кто умеет стримать MJPG, но мало кто может делать это, как надо.
А ты ещё может умеешь кодить для куды или стримц?
Ни разу не пробовал.
Чтобы написать коммент, необходимо залогиниться