CD_Eater

Очень хочется покидать камушки в огород тех, кто пишет на Си и верит в миф о лёгком портировании кода. Нет возражающих? Ну, тогда начну. Недавно на телесисях была поучительная ветка. Вот она http://telesys.ru/wwwboards/mcontrol/1809/...es/173406.shtml Прочитайте её, интересно. Прочитали? Тогда продолжим. Это почти классический пример - ЯВУ скрыл от программиста важнейшую деталь реализации: с виду атомарная инструкция "PORTB ^= 1" на самом деле оказалась неатомарной, и автор совершенно не ожидал, что здесь придётся заботиться о корректном доступе к общему ресурсу (порту B ) в многопоточной среде (фоновая задача + обработчик прерывания). Если бы человек писал на ассемблере, он бы легко увидел эту потенциальную "борьбу за ресурс" и принял бы обычные в таких случаях меры. Не исключено (хотя маловероятно), что автор предвидел эту возможную угрозу, но понадеялся, что компилятор достаточно умный и автоматически выберет самый оптимальный вариант реализации, то есть, "PINB = 1", сделав операцию атомарной (разумеется, компилятор сделал бы это из соображений оптимизации по скорости/размеру кода, а не из заботы об атомарности). Для нас важно одно: простые и однозначные с виду операции ЯВУ могут (в зависимости от компилятора и железа) оказаться вовсе не такими простыми и однозначными. Теперь представьте такую ситуацию. У Вас есть Сишный исходник и Вы портируете код проекта на другой МК. Разные не только МК, но и компиляторы. Предположим, что в проекте встречается ситация, аналогичная приведённой выше: в фоновой задаче и в обработчике прерывания используется нечто вроде "PORTB ^= 1", но в предыдущей реализации (при старом МК и старом компиляторе) эта операция была атомарной, а в новой реализации (на новом МК и новом компиляторе) перестала быть атомарной. Вопрос: заметите ли Вы это??? При переносе исходника Вы успешно подправите имена портов, замените где нужно номера битов этих портов, но придёт ли Вам в голову менять стандартную Сишную инструкцию "PORTB ^= 1" на какую-то другую? Да никогда в жизни! И программа успешно скомпилируется, и на Вашем столе она заработает без ошибок, и пирожок с полки Вы возьмёте, преисполненный гордостью за умение легко портировать программы. А потом, через месяц-другой, придут недобрые вести с поля - что-то там не фурычит. Приезжай, творец, разбирайся что натворил - изредка бывают сбои. Спорим, что первое, на что Вы подумаете - это на недостаточную помехозащищённость Вашего девайса. :) Вероятность того, что прерывание попадёт внутрь Read-Modify-Write последовательности, достаточно мала и при тестировании обнаружена не будет, но вот в поле (помножьте эту вероятность на тысячу устройств, которые Вы уже изготовили и внедрили) уверенно даст о себе знать. Пока Вы, начиная с мыслей о помехозащищённости, дойдёте до реальной причины неисправности, пройдёт порядка месяца, не меньше, т.к. это очень труднообнаруживаемая ошибка. Вы вряд ли станете искать ошибку в софте, т.к. при портировании код фактически вообще не был изменён, а в предыдущей реализации сбоев не было. Возможно, ошибку так и не найдёте, но будете всем рассказывать сказки про плохую помехозащищённость или ужасную глючность новых МК... Имхо: Надеяться на лёгкую портируемость проектов с одного МК на другой - это путь в страну Грабляндию. Создавая проект, пишите его применительно к данной задаче и для данного МК. Если всё же придётся переносить на другой МК, переносите только блок-схему алгоритма, заново наращивая "скелет" деталями реализации. Чаще всего придётся даже немного изменить алгоритм работы, приспособив его к особенностям новой периферии (например, использовать не поллинг пина по таймеру, а функцию захвата и т.п.). P.S. Сейчас меня обвинят в том, что я не люблю или не умею писать портируемые программы, что большинство программистов в мире пишут только портируемый код, и что за портируемым кодом будущее. В ответ замечу одну большую разницу - не сравнивайте программирование для PC и для МК. Легко портируются те программы, которые фактически не зависят от аппаратуры, например, математические вычисления (БПФ, фильтры и т.п.). Большинство программ для МК сильно зависят от железа. Правильный с точки зрения программирования подход к созданию легко портируемого кода состоит в том, чтобы выделять в отдельные функции (возможно, inline-функции) всё обращение к периферии, и при каждом портировании переписывать эти функции полностью. Причём для одной и той же операции, например, для "PORTB ^= 1", должны присутствовать две функции: одна реентабельная (для случаев типа нашего), другая нереентабельная, зато быстрая (для обычного однопоточного программирования). Тогда проблем будет гораздо меньше, но программы перестанут быть эффективными. Короче, стандартная ситуация с плюсами и минусами универсальности (тут очень в тему будут слова автора с ником -=Shura=- про джаву - искать гуглем по сайту телесистем фразу "anal sex")...

