Xenia

Долго ждать не пришлось - сегодня вышел EWAVR32-320A. Как я и ожидала, добавили поддержку AT32UC3L. Support for new device families FlashVault support Improved trace support Updated Hardware Debugger Guide IAR Embedded Workbench supports all devices with AVR32A and AVR32B cores: AP7000 family: AVR32 AP7000, AP7001, AP7002 UC3 family: AT32UC3A0128, AT32UC3A0256, AT32UC3A0512 AT32UC3A1128, AT32UC3A1256, AT32UC3A1512 AT32UC3A364, AT32UC3A3128, AT32UC3A3256 AT32UC3A364S, AT32UC3A3128S, AT32UC3A3256S AT32UC3B064, AT32UC3B0128, AT32UC3B0256 AT32UC3B164, AT32UC3B1128, AT32UC3B1256 AT32UC3L016, AT32UC3L032, AT32UC3L064 http://iar.com/website1/1.0.1.0/124/1/

Скажите пожалуйста, оговорено где-либо в стандартах (не в даташитах!) пределы, в которых цифровой сигнал (как 5 вольтовый, так и 3.3 вольтовый) обязан интерпретироваться, как высокий или низкий уровень. Т.е. в каком диапазоне у них низкий и высокий уровни?

http://electronix.ru/forum/index.php?s=&am...st&p=614489

Сразу признаюсь, что ответов на ваш главный вопрос у меня нет, поскольку использую я не ADS1256, а ADS1255, у которого нет каналов, которые можно было бы переключать. Могу лишь ответить на этот: "Я, честно говоря, не понял, зачем посылать команды SYNC и WAKEUP, если им полностью эквивалентно управление синхронизацией через вывод SYNC/PWDN...". Здесь, думаю, причина в том, что ипользовать выводы микросхмы для этих целей не целесообразно, когда АЦП и МК гальванически развязаны. Чтобы управлять этими сигналами через пины, пришлось бы дополнительно развязывать еще две линии, а управляя ими программно (через SPI) можно обойтись одним элементом ADuM для развязки. Однако хотела бы спросить о причинах странности с сигналом SCLK, который у вас на осциллограмме желтый. 1) Там где идут отдельные пачки по 8, это понятно - передача байта. А отчего две последние пачки такие толстенькие? На 2 пачки по 8, следующие друг за другом, они не похожи - 16 импульсов в них нет, а есть где-то около 14. 2) Отчего SCLK в промежутках между передачами уходит на постоянный высокий уровень? Ведь если это CLOCK, стробирующий положительной полярностью, то и держаться он вроде бы должен низким уровнем, когда пассивен. А у вас не так. Почему? 3) Те две толстенькие пачки странны еще и тем, что заканчиваются высоким уровнем. Честно говоря, я в растерянности от случая, когда импульсы начинаются с нижнего уровня, а кончаются верхним. Как тут считать их количество?

Если с паяльником дружишь, то лучше всего купить готовую демо-плату. Например вот эту: http://www.olimex.com/dev/avr-p28.html . Вставляешь в ту панельку ATmega8 в DIP-корпусе (ее купить придется отдельно) и установка готова. Там только входы UART к панельке не припаены, хотя сопряжение от RS232 уже сделано. Этот небольшой недостаток проистекает из-за того, что в корпус DIP-28 можно разные микропроцессоры втыкать, а потому заранее неясно где будет TX и RX. Ну и программатор еще надо купить, самый дешевый AVR-PG2B - http://www.terraelectronica.ru/catalog_inf...class_19_2_26_3 В той же "Терраэлектронике" можно купить и то, и другое сразу. А вообще, совсем не важно, насколько сложен тот процессор, с которого начинаешь. Ведь никто же не заставляет разом использовать все его возможности. Начать лучше с того, чтобы заставить его "ножкой дрыгать" - светодиодиком моргать (на плате светодиод уже приделан). После этого процессор становится другом :), и всё остальное постигается в процессе решения конкретных приложений. Если с паяльником не дружишь, то можно купить наборчик с релюшками http://www.olimex.com/dev/avr-io.html , они хоть и не велики ростом, но на 220 вольтах работают. Можно сделать к Новому Году переключатель гирлянд, а если как следует покорпеть, то и светомузыкальную приставку. Только в эту панельку обычно тинька (ATtiny) лезет, а это очень слабенький микропроцессор. Ну а для полного кайфа можно купить вот это http://www.olimex.com/dev/avr-usb-stk.html - тут и USB, и читалка карт памяти и гнездо для подключения наушников. Из этой можно и MP3-плейер сделать, если постараться. Хотя я не уверена, что этот микропроцессор справится с декодировнием MP3. Ну в крайнем случае можно пока WAV-файлы проигрывать. Короче говоря, демонстрационные платы - просто находка для тех, кто хочет самостоятельно освоить микропроцессорную технику. Их всегда можно купить в магазине, а заодно к ним скачать с сайта компании-производителя готовую программку для этой платы и посмотреть, как она работает. Программку дают с исходниками, которые можно использовать для изучения программирования.

