Я накатал больше 500 тысяч километров на 4 машинах. На первых 3 попадал в аварии, где, слава богу, кроме железа никто не пострадал, И пару раз спасся просто чудом. Но был абсолютно уверен, что я то водить умею. Потом слегка поумнел и на крайней машине за 5 лет — тьфу тьфу тьфу — ничего и рядом не было. А все го лишь снизил среднюю скорость передвижения на 20 км/час — почти до рекомендованой. Надеюсь что к Вам придет понимание не в результате жуткой трагедии.
Я пока не видел системы, в которой одновременно есть устройства и с B и с L-endian. Если знаете такую, скажите, может, мне просто везло. И если такая есть, то какой способ можно предложить вместо превратившихся в тыкву битовых полей? Маски с пробелами и чередованием старших и младших битов?
Системная плата это еще и мосты и память и FLASH и интерфейсы. А ничего из вышеперечисленного у нас нет. Хотя Модуль заявил что мост для своего камня он сделал. Тем не менее вышесказанное не означает, что свой процессор нам не нужен, а все лишь напоминает, сколько всего еще нам нужно разрабатывать.
То есть пока смею настаивать — при соблюдении должных мер предосторожности битовые поля очень удобный инструмент.
Можно перефразировать известное изречение «Битовые поля — наихудший способ, если не считать всех остальных»
Замечание верное, но все таки среди разработчиком МК не так много людей, получающих ищвращенно удовольствие от издевательства над разработчиком устройств и, как правило, порядок битов в регистре подразумевает нативный порядок байтов. Другое дело, что многие ядра поддерживают любой порядок байтов, ну так и следует выбирать такой, который не приведет к разрыву полей.
Я доброжелательно отношусь к критике, но во втором случае если бы ВЫ показали, как можно хорошо сделать при помощи битовых масок, я бы согласился, а пока что — согласится с мыслью о вредности вывода не могу.
А вот такое решение я не увидел.
Неплохо, совсем неплохо и битовая природа хорошо видна и наращиваемость очевидна. И в моем стиле попробую прокомментировать последнюю строку: -1 там стоит для того, чтобы при нулевой маске сообщить об ошибке получением отрицательного значения.
совершенно верно когда переносил руками ошибся в первом макросе должно быть ~(MASK-1) & MASK, спасибо, исправляю
Ну и прерывистые битовые поля я не рассматривал, поскольку с ними что делать вообще непонятно.
этот метод я конечно нашел, но речь то идет о красивых решениях ))
а не в переборных, а этот можно и упростить, если работать по байтам, но коряво до ужаса
Вот так всегда у меня — сначала разъясняю то, что более-менее очевидно, а потом, увидев много букв, начинаю пропускать необходимые вещи. В последнем абзаце я на них намекнул, наверное надо было поподробнее.
У TI теперь (спустя год после снятия Stellaris) есть МК с PHY в серии TIVA-C. например XXM4C129 — неплохой кристалл.
Я все таки даю TI шанс исправиться ).
У ST, насколько я знаю, так и не появилось среди Cortex-M моделей
Файловая система была взята изначально для того, чтобы делать удобную отладку — переткнул карточку, скачал файлы, проконвертировал и смотри, почему образы битые и тд.
Когда отладка закончилась, думал о варианте без FAT, но поскольку и все так заработало, до конца идею не довел.
В общем, как всегда — временное решение, превратившееся в постоянное )
На самом деле поток не был НАСТОЛЬКО интенсивным постоянно.
Это было устройство перехвата сканов в Xerox, и такая интенсивность шла только при потоковом сканировании, поэтому пиковая производительность была требованием ТЗ.
Реальную загрузку копировального аппарата Вы представляете.
Кроме того, были приняты следующие меры: SD карточка была предварительно размечена на 1000 файлов ( с именами data000.dat — data999.dat — недостаток фантазии у меня) и в дальнейшем директория не менялась, что исключало деградацию системной области, а запись шла со смещением последовательно во все файлы, то есть каждый кусок пространства FLASH использовался в 1000 раз медленее входного потока. Пометка о занятости файла содержалась в нем самом, а не в какой то общей области, и при включении в оперативной памяти создавался своего рода каталог, с которым и работали.
Были приняты меры по контролю состояния файлов (тайминги записи и отсутствие ошибок) с выключением данного файла из обслуживания, но за время работы 10 устройств в течении года (пока шел авторский надзор) ни разу не сработали.
Так что в общем было многое сделано для предотвращения деградации носителя. На этапе отладки я делал тестовое устрройство, которое имитировало скан каждые 1.6 секунды и прогонял такой режим непрерывано 2 недели. Потом SD исселедовал на наличие проблеммных зон (по сравнению тайминга до и после тестов) и отличий не обнаружил.
Можно перефразировать известное изречение «Битовые поля — наихудший способ, если не считать всех остальных»
Я доброжелательно отношусь к критике, но во втором случае если бы ВЫ показали, как можно хорошо сделать при помощи битовых масок, я бы согласился, а пока что — согласится с мыслью о вредности вывода не могу.
Неплохо, совсем неплохо и битовая природа хорошо видна и наращиваемость очевидна. И в моем стиле попробую прокомментировать последнюю строку: -1 там стоит для того, чтобы при нулевой маске сообщить об ошибке получением отрицательного значения.
Ну и прерывистые битовые поля я не рассматривал, поскольку с ними что делать вообще непонятно.
а не в переборных, а этот можно и упростить, если работать по байтам, но коряво до ужаса
Спасибо за добрые слова
Хотя «лучше» в данном случае понятие весьма относительное и субъективное
Просто он у меня в макросе забит и я про него забыл.
Я все таки даю TI шанс исправиться ).
У ST, насколько я знаю, так и не появилось среди Cortex-M моделей
Когда отладка закончилась, думал о варианте без FAT, но поскольку и все так заработало, до конца идею не довел.
В общем, как всегда — временное решение, превратившееся в постоянное )
Это было устройство перехвата сканов в Xerox, и такая интенсивность шла только при потоковом сканировании, поэтому пиковая производительность была требованием ТЗ.
Реальную загрузку копировального аппарата Вы представляете.
Кроме того, были приняты следующие меры: SD карточка была предварительно размечена на 1000 файлов ( с именами data000.dat — data999.dat — недостаток фантазии у меня) и в дальнейшем директория не менялась, что исключало деградацию системной области, а запись шла со смещением последовательно во все файлы, то есть каждый кусок пространства FLASH использовался в 1000 раз медленее входного потока. Пометка о занятости файла содержалась в нем самом, а не в какой то общей области, и при включении в оперативной памяти создавался своего рода каталог, с которым и работали.
Были приняты меры по контролю состояния файлов (тайминги записи и отсутствие ошибок) с выключением данного файла из обслуживания, но за время работы 10 устройств в течении года (пока шел авторский надзор) ни разу не сработали.
Так что в общем было многое сделано для предотвращения деградации носителя. На этапе отладки я делал тестовое устрройство, которое имитировало скан каждые 1.6 секунды и прогонял такой режим непрерывано 2 недели. Потом SD исселедовал на наличие проблеммных зон (по сравнению тайминга до и после тестов) и отличий не обнаружил.