xvr

Сам стек должен быть внутри, иначе этот контролер вырождается в набор проводов Это ChipSelect, выбор контролера, clock должен быть заведен отдельно

4 шины для обмена со стеком слишком много, достаточно 2х - данные для записи и прочтенные данные Адрес лучше проверить снаружи, в сам контролер завести только cs Какие подготовки, какие передачи данных Такое впечатление, что у тебя в стеке конвеер стадий на 10, не меньше :) Чтение и запись производятся НЕПОСРЕДСТВЕННО при выставлении сигналов rd/wr. Запись данных производится в этом же клоке (данные должны уже стоять на шине), чтение можно производить уже на следующем клоке (на данном клоке прочтенные данные фиксируются на выходной шине) Адреса на будет, будет один сигнал cs

Господа, уже закачавшие этого монстра :) Подскажите - он уже научился SV понимать, или придется и дальше ждать?

На подавляющем большинстве современных процессоров "unsigned int" будет занимать 4 байта, что делать с оставшимися 2мя байтами из "unsigned int"? И как нужно сравнивать - на равенство или на больше/меньше? Лучше спроси сколькими способами это можно сделать :) (Предполагаю, что сравнивать нужно "unsigned short" - оно как раз 2 байта) unsigned short val2check; // Это сравниваем unsigned char val2cmp[2]; // То, с чем сравниваем typedef struct { unsigned char s1; unsigned char s2; } S2; typedef union { unsigned short sh; unsigned char ch[2]; S2 s2; } U3; void compare(void) { U3 u3; unsigned short sh; // 1й способ u3.sh=val2check; if (u3.s2.s1==val2cmp[0] && u3.s2.s2==val2cmp[1]) ... // 2й способ u3.sh=val2check; if (u3.ch[0]==val2cmp[0] && u3.ch[1]==val2cmp[1]) ... // 3й способ u3.sh=val2check; if (memcmp(u3.ch,&val2cmp,sizeof(val2cmp)==0) ... // 4й способ if (memcmp(&val2check,&val2cmp,sizeof(val2cmp)==0) ... // 5й способ if ((val2check&0xFF)==val2cmp[0] && ((val2check>>8)&0xFF)==val2cmp[1]) ... // 6й способ if ( ((unsigned char*)&val2check)[0]==val2cmp[0] && ((unsigned char*)&val2check)[1]==val2cmp[1]) ... // 7й способ u3.s2.s1=val2cmp[0]; u3.s2.s2=val2cmp[1]; if (u3.sh==val2check) ... // 8й способ u3.ch[0]=val2cmp[0]; u3.ch[1]=val2cmp[1]; if (u3.sh==val2check) ... // 9й способ memcpy(u3.ch,val2cmp,sizeof(val2cmp)); if (u3.sh==val2check) ... // 10й способ sh=val2cmp[0]|(val2cmp[1]<<8); if (sh==val2check) ... // 11й способ ((unsigned char*)&sh)[0]=val2cmp[0]; ((unsigned char*)&sh)[1]=val2cmp[1]; if (sh==val2check) ... // 12й способ if (*(unsigned short*)val2cmp == val2check) ... } Можно наверное и еще способов придумать, но надеюсь этих хватит

Ни в чем - они и есть кластеры (но не всегда на x86 платформе) Обычно их не покупают, а делают под конкретную задачу. Вряд ли кто будет делать кластер специально, что бы продавать его машинные часы :) Но если он уже есть и не очень нагружен, то вполне возможно. PS. Загляни на сайт http://www.top500.org

В разделе для поиска документации смотреть не пробовали? http://electronix.ru/forum/index.php?showtopic=44895

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

По диодам, не по MOSFET'ам (или я что-то пропустил?)

Не надо ударяться об ножку стула :) В любом случае удар обо что-нибудь вполне можно отличить от нормального (не ударенного) движения, по тем же ускорениям.

Я имею в виду что так как полевой транзистор со стороны затвора представляет собой емкость (и весьма приличную), то его скорость открывания/закрывания напрямую зависит от тока, который будет вкачан в затвор в процессе включения/выключения. С выхода микроконтролера можно получить около 20ма (и то, если получится), с выхода одного из перечисленных мною драйверов - до 1.5А. Разницу во времени включения можете прикинуть сами :)

Ну тогда вообще проблем никаких - подключить модуль стека прямо к проводам и формировать на них необходимые сигналы.

Как предполагается задавать шину I2C - как ноги SDC/SDA или как абстрактый модуль с каким угодно интерфейсом не подключенный вообще ни к чему?