Для больших пакетов рулит Adler32 (скорость вычислений на порядок выше CRC). Если Вам 32 бита много, то можно по аналогии со стандартным Adler32 сделать "Adler16". Коротко: Adler - это Флетчер, но по простому модулю.

Не могли бы пояснить, почему Вы так думаете?

:bb-offtopic: Подтверждаю. Из своего немалого опыта программирования для PC вынес (правда, не сразу) эту же мысль - чем больше времени потратишь на тщательное продумывание программы (прежде чем прикасаться к клавиатуре), тем меньше общее время "продумывание+написание+отладка+доведение_до_ума".

xml-ка должна быть, но её там нет. Ни tiny48, ни tiny43

Интересно! Они хотят упростить и без того дешёвую мегу48. Куда ещё дешевле то? Действуют так, как будто хотят завоевать весь мир рынок 8-битных МК. Ну, мы только "за". Любопытная деталь - трёхбайтовая сигнатура tiny48 меньше, чем mega48P, это значит, что в планах инженеров Атмела tiny48 был уже тогда, когда ещё не было picopower-овых клонов атмег. Оп-с. Он 12-МГцовый. Значит, сэкономить решили ещё и на тестировании чипов. Блин, он что, полбакса стоить будет???

Да, раньше на экспорт были разрешены только криптосистемы с не более чем 40-битными ключами. Не знаю, как сейчас обстоит дело с 56-битным DES. Возможно, уже разрешили. Кстати, как наличие этих криптофункций отразится на цене чипа? Это было бы желательным расширением периферии, только если оно на халяву...

Ваши требования взаимно противоречивы. 1) Если критичным параметром является время реакции на внешнее событие, и мы говорим о величинах порядка 250 нс, то обработчик прерывания фактически должен "ничего не делать". 2) Если же Вы завели разговор о сохранении в стеке десятка регистров, то забудьте про 250-наносекундное время отклика (регистры сохраняли в стеке неспроста, видимо, сначала будет выполнен нехилый кусок кода, и лишь затем сможем дать корректный ответ на внешнее событие). Выберите что-нибудь одно. Upd. Как классно в Xmega-х сделали I/O Memory !!! Отвели нижние 16 регистров (побитово адресуемых) для нужд юзверя! Фактически, вдобавок к РОНам теперь есть ещё 16 почти-регистров с однотактовым доступом. Upd2 А однотактовый DES послужит хорошим генератором псевдослучайных чисел :)

Зачем же в прерывании, которое почти ничего не делает, сохранять десяток регистров в стеке? У АВР достаточно регистров, чтобы пару из них выделить для эксклюзивного использования в "узком" обработчике. И вообще, мсе писал, что решил задачу поллингом. Получить время отклика 250 нс при поллинге на 20 МГц АВРке - не проблема. Именно на это обстоятельство он справедливо указывает. То есть, обошлись однобаксовым чипом. :) Жаль только, что х-меги уйдут из ниши "проворных восьмилапов", и даже "20-лапов".

Интересно, почему в презентации график "CPU Usage vs USART baud rate (without DMA)" нелинейный? Или график специально загнули для усиления визуальной разницы между двумя кривыми? Ох уж эти маркетологи-пиарщики... Знаю, сейчас скажете "а вдруг это логарифмический масштаб". Только естественно ли выражать линейные зависимости (например, закон Ома) на нелинейных сетках?

Не буду заводить новую тему, спрошу здесь. Возможно, сам Prottoss и ответит. В некоторых проектах obdev МК питается напрямую от 5 вольт USB, что позволяет увеличить тактовую частоту МК и этим уйти от напрягающей проблемы "как уместить цикл в 8 тактов". Однако Osamu Tamura пишет: The Vcc should be lower than 3.6V to avoid SYNC errors. И наверное, неспроста пишет. Поясните plz, какие там возможны проблемы, если 3.3 вольтовый сигнал уверенно принимается типичной АВРкой при 5 вольтовом питании?

Да.

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

Ценой удивили. А как там с обвязкой? Тинькам-то для работы обвязка совсем не нужна (кроме последовательной памяти)... Не спорю, просто вопрос изначально поставлен про несложные компактные девайсы, стоимость которых меньше 5$.

proba - STR75x, M16C SasaVitebsk - LPC2106 То есть, Вы вышли за рубеж $5 (даже $10). Мне хотелось бы остаться. :)