потому что пишут это непрофессионалы

а моя либа будет озвучена только профессиональными программистами!

и будет иметь полторы функции в отличии от ардуины которая имеет тысячи библиотек

важно количество или качество?

очень зависит от подхода.

сейчас во всём мире ориентация на количество

важно количество или качество?

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

Я как бы за, давай запилим. Но чтоб было просто и эффективно - придётся много согласовывать

и будет иметь полторы функции в отличии от ардуины которая имеет тысячи библиотек

тысячи библиотек, только каждый дисплей это новое апи и новое всё. нельзя подменить один .h на другой и завести новый дисплей без перековыривания всего кода работы с дисплеем. и так во всём

Я как бы за, давай запилим. Но чтоб было просто и эффективно - придётся много согласовывать

Буквально свой стандарт изобрести

тысячи библиотек, только каждый дисплей это новое апи и новое всё. нельзя подменить один .h на другой и завести новый дисплей без перековыривания всего кода работы с дисплеем. и так во всём

я уверен там есть коллекции драйверов с общим апи где что-то подобное сделали, какая-нибудь мета-библиотека

тысячи библиотек, только каждый дисплей это новое апи и новое всё. нельзя подменить один .h на другой и завести новый дисплей без перековыривания всего кода работы с дисплеем. и так во всём

Увы, так и есть. Единое верхнее апи - круто, но как обобщить работу напр с условным дисплеем от 3310 и каким-то цветным 5и дюймовым? Не отговариваю, но интересен твой взгляд

А вот моя одна секретная идея могла бы порешать такое

Увы, так и есть. Единое верхнее апи - круто, но как обобщить работу напр с условным дисплеем от 3310 и каким-то цветным 5и дюймовым? Не отговариваю, но интересен твой взгляд

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

А вот моя одна секретная идея могла бы порешать такое

слежка за шлюхой? -_-

Нет, у меня есть одна задумка, которая позволит, в теории, делать очень быстро разные штуки и комбинировать разные ЯП и не важно обычной комп это или мк

расскажи срочно!

или таки секретно?

Нет, у меня есть одна задумка, которая позволит, в теории, делать очень быстро разные штуки и комбинировать разные ЯП и не важно обычной комп это или мк

виртуализация

Пока нет, я хочу все обдумать и, может, когда-то начну делать

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

Допустим, а плюсы уже нормально поддерживаются всеми компиляторами под мк? И как быть с нижним драйвером - для ногодрыга и дма всё равно писать придётся по отдельности. Тут особенности железа пойдут. И дма те у всех по разному настраиваются

Допустим, а плюсы уже нормально поддерживаются всеми компиляторами под мк? И как быть с нижним драйвером - для ногодрыга и дма всё равно писать придётся по отдельности. Тут особенности железа пойдут. И дма те у всех по разному настраиваются

я на плюсах писал для стм32 и для ефм32, ну то есть любые cortex-m поддержаны. остальные не проверял, но препятствий не вижу. нижний уровень пишется один раз (ну ладно, не один, но всё же) под конкретную линейку чипов. для стмок нужно примерно 5 немного различающихся халов. очень хочется, чтобы это хотя бы было не впустую. а мысль идёт дальше: в идеальном мире llvm компилер под железо пишется самим разработчиком железа. здесь могло бы быть примерно так же. чтобы апи этого хала стал стандартным, и диктовал другим рельсы, по которым ехать

да, диктовать я люблю :3

я на плюсах писал для стм32 и для ефм32, ну то есть любые cortex-m поддержаны. остальные не проверял, но препятствий не вижу. нижний уровень пишется один раз (ну ладно, не один, но всё же) под конкретную линейку чипов. для стмок нужно примерно 5 немного различающихся халов. очень хочется, чтобы это хотя бы было не впустую. а мысль идёт дальше: в идеальном мире llvm компилер под железо пишется самим разработчиком железа. здесь могло бы быть примерно так же. чтобы апи этого хала стал стандартным, и диктовал другим рельсы, по которым ехать

Самими разрабротчиками железа - ага, да)) пусть хоть доки в одном стиле верстают

ну это я помечтал

естественно, не будет никогда так

я на плюсах писал для стм32 и для ефм32, ну то есть любые cortex-m поддержаны. остальные не проверял, но препятствий не вижу. нижний уровень пишется один раз (ну ладно, не один, но всё же) под конкретную линейку чипов. для стмок нужно примерно 5 немного различающихся халов. очень хочется, чтобы это хотя бы было не впустую. а мысль идёт дальше: в идеальном мире llvm компилер под железо пишется самим разработчиком железа. здесь могло бы быть примерно так же. чтобы апи этого хала стал стандартным, и диктовал другим рельсы, по которым ехать

И экраны требуют иногда временных интервалов. Нопы и циклы отпадают, нужно втаскивать таймер мк. Тут опять же у всех - по разному. А если выйти за рамки стм32 то вообще хз

Получается, приходим к халу от ст

скрыть реализацию за тредами в ртос. там всё равно обычно есть какие-то границы у этих интервалов

довольно широкие

Получается, приходим к халу от ст

кажется, мы скорее приходим к плис.