'Более крутыми' - это сколько (в ns)? Какое падение напряжения допустимо на транзисторе? Зависит от транзистора. Зайдите на сайт любого производителя силовых полевых тр-ров (например www.irf.com) и подберите по вкусу (например: IRLZ24N IRLZ24NL IRL530NL IRL530N) Схема включения будет зависить от требуемой крутизны фронтов. Для получения максимальной крутизны рекомендую специальные драйвера для управления ПТ (например MC33151DG, MC34151DG, MC34152DG или MC33152DG )

Кстати, по поводу мышиных потрохов для определения положения: можно не заниматься вивисекцией, а взять MEMS акселерометр и гироскоп (например у AD). Точности наверное хватит.

Код предполагается синтезируемый или это чисто поведенческая модель? Если первое, то надо считать, что это может быть реальной плисиной :) Я имел в виду контролер между физическими выводами I2C (SDC,SDA) и контролером стека. Или шину I2C тоже предполагается сделать на поведенческом уровне (т.е. без выводов вообще :) )? Опыт - дело наживное

Предлагаю объединить контролер стека с самим стеком, ибо я не предсталяю их отдельной реализации. Они и вместе вряд ли займут более 10 строк кода Хм. До сих пор я считал, что это очевидно. Кроме того, я слабо представляю, как их можно сделать иначе :05: Этого в оригинальном задании не было. Других добавлений, кроме нескольких стеков, не предвидится? А как вы собираетесь общаться с I2C шиной без контролера?

Т.е. предполагается 3 устройства (I2C контролер, контролер стека, стек)? В таком случае одно из этих устройств лишнее - просто набор проводов Не совсем понимаю, что такое 'шина передачи данных', но если под этим понимается 3х стабильная двунаправленная шина, то вне зависимости от того, как передаются сигналы rd & wr в данном дезайне такая шина будет лишним усложнением. Да Это сложнее реализовать Завершится, но master, начавший цикл, получит ошибку обмена. Ок, это даже проще Похоже на набор проводов :) Или это имеется в виду контролер I2C? Слишком усложнено. Все сравнения адресов и машинерия с I2C шиной должна остаться внутри I2C контролера. Наружу нужно выдать уже голые команды чтения и записи в стек. Интерфейс будет один в один совпадать с интерфейсом стека (за исключением направления сигналов - оно будет противоположным) Если сделать отдельно интерфейс к I2C и потом его пристыковывать к стеку, через еще один модуль, то придется реализовавать более-менее полноценную имплементацию протокола I2C со всеми ACK/NAK, подсчетом принятых и переданных байтов, т.к. цепи генерации ACK будут находится в другом модуле и придется всю эту логику протаскивать через интерфейсы 2х модулей. При этом реально это все будет не нужно, т.к. пользователь у шины I2C в вашем случае один, и набор требований у него фиксированный, т.ч. можно сделать под него урезанную имплементацию I2C PS. Реализация стека здесь тривиальная, по сравнению с реализацией I2C контролера.

Включить 1 резистор последовательно с питанием - это 'сложновато'? :07: Если нужно померять 'для себя' (а не самим процессором), тогда включи амперметр (можно мультиметр в режиме измерения тока) между источником питания и ногой питания процессора. Можно вообще включить амперметр последовательно в разрыв провода, подводящего питание к всей плате, но так измерится ток, потребляемый ВСЕЙ платой, а не только процессором. PS. Если слова 'амперметр', 'мультиметр', 'последовательно' тоже кажутся слишком сложными, то советую почитать какой-нибудь букварь по электрическим цепям уровня Дворца Юнных Техников. PPS. 'Электрические цепи' не имеют ничего общего с цепями, которыми обматывают колеса и ограды :)

Это устройство включает непосредственно стек, или сам стек это еще одно устройство? Устройство (равно как и все остальные) рекомендуется делать синхронным, т.к. почти все современные схемы синхронные. С этим как раз все просто - гораздо проще сделать 2 раздельные однонаправленные шины, чем одну двунаправленную, к которой понадобятся дополнительные сигналы для управления направлением передачи данных. Кроме того, во многих FPGA просто нет внутренних шин с 3мя состояниями. Это не существенно, добавится один компаратор на адрес. В смысле не поддерживается обмен пакетами данных по I2C - только побайтово (1 байт за один полный цикл обмена) Кем не будет допускаться? И что делать контроллеру стека, если оно все же произошло? Обмен по шине I2C подтверждается адресуемым устройством в цикле передачи адреса. Имеется в виду, что данное устройство не будет подтверждать обмен (т.е. мастер I2C просто не увидит устройства на шине), если оно (устройство) не может обслужить запрос на чтение или запись. Имеется в виду, что при попытке чтения из пустого стека устройство вообще ничего делать не будет, альтернативой может являться чтение нуля (например) В общем вырисовываются такие сигналы в интерфейсе: input clk - Системный клок input enable - Обращение к контролеру стека input write - Цикл записи (1-запись, 0-чтение) output full - Признак заполненности стека output empty - Признак пустоты стека input [7:0] in_data - Шина записи output [7:0] out_data - Шина чтения