Ага, совсем :). REF нужен не для симметрии, а как эталон, с которым сравнивается измеряемое напряжение. И калибруется он по этому же напряжению. Обычно REFы ставят на половину шкалы или на целую шкалу, а для конкретного АЦП написано в его даташите. Отсюда ясно, что при нулевом REF АЦП работать не будет. Знаю три способа этого достичь: 1) Поставить на входе специальный операционный усилитель, способный делать измерямому напряжению подпор (например INA114). Если этому операционнику подать на ref-вход REF, то он на это напряжение и поднимет. Тогда на выходе ОУ и на входе АЦП будем иметь Uвх+REF или от 2.4 до 2.9 вольт в вашем случае. Однако будьте готовы кормить этот ОУ отрицательным напряжением питания, иначе он (и не только он) не станет работать с отрицательным входным сигналом. 2) Если земля АЦП развязана с измеряемым напряжением (т.е. питаются от разных источников питания, не имеющих общей земли), то есть совсем простой способ - подать измеряемое напряжение между REF и входом АЦП. Тогда REF автоматически будет прибавляться к входному напряжению. Но если у вас земли гальванически не развязаны, то таким соединением вы угробите источник REF-напряжения, замкнув его на землю. 3) Измеряемое напряжение подать между -IN и +IN, и измерять в дифференциальном режиме. При этом соединяя с REF среднюю точку (ее можно получить на делителе по 500 ком в каждом плече между входными контактами измеряемого напряжения). Эти напряжения могут быть разными, но земля у них одна. А разделили эти земли только для того, чтобы вы могли аналоговые элементы заземлить в одной точке, а цифровые в другой, а потом соединить между собой обе эти точки. Такова уж особенность минимизации попадания цифровых шумов в аналоговую часть. Имеено для этого, а не для того, чтобы вы между этими двумя землями втыкали лишний потенциал.

Когда команды примитивные (т.е. без параметров), и их число не превышает 256, то, несомненно, удобнее односимвольная кодировка - тут она самоя короткая. Но как только символов ASCII перестало хватать - приходится использовать слова, а тут уже потребуются какие-то разделители между ними: пробел, табулятор, символ конца строки и т.п. В этой связи вспоминается фраза на манер японских хайку: "Кончилось место на Z, Что же мне делать теперь? Ведь это последний..." :)

Ресет USB-устройства и ресет удаленного микропроцессора - вещи совершенно разные! Reset USB-устройства это разрыв логического соединения, а затем его новое соединение с повторным чтением всех дескрипторов и присвоением нового адреса (SET_ADDRESS). Эта процедура происходит на уровне протоколов. Напротив, ресет микроконтроллера означает его физический перезапуск, вследствие чего он имеет возможность запуститься с загрузчика. Никаким ресетом порта вам не заставить перезапусться микроконтроллер! Отвечу вам в тон: а что если тулза юзера сделает то же самое, что делает код вашей функции?

Это свидетельствует о ... высокой ответственности! :) Прежде чем пустить серию на продажу, она проходит тщательную предварительную проверку. А вы как хотели? Чтобы процессоры пускались в продажу с пустой ерратой, а недостатки выявлялись уже на том, что продано?

И чего народ так еррат боится? Их надо рассматривать не как недостатки процессора, а как недостатки даташита :).

