SII

А сравнить SCR1 с Cortex-M0/M1 не корректнее будет?

У меня тоже какая-то проблема была, но не помню, как решил. Скорей всего, слепил свой проект без всяких там IP -- просто на уровне исходников впихнул (а может, вообще на Спартане-3Е делал в ИЗЕ...)

В СыстемВерилоге.

Ну, во-первых, можно с сайта АРМа и/или Хилинха скачать. А во-вторых, собственно дешифрованные исходники ядра я выкладывал в закромах. Пы.Сы. Кстати, о корках. У АРМа вроде как и Кортех-А5 дают. Кто-нибудь пробовал?

В Тумбе-2 есть и 2-, и 4-байтовые команды, только 2-байтовые -- в чистой Тумбе (если BL рассматривать как две двухбайтовые, какой она изначально -- в ARMv4T -- и была). Насколько эффективно компилятор умеет этим пользоваться -- вопрос. В частности, для эффективного использования нужно отдавать предпочтение регистрам R0-R7, используя остальные лишь в крайнем случае, так как почти все 2-байтовые команды не имеют работать с "верхними" регистрами. Поправочка: Cortex-M3 и большая часть других. Но, например, Cortex-M7 -- суперскалярный (две команды за такт, если звёзды сходятся).

Если говорить про собственно язык, то эти вещи с не меньшим успехом можно и на Си++ писать. Другое дело, что, например, если пишешь что-то для ядра Линуха, ты должен соблюдать требования этого проекта -- а там пишут на чистом Си. Но это, повторюсь, не технический вопрос, а организационно-идеологический.

Вообще-то достаточно давно уже C++20 имеется... А "быть в тренде" сегодня -- это какой-нибудь Питон тянуть всюду, в т.ч. и на МК, так что я уж никак не в тренде. И таки да, я не вижу ни одной причины в наши дни и на сколько-нибудь современной платформе, для которой имеется вменяемый инструментарий не из прошлого века, использовать чистый Си. Ну то есть вообще ни одной. Всё это я прекрасно понимаю, но, тем не менее, много раз за свою жизнь сталкивался с ситуацией, когда начальство было склонно платить куда больше за "красивые картинки", хотя любому специалисту было бы очевидно, что реально сложная работа -- отнюдь не там.

Там полно удобных и полезных вещей и помимо классов. Ну а писать можно и на Фортране, например. Потому что работу оплачивают почти всегда ни в чём не разбирающиеся менеджеры. Они видят красивую картинку в браузере -- о, крутая работа, заплатим бабло. Ну а что они в ПЛИС увидят? Ничего -- а значит, и платить им не очень-то хочется. Сфера применения гораздо шире. На голом Си, считай, только под МК и пишут -- и то больше из-за инерции и нежелания изучать новое; никаких препятствий к использованию там Си++ нет. Скорей, C#, но никак не плюсы.

Вообще-то ПЛИС и линух -- это тёплое против мягкого... Нужно всё, поэтому специалист в любой области будет востребован. Только нужно помнить, что специалист != обладатель диплома.

Это не ардуинщики, это абдуринщики... Ибо слепить своё даже на Арудино требует всё ж знать кой-что из теории -- в отличие от тупого повторения чужого. Ага, ржём. Ибо как-то ухитрялись подключать к нему не только память. Ага, именно что к его шине адреса (а также к шине данных и шине управления). И работало, как ни странно. Вероятно, мы что-то делали не так.

А ещё неплохо было бы посмотреть справочные данные микросхем. Ибо ВНЕЗАПНО обнаружится, что 176-й серии подавай питание 9 В (и логические уровни соответствующие), 555-й -- 5 В, а всякие там STM32 и ПЛИСины в общем случае не выше 3,3 В. А вообще, накал бреда знатный. Давно такого читать не приходилось :)

А на высоких частотах и/или длинных линиях -- ещё всякие импедансы и прочая чёрная магия :)

Это всё написано в даташитах на конкретные МК.

Я подозреваю, что даже при обмене ПЛИС-STM32 по обычному SPI пропускная способность будет выше, чем ногодрыгом на достаточно широкой шине (скажем, 16 битов данных). Программный ногодрыг -- он очень тормознутый...

Да как ни делай, скорость обмена будет в разы или в десятки раз ниже, чем при прямом подключении памяти к ПЛИС. Собственно, память всегда должна подключаться к процессору как можно более прямым образом, а раз предполагается сделать процессор на ПЛИС -- то к ней и надо цеплять память.