Даже упрощенная модель должна чему то соотвествовать :) Я вот и пытаюсь понять - нужен стек или линия задержки? Это разные вещи. Я не придираюсь, я честно пытаюсь понять требования к дезайну, пока не очень получается :07: Допустим данные приходят из 2го байта данных по I2C, тогда куда должны уходить данные, прочитанные из стека? Давай попробуем наоборот - определиться с протоколом, а потом спросить у препа - это то, что он хотел, или нет :) Итак: Адрес в обменах по I2C игнорируется, направление обмена определяется битом R/W в первом байте Размер стека - 8 байт Обмен со стеком поддерживается только побайтовый (1 байт за один цикл шины I2C) Запись в стек производится только при наличие в нем свободного места, данные для записи берутся из байта данных (2й байт цикла записи шины I2C) Запрос записи подтверждается ACK в адресном цикле шины I2C только при наличии свободного места в стеке Чтение из стека производится только в случае непустого стека в первом байте ответа цикла чтения по I2C Запрос чтения подтверждается ACK в адресном цикле шины I2C только при наличии данных в стеке Так сойдет?

Т.е. что оно реально делает до лампочки ? То, что описано выше - вообще не стек а недоделанное FIFO. По I2C передаются не только данные, там еще передаются адреса и комманды. 'Когда надо' - это когда? Запись и чтение из стека это взаимно обратные операции, они не могут управлятся одним сигналом. Советую сначала определится с протоколами, потом с обшей структурой системы, интерфейсами и соединениями между модулями, и только потом писать содержимое B)

Он всегда возвращает значение последнего элемента стека. На самом деле у тебя описан не стек а линия задержки на 8 тактов wr. Ты уж определись стек у тебя или что, и что и как должно в него записываться и читаться. Что касается I2C то вообще не понятно что из нее и куда должно подаваться и читаться.

Мда, все не так :( module stack(output [7:0] out_stack, input [7:0] in_stack, input wr); reg [7:0] st0, st1, st2, st3, st4, st5, st6, st7; always @(posedge wr) begin st7 <= st6; st6 <= st5; st5 <= st4; st4 <= st3; st3 <= st2; st2 <= st1; st1 <= st0; st0 <= in_stack; end assign out_stack = st7; endmodule

Если в комнате стоит гробовая тишина, то пойдет любой излучатель :) Излучатель, посоветованный rezident'ом будет слышно только в непосредственной близости от прибора (в радиусе метра) и в не очень зашумленном помещении. Если требуется большая громкость, то нужны излучатели посильнее (например от Sonitron в том же Платане). Далее: Выбираете КОНКРЕТНЫЙ излучатель Смотрите его характеристики - рабочее напряжение, ток (для пьезо излучателей - емкость) Если напряжение не более 5 вольт и ток в пределах допустимых нагрузок порта МК, то подключаете напрямую к ногам МК. Можно сделать мостовую схему - подключаете в вывода пищалки к 2м ногам МК, сигналы на них генерируете в противофазе. Если напряжение больше 5ти вольт, или ток слишком большой, то нужен усилитель (на транзисторе или мостовой, зависит от требуемой громкости). Если по току проходит но напряжение больше 5ти вольт - то все равно можно попробовать от ног МК (уже обязательно в мостовом включении), может громкость будет удовлетворительная. Что касается прямого подключения пьезика к ногам МК, то так делать можно, но осторожно :) Емкость у него не столь большая, что бы на частоте 1 KHz создать сколь либо ощутимую нагрузку, а что касается вышибания ног МК пьезо электричеством, то достаточно последовательно с пьезиком включить небольшой резистор (ом так на 100)

Вполне достаточно ШИМ нужен если ты хочешь, что бы для привлечения внимания динамик орал 'Внимание! Внимание!'. Для выдачи 1000 гц нужно просто выдать меандр с частотой 1000 гц. Да. Подсоединить выход контролера к динамику :) К174УН14 - это усилитель для относительно мощных динамиков (ватт так на 10). Использовать его для усиления голого меандра абсолютно бессмысленно. Во первых, есть динамики со встроенными генераторами. Им достаточно подать питание и все. Если использовать голый динамик (без генератора), то можно задействовать таймер МК (или что там у него будет). Самый простой вариант - не связываться с К174УН14, а поставить один банальный транзистор в ключевом режиме. 2 КГ, не меньше Конкретную марку надо выбирать исходя из необходимой громкости звучания. Все остальное получится из выбранной марки динамика.