xvr

Посмотрите на Коды Флетчера. Очень быстрые и не требуют таблиц для подсчета

О! Помню случай из своей практики: Делали по заказу одного научного учереждения (АН СССР, давно это было) драйвер пьезокерамического излучателя (как бы это назвали сейчас). Частоты были относительно невысокие, так что схема была весьма простая - мост с автокоммутацией на тиристорах и повышающий трансформатор после него (до нескольких КВ). Были так же амперметр и вольтметр для мониторинга. На приемке девайса заказчик захотел узнать мощность, закачиваемую в излучатель. На предложение перемножить ток на напряжение, нам было отвечено про 'косинус фи'. Для замера этого самого косинуса, заказчик взял осцилограф, подал ему на X и Y сигналы пропорциональные току и напряжению, вооружился линейкой и собрался измерять диаметры эллипса :rolleyes: После включения установки на экране осцилографа отобразилось нечто, отдаленно напоминающее знак '&' Потом он долго искал, где у 'этого' какие оси, так и не нашел :cranky:

А можно узнать нафига это надо? Я к тому, что если вам надо сделать станок с ЧПУ, то одного двигателя мало. А если надо просто поиграться, то можно и к кнопке присоединить. Озвучте требования к параметрам сигнала управления, в частности стабильности частоты и фазы. Если стабильность фазы не требуется, то можно подключиться к RS232 (TX). Выдаете в порт 0x0F - получаете один импульс, выдаете 0x33 - получаете 2, максимум при 0x55 - 4 импульса. Меняя скорость порта и набор выдаваемых данных можно управлять частотой и фазой (к сожалению фазой - не очень точно, из за наличия стартовых и стоповых битов)