Если использовать C++11 или более позднюю версию стандарта, то там уже есть стандартные средства для управления выравниванием (ключевое слово alignas), которые можно использовать с любыми более-менее современными компиляторами (на то они и стандартные -- в отличие от __attribute__ и т.п. конструкций). Как в чистых сях, не знаю, ибо не использую, но, возможно, там аналогичное тоже ввели. Ну и стоит помнить, что компилятор-то сгенерирует код для невыровненного доступа, но исполнен он может быть не на каждом МК (в частности, ядро Cortex-M0 на такое не способно).

Насколько помню, обычная ФАТ32 просто не поддерживает файлы больше 4 гигов. Из-за этого, в частности, есть определённые проблемы с установкой последних версий Винды с флэшки (наиболее простое решение в этом случае -- отформатировать флэшку в НТФС). С моей точки зрения, правильней было б в самой прошивке Вашего устройства время от времени закрывать текущий выводимый файл и открывать новый. Скажем, если там есть часы, делать это при смене даты -- получится по одному файлу на сутки.

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

А можно и не счётчик, а хранить это состояние на четырёх триггерах и сделать логику их переключения. Машину состояний, в общем.

Кстати говоря, в основном из-за ёмкости ЭСЛ в несколько раз быстрей ТТЛ, хотя и те, и другие выполнены на одинаковых, в общем-то, биполярных транзисторах, и во много-много-много раз быстрей КМОП (при условии использования более-менее сходных техпроцессов, конечно: сравнивать по скорости работы 7-нм МОП-транзисторы современности с биполярными образца конца 1960-х годов не совсем корректно). Просто в ТТЛ транзистор либо полностью открыт, либо полностью закрыт, и переход из одного состояния в другое требует довольно много времени, в т.ч. для заряда/разряда паразитной ёмкости. В МОПах ёмкость уже не паразитная, а основа его принципа работы -- и она существенно больше, из-за чего скорость переключения много меньше. Ну а в ЭСЛ транзисторы никогда полностью не закрываются и не открываются, а лишь больше или меньше приоткрыты -- отсюда высокая скорость переключения и огромное энергопотребление. Собственно, именно по последней причине вся современная цифровая электроника сделана на КМОП, индивидуально ЭСЛ по скорости вроде так и осталась непревзойдённой, если говорить о классической полупроводниковой электронике.

Нужно проводить различие между логическими уровнями, т.е. как что-то воспринимается "извне" схемы, и внутренними принципами работы этой самой схемы. В подавляющем большинстве случаев логические значения задаются именно напряжениями, при этом ток как таковой роли не играет. Например, в классических ТТЛ любое напряжение, установившееся на входе или выходе схемы и не превышающее 0,8 В считается логическим нулём, а не ниже, кажись, 2,4 В -- логической единицей; в древних ЭСЛ (где полярность питания отрицательна -- сейчас они обозначаются NECL) нуль, если правильно помню, в районе –0,8 В, а единица -- примерно –1,6 В, ну и т.д. Хотя бывают и случаи, где "действующим" является не напряжение, а именно ток: скажем, у достаточно популярной "в древности" токовой петли нулики и единички кодировались либо наличием тока (обычно в районе 20 мА), либо его отсутствием, при этом напряжение само по себе роли не играло. А вот "внутреннее использование" токов и напряжений прямо определяется физическими принципами работы. Скажем, если схема построена на биполярных транзисторах, то ток через транзистор регулируется током же, а вот если на лампах или полевых транзисторах -- то уже напряжением. Хранение же информации -- это вообще отдельная тема. Если в обычных триггерах, на которых построены регистры или там статическая память, действуют обычные токи или напряжения (они ничем не отличаются от любой другой электронной схемы, выполненной по данной схемотехнике и технологии), то, например, в динамической памяти, построенной, по сути, на конденсаторах, хранятся уже заряды, а не токи или напряжения.

ARMCLANG 6.16.

В порядке флуда: если с Мальты логистику проблемно организовать, поскольку это -- остров, то как с Тайванем-то проблему решили? Он же тоже остров. И Япония, и Англия с Ирландей. Да и Южная Корея, в силу политических причин, работает в режиме острова... А вот Белоруссия и Россия таки да -- материк-с. Может, это с островов на означенный материк перевозки затруднены? :)

У меня в этом проекте вообще мистика :) На -O0 или -O1 -- всё нормально. При -O2 или -O3 на дисплей цвета выводятся инвертированными. Естественно, стал разбираться, и первое, что обнаружил -- в буфере информация корректная. А сам вывод у меня по DMA идёт, так что вроде бы изменяться значения ну никак не могут (тем более, что картинка на своих местах и т.п. -- а значит, команды дисплею выдаются корректно, а выдача-то производится тем же самым DMA!). Вот сейчас малым ходом ползу и разбираюсь, во что компилятор превратил мой быдлокод...

Хм... про время выхода из цикла не подумал... Спасибо за идею.