4 АП17 плюс прочая логика, большая схема получается![]()
4 АП17 плюс прочая логика, большая схема получается![]()
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
Так вроде были нужны регистры ...?
Две мс вроде хватит ...
CPLD ?? Причем логику нормальную можно сделать и 1 микруха за 3-5$ если какую нить EPM3064. В ней 64 тригера то есть можно в принципе регистры секторой дорожек разместить в ней, и управлять ими как нить укорочено,
к примеру со стороны мелкоконтолера
000 - idle
001 - Запись номера дорожки из мелкоконтролера
010 - Запись номера сектора из мелкоконтолера
100 - Номер сектора ++
101 - Номер сектора --
110 - Номер дорожки ++
111 - Номер дорожки --
Или что то в этом духе, в том смылсе что не нада постоянно формировать стробирующие сигналы и данные для записи в эти замые регистры
Добавлено через 12 часов 32 минуты
Во еще немаловажно
логика DRQ красиво ложиться в CPLD и прозрачно и гармонично будет работать с МК
к прмеру CPLD отлавила что подана команда записи сектора, она по логике WD1793 сразу выставляет DRQ требуя данные, после того как проц запишет их в регистр данных, CPLD снимает DRQ и посылает IRQ мелконтролеру, как только он их прочитал из регистра DRQ опять ввзводиться. С чтением таже ситуация но в обратную сторону. Причем микроконтролеру ваще париться с этой траблой не нада, так же CPLD биты занятости, ошибки может показывать и ваще раскладку регистра статуса в зависимости от поданной команды, что опять же разгрузит МК, также стоит расмотреть возможность отсеивания от МК в случае занятости всех команд кроме прерывания.
А ваще адресуемый PSP помогает только при записи в порты, а со чтением от него толку мало всеравно на прерывания цепляться прийдется, да и при записи тож прерывания нада, хотя бы что бы DRQ логику отрабатывать, короче от него пользы мож на пару трешку команд МК экономии.
Последний раз редактировалось ZEK; 27.12.2007 в 03:17. Причина: Добавлено сообщение
"А ваще адресуемый PSP помогает только при записи в порты, а со чтением от него толку мало всеравно на прерывания цепляться прийдется, да и при записи тож прерывания нада, хотя бы что бы DRQ логику отрабатывать, короче от него пользы мож на пару трешку команд МК экономии."
Ну во-первых, 16 мипсов вместо 10 у PIC18, это уже само по себе сильно помогаетВо-вторых мипсы 24-ого значительно мипсее 18-ого (чтобы сохранить регистр при записи нужно 62 нс вместо 200) и даже если применять подход, который я предложил выше для PIC18, то и без адресного PSP 24-ый справится и, возможно, даже в турбе.
А если кому мало, то можно вместо PIC24FJ взять PIC24FH, которые работают на 80МГц и, соответственно, имеют производительность 40МИПС
А заодно между делом на этом же ПИКе заэмулить Z80
А адресуемый PSP, думаю, лучше использовать - раз есть такая приятная железка, то почему бы ей не воспользоваться?
Единственное, на мой взгляд, неудобство использования PIC24 - питание оного от 3.3v. Но согласовать уровни легко, так что это не проблема.
Последний раз редактировалось AlexBel; 27.12.2007 в 09:03.
А что там согласовывать, на вход он и 5 в съест, разрешено. А на выход шина и так подтянута к 5 в.
Согласен, входы толерантны к 5в, выходы можно сделать вообще с ОК. Но если использовать (если использовать, конечно!) PSP, то как в этом режиме будут работать выходы - не знаю, нужно курить даташит. Впрочем, думать об этом нужно, только если использовать PIC24. Я-то не очень думаю о согласовании, поскольку буду цеплять не к "Пентагону" или чему-то подобному, а к DE1, с которой проблем согласования не будет![]()
Последний раз редактировалось AlexBel; 27.12.2007 в 09:57. Причина: Добавлено сообщение
Да, это наверное самые большие проблеммы....
А ваще про пипсологию что бы немного подзадумались.
Допустим PIC24 дает нам полные 40MIPS то на 1 такт процессора исполняется всего лиш 11 команд, а за 2 тата за которые нада обычно сообразить мы всего 22 команды успеваем.
А если учесть что это самые узкие места, забитые ветвлениями и проверками....
К тому же в общем мелкконтролер справляется со своими задачами но ему не зхатает место в той части, где мелкаконтролер, мягко говоря не совсем оптимален.
В то же самое время CPLD может оень многое на себя взять и чисто оринтироваться по данным и командам от проца и ответам от мелкоконтролера, без всяких вайтов.
А почему бы тебе не использовать конкретные цифры? Например: "команда OUT Z80 выполняется за столько-то времени. По описанию) на команды ввода-вывода у Z80 добавляется еще такт. За это время PIC24 успеет выполнить столько-то команд. Таким количеством команд ну никак не успеть обработать обращение Z80 к контроллеру!"
А CPLD чем фактически сможет помочь? успевать защелкивать данные, чтобы контроллер успел их потом прочитать? Как раз для этого и существует аппаратный PSP. А данные что из PSP, что из CPLD все равно нужно успевать читать и писать.
И если для чтения/записи из адресуемого PSP нужно просто обратиться к одному из регистров, то для той же операции с CPLD нужно для нее выставить кроме данных еще какие-то сигналы, чтобы она знала, что ей делать с данными. И получится, что "за что боролись, на то и напоролись". Или CPLD будет как-то иначе догадываться, что от нее нужно контроллеру?
В общем-то, на мой взгляд, CPLD могла бы помочь аппаратным формированием сигналов INTRQ и DRQ и, может быть, бита индексного импульса. Но ради этого, думаю, ее использовать не стоит...
Добавлено через 5 минут
Да, но выводы, где аналоговые входы, переводятся в цифровой режим.
Последний раз редактировалось AlexBel; 27.12.2007 в 14:33. Причина: Добавлено сообщение
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)