В протоколе USB нет и не может быть такой команды, получатель которой делал бы себе харакири :). Поэтому копать надо не в сторону поиска такой экзотической USB-команды, а в сторону интерпретации уже имеющихся в протоколе команд. Например, интерфейсная команда SEND_BREAK используется крайне редко, вот на ее обработчик (в вашем USB-устройстве) вы могли бы повесить ресет (блокировать прерывания + поставить самый быстрый WatchDog + войти в вечный цикл). Тогда для ресета микропроцессора было бы достаточно послать на виртуальный COM-порт команду с помощью API-шной Windows-функции SetCommBreak. При этом нет необходимости делать интерпретатор идущего по линии потока данных, поскольку интерфейсные команды поступают иным путем. P.S. Только не забудьте, сразу же закрыть COM-порт (CloseHandle) со стороны компьютера, а после ресета снова его открыть, иначе после ресета USB-порт откажется разговаривать с устройством, позабывшим свой адрес. Т.е. рискуете тем, что устройство перезапустится на bootloader, но USB-канал зависнет в патовой комбинации, из которой выйти можно только вручную - выдернуть и снова воткнуть USB-кабель.

Вчера (!) выпущен AT32UC3L (в анонсах он был объявлен ранее). Пико-токопотребление (0.48 mW/MHz), 48 ножек, $1.96 (64K flash) и $1.47 (16K flash) в партии 10 тыс. шт. Источник - http://finance.yahoo.com/news/Atmel-Introd...ml?x=0&.v=1 , даташиты здесь - http://www.atmel.com/dyn/products/product_...sp?part_id=4591

Уже думала про это, но лениво было проверять :). А вот это как раз меня больше всего интересует! К сожалению, константы DeviceIoControl для СОМ-порта не описаны. Любопытно, что функция BOOL EscapeCommFunction( HANDLE hFile, // handle to communications device DWORD dwFunc // extended function to perform ); очень похожа на DeviceIoControl, поскольку значение dwFunc очень похожа по смыслу на констанды DeviceIoControl: dwFunc value: CLRDTR Clears the DTR (data-terminal-ready) signal. CLRRTS Clears the RTS (request-to-send) signal. SETDTR Sends the DTR (data-terminal-ready) signal. SETRTS Sends the RTS (request-to-send) signal. SETXOFF Causes transmission to act as if an XOFF character has been received. SETXON Causes transmission to act as if an XON character has been received. SETBREAK Suspends character transmission and places the transmission line in a break state until the ClearCommBreak function is called. CLRBREAK Restores character transmission and places the transmission line in a nonbreak state. К сожалению, нмчего похожего на SEND_ENCAPSULATED_COMMAND и GET_ENCAPSULATED_RESPONSE тут нет.

По одному символу, как правило, принять решение не удается. Приходится прочесть слово целиком, чтобы понять, что оно означает. И вообще, символ конца строки (Enter) это не просто символ, а символ ПОДТВЕРЖДЕНИЯ того, что бы сказано. До его появления программа не имеет права начать выполнение команды, даже если смысл ее вполне понятен. Например, компьютеру нельзя выполнять "FORMAT C:" :), пока не нажат Enter. А вы вознамерились по одному символу принимать решение. Компьютеру все равно, как было передано - отдельными символами или строкой, поскольку на физическом уровне в обоих случаях прием и передача ведутся по символьно. Точно так же и AVRка получает прерывания (если их разрешить) при поступлении очередного байта, не зная того, gets'ом или getchar'ом отправлялась посылка.

Кто знает, отчего берутся USB-запросы (CDC Class Requests): SEND_ENCAPSULATED_COMMAND GET_ENCAPSULATED_RESPONSE ? Обычно их не обрабатывают, но любопытно, для чего они нужны. Короче говоря, мой вопрос формулируется так: "Какую команду из Windows-API должно подать приложение, чтобы моя AVRка получила один из этих реквайстов?" И в частности, если у меня на USB организован виртуальный COM-порт. Как вызвать все остальные реквайсты я знаю, остались непонятными только эти. В книгах и исходниках эти два реквайста всегда упоминаются, однако ни слова не нашла про то, в связи с каким событием такие запросы посылаются. Драйвер, конечно, может послать любой реквайст, но остается неясным, как побудить драйвер к этому (я использую стандартный драйвер виртуального порта usbser.sys, встроенный в Windows).