скрыть реализацию за тредами в ртос. там всё равно обычно есть какие-то границы у этих интервалов

Т.е. без ртос эту либу уже никак не завести?

И экраны требуют иногда временных интервалов. Нопы и циклы отпадают, нужно втаскивать таймер мк. Тут опять же у всех - по разному. А если выйти за рамки стм32 то вообще хз

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

Т.е. без ртос эту либу уже никак не завести?

давно пришёл к мысли, что новый проект нужно начинать с git init и копирования фриртоси.

Как бы да, но диспетчер - это уже доп расходы. Неужели так мало проэктов без ртос?

диодные мигалки разве что?

я тут неделю назад детей совращал

про ртос им рассказывал

и заставлял делать любые проекты только через неё

Ок, а какой минимальный обьём она может занимать в мк, не помнишь? Мне больше 2-4кБ флеша жалковато

блиин, у меня была охрененная табличка про всякие такие либы но пропала :(

помню, в недавней статье на хабре мелкие ртоси оценивали в <1кБ!

диспетчер это простая штука.

Ну и тогда лучше на фриртос не завязываться, а просто определить ф-ии которые хз кто должен уметь реализовывать. С указанием нюансов

помню, в недавней статье на хабре мелкие ртоси оценивали в <1кБ!

Да, есть такое

А может кто-то уже реализовывает твою идею, а мы просто не в курсе?

вполне возможно. найти бы их и влиться и помочь

очевидно, в моей идее тоже куча изъянов, но потому я и не сижу на ней и бешено вращаю глазами, а спрашиваю вас и предлагаю обсудить

Во! Как только все изъяны будут найдены, а идея выживет - значит концепция достигла идеальности, заслуживает права на жизнь и можно смело браться за реализацию

диодные мигалки разве что?

(забавно, что я рассказывал детям про ртос именно на примере диодной мигалки, которую без операционки сделать тяжелее, чем с ней)

Одно время приходила идея написать плагин поддержки Cortex-М4 для HiASM, но много дел да и лень. Может кому интересно будет про HiASM - ребенком начинал с него учиться прогать - очень интуитивно там всё, но о нём мало кто знает.

Видел много зачатков универсальных либ, смотришь - о, круто, красавчег,... последний коммит 4 года назад( и понимаешь - хм, наверное что -то не пошло.. А почему? Идея вроде норм была.. И вот не понятно

Одно время приходила идея написать плагин поддержки Cortex-М4 для HiASM, но много дел да и лень. Может кому интересно будет про HiASM - ребенком начинал с него учиться прогать - очень интуитивно там всё, но о нём мало кто знает.

Кек, сам начинал))

То, с чем разобрался чисто интуитивно без туторов и доков. А потом пошёл в универ и стал учить С чтоб вкатиться в мк

Ардуины то ли не было, то ли дорогая была.. Да и не слез бы наверное

С каким трудом заставил себя пересесть с авр на стм32!

Одно время приходила идея написать плагин поддержки Cortex-М4 для HiASM, но много дел да и лень. Может кому интересно будет про HiASM - ребенком начинал с него учиться прогать - очень интуитивно там всё, но о нём мало кто знает.

На счёт мало кто - хз, примеров там тонны уже

Не, людей то много, но нет широкой осведомленности. Ни один мой знакомый не знает о нем

есть ощущение, что чат реально уже требует разделения. только точно так же уверен, что это будет началом конца.

Ну, а толку? Чатики про электронику уже есть, чатики про фуррей - тоже, многие местные сидят и там, и там. От того, что появится ещё по одному чатику про то и про другое интереснее не станет.

Видел много зачатков универсальных либ, смотришь - о, круто, красавчег,... последний коммит 4 года назад( и понимаешь - хм, наверное что -то не пошло.. А почему? Идея вроде норм была.. И вот не понятно

И я тоже начинал пилить что-то универсальное, чтобы сделать мир лучше) Всё упирается в то, что нужно много людей заражённых одной идеей, и желательно не просто людей, а профи. Потому что надо провести титаническую работу по формализации подходов, а потом наполнять библиотеку кодом - а это значит, надо писать код, документацию, тесты, очень много сил нужно. Одному, да в качестве pet-project с выделением небольшого времени это быстро превращается в уныние, и постоянные вопросы себе : "зачем я это делаю?", "А надо ли оно кому то?", "А вдруг я как-то криво делаю?"

тысячи библиотек, только каждый дисплей это новое апи и новое всё. нельзя подменить один .h на другой и завести новый дисплей без перековыривания всего кода работы с дисплеем. и так во всём

Даже если взять не дисплеи, а просто i2c микрухи - их тысячи, а i2c блок не очень то отличается между вендорами мк +-. Казалось бы, что мешает реализовать низкоуровневые функции работы с i2c по разу для каждого семейства вендора, а потом наполнять библиотеку i2c устройствами по одному api? Сделать правила для контрибьюта и охватить тысячи микросхем

Вот нашел что-то подобное, и даже живое https://github.com/jrowberg/i2cdevlib Но не уверен насколько хорошо и правильно они идут по этому пути

Алсо, если делать слишком универсально, Линукс получится.