Советую взять скриптовый язык помощнее (например Perl с www.activestate.com http://downloads.activestate.com/ActivePer...x86-287188.msi), все ваши вопросы (кроме снятия скриншота) сразу решатся

Похоже на Манчестер Этого мало, нужна какая то известная синхропоследовательность в начале. Или очень длинная последовательность. Еще надо знать частоту сигнала данных (хотя бы приблизительно) ФАПЧ вам поможет

У радио и ИК реализации есть один серьезный недостаток. Рассмотрим такой сценарий использования: 1) Студент приходит в аудиторию, берет пульт 2) Нажимает кнопку 3) Кладет пульт в карман и уходит :05: Можно даже прикинут период полураспада пула пультов :(

Операторы << и >> осуществляют форматированный обмен с файлом (т.е. в виде текста), вне зависимости от режима открытия файла. А ничего не читает оно потому, что бинарные данные ну никак на текстовое представление float не похожи.

Нету их. Они появляются после того, как BIOS в PC выполнит код инициализации, который находится в ROM BIOS Extension на самой карточке. Кто у вас будет выполнять этот код? А без него карточка останется куском мертвого железа. Есть такие, по ногам и всему процему они пожалуй переплюнут AVR :rolleyes: Рекомендую почитать стандарт PCI - такие мысли сразу отпадут :cranky: Угу, 1 FPS хватит? Если нужно больше - берите какой нибудь DSP PS. Тут в прошлом году какой то парень пытался сам сделать процессор, не ваш родственник случайно? :laughing:

В связи в этим несколько вопросов. Зачем он в винде ищет sys_open() и подобные вещи? Как объяснить этой библиотеке, что у нас Win32 и попросту не может быть подобных функций? (ну или как ему их подсунуть?) У вас как то подцепились stream функции из стандартной библиотеки C++. Они не относятся к Linux'у, и вполне имеют право быть и в Винде.

Родные Xilinx кабели комплектуются именно таким разъемом (IMHO). Скачайте UG на какой нибудь из них - там есть распиновка разъема

Очень похоже на LD (Ladder Diagram) : Ladder Diagram — Википедия Moderator: Бездумное цитирование удалено

jed файл можно прошить только родными тулами от Xilinx (IMHO). Это весьма немалый кусок от WebPack'а (не 2.5Г, а всего около 1Г :07: ) iMpact называется xsvf - это бинарный вид файла svf (тоже произведение Xilinx), оригинальный svf может шится практически любым JTAG прошивальщиком. Для xsvf у Xilinx есть С'ные тексты для embedded прошивальщика, по поводу не embedded - ничего сказать не могу :( По поводу прошивки - лично я шил через STAPL player от Altera (он понимает Xilinx LPT II шнурок, и размерами НЕИЗМЕРИМО меньше, чем iMpact).

Это С++ (или С99). Ни один эмбеддед чистый С компилятор это не поддерживает :05: Это есть, но не смертельно. Кроме того, в последних версиях уже появились переменные в EEPROM (вот только не помню, в PICC или только в PICC 18)

Эээ, а чего в нем нельзя? Угу, есть проект - таймер для солярия. Там некоторая интерактивная часть - для задания времени и количества интервалов загара, а так же для определения рабочих секций УФ ламп. Меню совсем немного, собственно таймера тоже немного, и остальной интерактив. Всего около 600 строк на С. Полностью забитая PIC16F628

ЛИЧНО сражался с сервером, который НАОТРЕЗ отказывался воспринимать 0В как mark, так и не работал, пока ему -3В не подали :(

Хм. У вас только СТРОКИ из самого меню забьют эту самую память программ (1 символ - 1 слово) Меню надо кодировать максимально компактно, switch'и из программы убирать. Структура описания меню должна быть такая, что бы размер занятой памяти программ был равен количеству символов + несколько байт на каждый элемент меню (чем меньше, тем лучше). Код обработки меню не должен зависить от размера собственно меню. В любом случае в 628 пик много не влезет :( Можно попробовать 648 пик. В качестве компилятора лучше взять HI-TECH PICC, он пожалуй наилучший

Для XPower нужна реальная схема на реальной частоте с реальными входными воздействиями (из симулятора). Иначе он будет считать погоду на Марсе, а не потребление вашей схемы.

Хочу добавить еще один совет в копилку безопасного сек... отладки (для слаботочных схем, питаемых от 220В) - включайте вашу схему через обычную лампу (ватт так на 100). Тогда при проблемах в схеме вы буджете наблюдать не феерверг из силовых транзисторов, а красивое зажигание лампочки :)

Это не есть макрос - он заменяет не макровызов (по ID макроса), а обычную ассемблерную комманду call

Thnx, не знал, добавлю в копилку :beer: Но по сравнению с тем, что способен сделать компилятор - это всетаки 'не оптимизация' B) Оптимизации такого уровня способен делать любой компонент в цепочке компиляции, например в Sun'овском ассемблере он мог делать inline подстановки специальных функций (они были описанны в специальных файлах) вместо их вызовов

Я являюсь :) Это не совсем точное высказывание :( Код может оптимизироваться на этапе линковки, но занимается этим не линкер, а все таки компилятор. И тот 'код', который оптимизируется, на самом делен не код, а промежуточное представление компилятора. Вне зависимости от того, нравится это или нет, оптимизациями занимается компилятор, когда бы он не запускался :1111493779: Пример: Hi-TECH PICC-18 Pro. Результатом независимой компиляции модуля (.c) является файл (.p1) с промежуточным представлением С'ной программы. На этапе сборки (линковки) они ВМЕСТЕ обрабатываются компилятором, который и генерит выходной код. Другой пример: Intel C компилятор. Опция -ipo (или -fast) переводит компилятор в режим компиляции всей программы. При этом, компиляция собственно модулей (.c) производит .obj файлы, в которых НЕТ кода, зато есть секции с промежуточным представлением программы. На этапе линковки снова вызывается компилятор, который читает все это из .obj файлов и генерирует код (в виде одного .obj файла, на этот раз с кодом) который уже и отправляется линкеру. Что касается опции 'MSVC++ 7.0 /ltcg' то сдается мне, что это не опция линкера, а опция ВСЕГО проекта, и подавать ее надо везде. Реализация (скорее всего) будет очень похожа на реализацию в Intel компиляторе Единственная известная мне 'оптимизация' именно ЛИНКЕРА - это выкидывание неиспользуемых кодов и данных из исполняемого файла. Но у меня язык не повернется назвать это 'оптимизацией' :(

Пардон, имелся в виду их потомок - VAX (кажется у него было нечто похожее)

Нет. Компилятор ОБЯЗАН обеспечить состояние переменных, видимое с точки зрения программиста, в любой точке программы. volatile всего лишь заставляет компилятор считать, что состояние переменной может быть изменено не только тем, что написанно в программе. Т.е. компилятор не имеет права выкидывать любые записи и чтения этой переменной. Но он не обязан каким либо другим способом синхронизировать доступ к ней - это обязанность программиста. Например, если мы имеем код a=1; ... a=2; ... a=3; то для не volatile переменной компилятор может оставить только последнее присваивание (если в промежутке не было вызовов других функций), для volatile все присваивания останутся От количества модулей это не зависит. А вот качество оптимизации может зависеть.

Похоже, что FLASH шьется 16ти битными big endian словами. Возможно что где то нестыковка при формировании из них 32х битного слова. Где именно нестыковка непонятно, возможно просто при показе, а FLASH на самом деле прошит правильно :rolleyes: Могут, но мне они неизвестны :( Могут быть баги и фичи big endian тулчейна на little endian хосте

Objcopy от native платформы или от toolchain'а, которым собирали elf? Могут быть разногласия :) Вам уже писали, что порядок похож на PDP - 16ти битные слова внутри 32х битного слова - в LSB, байты внутри 16ти битного слова - MSB EA 00 00 12 -> EA00 0012 -> 0012EA00 Типичная LSB <-> MSB конверсия У JTAG прошивальщика нет опций для указания трактовки endianess'а файла? Кстати, он шьет именно бинарник, а не hex? В hex есть опция для упаковки по 16ти битным словам, может получится именно это