Комментарии 33
Извините, но матрица с адресными диодами + ATTINY45/85 сделает все тоже самое гораздо быстрее и в RGB (причем можно даже без библиотек), а использовать для такой задачи такой мощный проц да еще и обычные светодиодные матрицы - я даже не знаю что сказать.
Вообще-то статья не о камнях и светиках. Так что об этом и говорить не стоит - даже если и знаешь, что сказать.
Любой инструмент хорош, если его применять по назначению. Для данного проекта идеальный МК - тот который лежит на расстоянии вытянутой руки. Гляньте последние абзацы, кстати, там как раз безбиблиотечный результат.
Ну мне, как инженеру-программисту жалко проц, который 99.99999% времени проводит в idle)
Это как гончая, которая сидит дома и ее не пускают на улицу.
Для каждой задачи есть свой инструмент, это точно, но здесь, имхо, микроскопом гвозди на 80 вгоняются в бетон одним ударом.
Именно этот проц большую часть своей активной жизни проводит в брейкпойнте под отладчиком, и это не первая и не последняя его прошивка )
Ну еще лет пятнадцать назад многие микроскопы подешевели, и стали дешевле молотков. У вас не было проектов, где в толстом SoC используется одно-два ядра из 4-6? Я с этим в промышленной разработке сталкиваюсь постоянно.
Хм, не доводилось. Но у меня обычно крупносерийка в проектах. Ядер свободных не наблюдал. Но вот запас по памяти двух, трехкратный - это в порядке вещей. Но это тоже не от разгильдяйства - уменьшение номенклатуры на складах, оптовые закупки всё такое. Вообще, когда в проекты вмешивается экономика - всё становится гораздо интереснее. Учитывается даже минимальная необходимая квалификация разрабов для поддержки проекта и сложность входа в проект.
Вот из-за экономики предпочитаю заниматься всякой мелкосерийкой для измериловки или военки - стоимость комплектухи не на первых местах, можно выбрать подходящий камень, не смотря на цену. Был опыт, когда себестоимость одной железки для крупносерийного производства надо было утолкать в 75 баксов. Не хочу его повторять.
А по мощности используемых чипов - в 2009 вроде бы году был провал по поставкам AVR, когда они свой последний завод продали, и свежевышедшие stm32f100 оказались вдвое-втрое дешевле привычных атмег. Куча разработчиков тогда переехали на arm, хотя стм-ки для тех проектов были сильно избыточные и вполне себе выглядели микроскопами вместо молотков.
или военкиА потом, внезано — невыездной 15 лет ))
Обошлось )). Вообще много где можно выше 3 формы не залезать.
Для второй формы - 5 лет. Ну и в зависимости от обстоятельств можно и при увольнении оформить бумагу, что реального доступа к гос. тайне не имел.
Я на это немного по другому смотрю. Воспринимаю бизнес-ограничения просто как дополнительный фактор разработки. Как повышенную ударопрочность или расширенный диапазон температур, например. Но шансы пощупать что-то пожирнее при таком подходе заметно снижаются, конечно. Зато на фундаментальном уровне приходится разбираться более детально.
В один байт оно не помещается, полсердечка - 5x8 точек. Так что это плюс 8 байт к прошивке, а анимация от этого проще бы не стала, даже наоборот, ибо она симметрична. Так что проще оказалось именно зеркалить видеобуфер на финальном этапе. Возможно, стоило положить его "на бок". Можно бы было еще 3 байта отжать. Впрочем, код открыт. Может, кому будет интересно поэкспериментировать.
Так что это плюс 8 байт к прошивкеДаже не знаю, что сказать :)
Я не в теме современной низкоуровневой разработки на микроконтроллерах, так — библиотеками развлекаюсь. Потому любопытно, сильно ли это отличается времен DOS, когда массив передавали в видеопамять через указатель и он просто «появлялся» на экране. Может и здесь такое работает?
Может и здесь такое работает?
Пожалуй, аналогия уместна. Если, предположить, что SPI-прослойка - это уже генерация видеосигнала, вместо VGA. Но для МК - это только один из возможных путей. Т.е. здесь приходится писать не только "DOS-программку", но еще и саму DOS, и прошивку к видеокарте. Спасает только то, что весь функционал писать не надо, а только то, что нужно здесь и сейчас.
Еще мысль.
Можно же не удалять библиотеки из проекта целиком, а оставлять в них только инициализацию устройств и те 2-3 функции, которые нужны. Остальное просто стереть из файла. Исполняемый файл получится в разы меньше, ибо компилироваться будет не вся либа, а процентов 5 от нее, но сохранится удобство высокого уровня, когда все передается через удобные аналоги print()
Видеопамять во времена DOS аппаратно отображалась на физическое адресное пространство — видеоконтроллер "слушал" системную шину и перехватывал обращения к определённым адресам. При этом, подозреваю, поначалу оперативной памяти на этих адресах не было физически. А потом пришлось настраивать чипсет чтобы тот "не пускал" запросы к определённым адресам в оперативную память, во избежание конфликта.
Ключевым моментом тут является то, что видеопамять физически находится в видеокарте, а отображение так или иначе работает за счёт вклинивания в системную шину.
Особенностью микроконтроллеров является то, что память у них внутри, как и системная шина. Наружу не "торчит" ничего хотя бы отдалённо напоминающего шины адреса и данных, все ножки по максимуму отданы под GPIO. Как в этих условиях делать отображение чего-то на память? Никак, оно и не делается.
Автор явно упоминает, что взаимодействие с дисплеем идёт по SPI. SPI — это последовательный интерфейс на 4х проводах.
подозреваю, поначалу оперативной памяти на этих адресах не было физически
По началу, как раз, это и была самая обычная оператива, просто периодически, соблюдая тайминги, её сканировал видеоконтроллер (если его можно так назвать) и превращал байты в видеосигнал. На ПК типа Спектрума эту память спокойно можно было пользовать для своих нужд, если, конечно, вас не смущала каша на дисплее.
Про библиотечный код: если взять библиотеку на шаблонах C++ (хотя нужным оказался только SPI и GPIO), то со стандартным стартапом получилось 1136/60.
Регистры vs библиотеки на примере сердечек