Совсем запугали бедного Кулика :). Делать так, как он вознамерился - можно! Только никакая gets() тут не нужна, хватай символ из UDR1 - вот и вся процедура получения байта. Обычно, байтики, схваченные в прерывании кладут друг за дружкой в строку до тех пор, пока очередным байтом не окажется "конец строки" (Enter). Этот символ можно в строку не класть, а вместо этого заняться ее анализом и исполнением того, что эта строка означает.

В данном случае варианты компиляции выражения WDTCR |= (1<<WDCE) | (1<<WDE); несущественны, поскольку запись в регистр WDTCR всегда будет ПОСЛЕДНЕЙ инструкцией. А, стало быть, протяжка перед следующей строкой WDTCR = 0; зависит исключительно от сложности обнуления регистра. Дольше двух тактов это не затянется при любых способах оптимизации или отсутствия оной.

Докажите обратное! Приведите результат компиляции этих двух сишных строк, чтобы компилятор допустил больше одной промежуточной инструкции между записями в регистр WDTCR. Условия оптимизации можете выбирать любые.

Длиннее просто невозможно скомпилировать, т.к. операции с константами всегда производятся еще при компиляии, а не в runtime. Приведенная в моем прошлом посте компиляция одинакова как при отсутствии оптимизации, так и при оптимизации по скорости или размеру. Поскольку из-за примитивности примера ее невозможно оттранслировать ни длиннее, ни короче. Константы невозможно "приготовить заранее". Если вы намереваетесь поместить их в память, то вытаскивание оттуда обойдется дороже - тогда действительно в 4 такта можно не уложиться. А если положить в регистр, то примерно так оно и получится. P.S. Мой предыдущий пост, адресованный вам, был мною отредактирован. Ознакомьтесь с ним пожалуйста еще разик.

Вот, пожалуйста, результат компиляции на IAR EWAVR: WDTCR |= (1<<WDCE) | (1<<WDE); 00000000 B501 IN R16, 0x21 00000002 6108 ORI R16, 0x18 00000004 BD01 OUT 0x21, R16 WDTCR = 0; 00000006 E000 LDI R16, 0 00000008 BD01 OUT 0x21, R16 - между записями в регистр WDTCR только одна лишняя команда. Итого всего 2 такта между операциями записи. А про оптимизацию вы не совсем правы, когда речь идет о записи в регистры, то компилятор (IAR) никогда не опускает присваивание, даже если оно повторное. И это при любом типе оптимизации - как по размеру, так и по скорости. Однако не забывайте название темы - сказано, что WatchDog запустить удалось. А, значит, компиляция велась в условиях, когда требование 4-х тактов соблюдалось. Поэтому это условие я не стала особо оговаривать.

А вы пытались останавить его тоже комбинацией или простой записью? Может быть так попробовать: WDTCSR |= (1<<WDCE); WDTCSR = 0; или так: WDTCSR |= (1<<WDCE) | (1<<WDE); WDTCSR = 0; Только не забудьте прерывания блокировать на время исполнения этих двух строк. Ну в крайнем случае так: cli(); wdt_reset(); MCUSR &= ~(1<<WDRF); WDTCSR |= (1<<WDCE) | (1<<WDE); WDTCSR = 0; sei(); Ну тут уж кажется всё предусмотрено с запасом...

Кстати, у AT32UC3 на борту имеется 16-bit Stereo Audio Bitstream – Sample Rate Up to 50 KHz. Что такое битстрим и чем он от PWM отличается, я так и не поняла, но этот МК позиционируется как раз для высококачественных аудиопроигрывателей с закачкой контента из интернета (видимо для этого у него еще и Ethernet на борту). А ваша MSP 16 бит на 50-ти мегагерцах потянет? :)

А что, разве АРМы превосходят АВРы в том, что биты поштучно из памяти таскают? :)

Несуразности возникают только в сознании :), когда путают переменную типа bool и операцию с битами. ЛЮБАЯ ПЕРЕМЕННАЯ - это одна или несколько ячеек памяти, а потому быть тождественной с битом она принципиально не может. А если нужны операции с битами, то это делается не с помощью bool-типа, а с помощью побитово расписанной структуры. Например: struct mystruct bool a : 1; bool b : 1; bool c : 1; bool d : 1; bool e : 1; bool f : 1; bool g : 1; bool h : 1; ) flag; Вот тут уже все становится ясно и компилятору, и процессору, и программисту - видно, что в памяти ассигнован блок в один байт (8 бит), из которого велено таскать биты. Ни у одного процессора в мире нет в памяти однобитных переменных. И это уже потому, что память побитно не адресуется. Однако компиляторы обычно предоставляют пользователям удобные способы работы как с битами, так и с битовыми полями (см. мою предыдущую реплику). Однако надо понимать, что делается это "через ухо", т.е. компилятор достает слово памяти целиком, а потом вырезает из него нужные биты. Модификация бита стоит еще дороже - сначала процессор прочитывает целиком слово памяти, к которому этот бит относится, при помощи операций or и and модифицирует в нем нужный бит или группу битов, а затем записывает модифицированное слово обратно в память. Инструкции ряда микропроцессоров (и AVR в том числе) позволяют модифицировать отдельные биты в собственных регистрах и портах, только в этом случае битовые операции над ними реализуются эффективно. Поэтому битовые флаги лучше всего держать в регистрах, а не в памяти. Во всех же остальных случаях, выгоднее не экономить на спичках, а заводить переменную bool типа. Такая кодировка действительно оказывается избыточной, зато ее применение компенсируется максимально высокой скоростью использования. Можно с полным основанием считать, что тип bool является атрибутом оптимизации как по скорости, так и по объему кода, когда как его недостаток состоит лишь лишнем расходе памяти.

Грустно, что обсуждение перешло обсуждение на размерности булевской переменной. По всей видимости, это произошло из-за того, что участники дискуссии путают "битность" процессора и шириной шины данных. Между тем, как это вещи в общем случае разные. Разрядность регистров процессора может превосходить ширину шины данных (т.е. сетку физической адресации памяти), но наоборот быть не может. В своё время процессор i80386SX уже имел 32-разрядные регистры, когда как работал с 16-разрядной шиной памяти. Такая ситуация означает лишь необходимость в наличии инструкций по чтению/записи старшей и младшей части регистра и их комбинацию, обеспечивающую двухступенчатый обмен между целым регистром и двумя последовательными ячейками памяти. Вопрос о размерности булевской переменной связан исключительно с шириной шины памяти. Не процессор виноват в том, что один бит из памяти он достать не может, а вынужден читать или писать целиком область памяти, равную разрядности шины данных - это атрибут памяти, которая не может считываться или записываться побитно. При этом заметим, что и от адресации памяти (виртуальной) размер булевской переменной не зависит. Адресация памяти может быть побайтная, в то время как шина данных быть в 4 байта. Такая ситуация мешает процессору сразу записать байт в память, а вынуждает его сперва прочитать из нее 4 байта, потом заменить один из байтов на новый, и уж только затем записать назад эти 4 байта. Как видим, операция с булевскими переменными становятся неэффективными, если размерность такой переменной отличается от ширины шины данных. Причем это же касается и операций с текстовыми символами, которые в практическом отношении встречаются гораздо чаще, чем булевские переменные. Возвращаясь к микропроцессорам замечаем, что разрядность шины данных у них обычно мала. Т.е. данные передаются во внешнюю память силами одного, максимум двух портов. Например, у AVR32 шина данных памяти 16 бит (шину адреса я не посчитала). Это означает, 3что 32-битность на память не распространяется, поскольку ФИЗИЧЕСКИ память обменивается с процессором сразу 2-мя байтами. Стало быть и булевская переменная, если уж она так сильно вам нужна, будет в данном случае иметь 16-битную размерность. Гораздо более существенным вопросом, чем размерность булевской переменной, является вопрос о размерности АДРЕСА памяти, что в первую очередь определяется максимальным объемом рабочей памяти. У AVR32 этот адрес занимает 24 бита. Именно отсюда и возникает преимущества 32-битности, что адрес целиком помещается в регистр. Тут уже не надо маяться, работая с адресом, как регистровой парой (операция по ее инкрементированию более сложна). Ну а главное все-таки арифметика! Все мы знаем, что размерность произведения вдвое больше размерности данных. Вот тут-то длинные регистры очень кстати. И, наконец, преимущества длинных регистров поймут все те, кто хотя бы краешком глаза заглядывал на то, как реализуется в библиотеках эмуляция работы с плавающей точкой.