Понеже днес ми е дошла музата, реших да се включа в дискусиите, защото напоследък наистина е

мъртвило.

ПЪРВО : КАКВО ЩЕ ИМА В CPLD или FPGA - според вкуса. Това е най-добре да се даде като схема на

PROTEL, но се надявам и така да ме разберете. Като имам малко повече време, ще го нарисувам.
1. Схема за тригер ( спусък ). Това ще дава 'начало' на събитието, което ще записваме. Това ще е

един Flip-Flop с нулиране от две места : по команда отвън или при запълване на RAM. Нулирането ще

е асинхронно. Ще има възможност за установяване по външна команда, също асинхронно. До тук за

тригера се оказа, че ни трябват 2 бита от някакъв вътрешен управляващ регистър. След нулирането си

този Flip-Flop ще сетне в 1 втори Flip-Flop, който ще се нулира само софтуерно, от същия бит както

първия. Тези два тригера, да ги наречем TR_START и TR_DONE ще могат да се четат през управляващия

интерфейс - ето ти 2 бита статус от спусъка.
Тънкият момент тук е стартът, т.е. сетването в 1 на TR_START. Tова ще стане при определен

фронт на някой от входните сигнали. Ако приемем, че ще контролираме само 8 входа, това означава 4

бита - 3 за избор на входа и един за избор на активния фронт (xor). Освен това останалите 7 ( за

удобство 8 ) входа трябва да са в някакво състояние - LOW, HIGH или DONTCARE. Това са още 16 бита.
С това слагаме край на описанието на спусъка - 22 управляващи бита и 2 бита за четене на

състоянието, 2 тригера.

2. Брояч на адресите на RAM. Това ще 'върти' адресите на чиповете памет, където се записват

измерените сигнали. Също така това се използва и при Patern Generator-а. Според мен това ще е

най-много 20 битов брояч за 1М отчета. Какво трябва да има това: Един вход за асинхронен ресет, 6

бита за избор на вход и прескелер на входа, 1 бит, който определя дали да брои и без да е

'щракнал' спусъкът. Гадното е, че най-младшият разряд няма да годи на адресната шина, а ще

мултиплексира латчовете на данните, за да можем да работим с двойна честота спрямо максималната на

паметта. Той задължително няма да брои, ако TR_DONE = 1. Наричам го RAM_COUNTER.
Последно : 8 управляващи бита, нито един за състояние, 20 тригера.

3. Регистър за 'STOP'. Tова ще е един почти 20-битов регистър, реално 12 истински бита и 8

младщи бита нули. Неговата функция е да спре RAM_COUNTER при изравняване на записаното в него

число с това, което е в RAM_COUNTER. Как ще става сетването на този регистър? Ще има един

управляващ регистър, наричам го PRE_HISTORY, с дължина 12 бита. При сетването на TR_START в

STOP_REG се записва сумата от 12 старши бита на RAM_COUNTER и PRE_HISTORY.
Идеята е, при постоянен запис, да имаме предистория какво се е случило известно време

преди да щракне спусъкът.
Последно : 12 управляващи бита.

4. Управляващ блок за генериране на управляващи сигнали към паметта и латчовете на данните. Ще

работи на 4 пъти по-висока честота от честотата на семплиране. Ще има следните управляващи битове

: 1 определящ режима - автономна работа или четене/запис от контролера; 3 определящи банката с

която ще работим, т.е. ще се поддържат максимално 64 бита паралелна работа; 1 определящ посоката

на обмена от контролера - четене или запис; 8 определящи режима на всяка банка в автономен режим -

логер или генератор. Ще има 1 8-битов регистър за съхранение на междинните резултати (данни).
Последно : 13 управляващи бита, 10 тригера.

5. Интерфейсен блок - иска ми се да е с 8 битов паралелен интерфейс и 3 адресни линии, ама още

не съм наясно. Другият вариант е да е с SPI. USART не ми се прави, въпреки че от гледна точка ка

контролера този интерфейс е много удобен. Ама е бавен!
С подбазикване на вече описаните регистърчета може да се направи всичко със системата.

Абе и на мен ми се иска да е паралелен интерфейс а не по UART, но тоя BitBang на FT232 и FT2232 е само 8 пина...Няма как да направиш 8-битова шина и поне 2 контролни линии. А SPI ако пък тръгнеш да си сглобяваш от тия 3Mbps гаранция ще паднеш под 1Mbps... Затова има FT245, чисто паралелно изпълнение

А можеш ли да направиш 4 битова шина, вход/изход и 4 бита управляващи, само изход ?

По принцип може, ама не съм сигурен че ще стане бърз, нямам понятие за колко време се превключва от вход към изход или обратно. Освен това можем да се възползваме от FIFO-то ако ползваме UART режима. Схванах ти идеята, сега ще пробвам...

Оп, корекция, сега като препрочетох всичко за BitBang ще се корегирам малко При BitBang режима също се използва FIFO-то на FTDI чипа. Никъде обаче не се споменава време за превключване на 8-те крака от вход на изход или обратно. В момента правя експеримент с две платки FT232BM, ще докладвам резултати по-късно

BateAz в точка 4 пишеш че ще трябва clok генератор на честота 4X честотата на семплиране. Но при честота на семплиране 100Мhz което е реално при паралелна работа с 2 12ns памети / а е възможно и доста повече / се получава че clock генератора трябва да е на 400 Мhz,което пък не е в възможностите на Spartan III.
280Mhz ни е максималната възможна честота / стр 29 на pdf-a /
Така че трябва да се излъже някак едно семплиране да се прави на 2 такта. В Омегата ми са го реализирали,максималната честота на сканиране е 2 пъти по малка от честотата на клока.

Predator_MF ако правилно съм те разбрал протокола се описва така
формат на изпращан пакет:

<ID>
<Data Size>
<Command and Data> // Първия байт е командата
<CS>

Изчакване на отговор с TimeOut 2s

Аз лично не виждам необходимост от <ID> нали връзката е 1 към 1 устройство. Таим аута е много голям според мен. Тук експериментирах с един FTDI2232 и ми се видя 500ms предостатъчно. Но това са
подробности.


Да дам и аз един вариант на протокол,дайте и още някой друг вариант и да изберем най подходящия.

Моето предложение е:

//---------------------------------------- Command
<Command>
<Data> // 2 байта
<Check Sum>

//---------------------------------------- Data
<Data>
<CRC16 or CheckSum>

//---------------------------------------- OK
<0x99>

//---------------------------------------- ERROR
< 0xAA >

//---------------------------------------- ERROR_Check
< 0xBB >



имаме следнните команди.
//---------------------------------------------------------------------------------
char SentCommand
(char COMMAND_INDETIFICATOR,unsigned int COMMAND_OPERAND )
{
// Ако след предаването на командата е пристигнал отговор
//ОК /0xAA/
return0;

// Изтекъл е TimeOut 500ms но не е получен отговор
return 1;

// Отговора е ERROR_Check
return 2;

// Отговора е ERROR
return 3;
}
//---------------------------------------------------------------------------------
char SentData(char *buff,char lenght)
{
също като SentCommand
}

//---------------------------------------------------------------------------------
char ReceiveData(char *buff,char lenght);
{
// При приети lenght байта и вярна чексума
return OK;

// Изтекъл е TimeOut 500ms
return ERROR

// Грешна чексума
return ERROR_Chek
}


//============================================
Обмена се води по следния начин
if
(SentCommand( COMMAND_INDETIFICATOR,COMMAND_OPERAND ))
ERROR_COMUNICATION

// Ако командата не изисква изпращане или приемане на Data -
// връщане от функцията a ако изисква продължаваме нататък
}
Ако командата изисква изпращане на Data
if ( SentData(Buff,Lenght ) ) ERROR COMUNICATIONS

Ако командата изисква приемане на данни
SentByte ( ReceiveData(Buff,Lenght) ) ;

като връщаните стоиности от функциите позволяват обработка на грешките и построяването на по сложен обмен с повтаряне предаването на грешно приети команди или данни.

Грешно съм го написал. Да се чете : "Честота, 4 пъти по-висока от честотата за работа с RAM-a" Естествено, никой няма нужда от времедиаграми, усукани на моряшки възел и шарени като Чипровски килим.

За паралелния интерфейс на FTDI чиповете вече имам резултати. Накачих един LCD от 3310 за експеримент директно към FT232BM (паралелния режим е същия като на FT2232C). Всичко работи OK, само една много важна особеност... Всяко викане на функция от DLL'a на FTDI се испълнява доста бавно (милисекунди), предполагам заради факта че минава през няколко места - DLL >> .SYS >> USB I/F stack (стека на USB) и чак някъде след това се пълни във FIFO на FT232... Какво искам да кажа - трябва така да се напише протокола за комуникация, че наведнъж да се изпращат и приемат големи пакети по паралелния интерфейс, иначе изключително бавно се пренасят пакети по 1-10 байта... Резултата от първоначалния ми тест беше затриване на целия LCD за повече от 30 секунди (като FTDI е конфигуриран да работи паралелно на 3Mbps).След това с малко тарикатлък постигнах същото за около 1.5 секунди. Не знам наистина за какво толкова бавно се пращат пакетите...ако някой се досеща да каже

Следя темата от самото и начало, но до сега не съм писал, защото не съм участник и не виждам с какво мога да бъда полезен. Имам обаче един съвет към всички участници:
За да стане на всички ясно какво точно ще се прави и какви ще са функциите и възможностите на устройството е време да се напише едно задание. По старите във форума, които имат опит с разработки знаят как се прави това. Сега който и да влезе в темата и не е участвал в дебатите много трудно си създава представа за възможностите на това нещо. А и когато има задание, което всички са приели, нещата по-лесно се структурират: кой за какво отговаря, кой по каква част от цялото работи, какви са ориентировъчните срокове да се свърши нещо, за да се развива правилно проекта и накрая да се види колко сте близо до поставените цели.
В противен случай ще цари хаос и накрая ще стигнете не там, за където сте тръгнали....
И моля да не се приема написаното като "конско". Просто 25 годишния ми конструкторски опит ме накара да го напиша.

Така като ни чете някой може да си помисли че проекта е заебан...е, не е В момента пиша терминал за FTDI чиповете, подържащ FT232/245/2232, идеята му е по-лесно усвояване на начина им на работа. Освен това с учвебна цел програмата подържа и управление на графично LCD тип Nokia 3310 и 3 бутона закачени директно към пиновете на FTDI чипа. Управлението на такъв дисплей е крайно елементарно, мисля че ATmega ще се справи с тая задачка. Единия канал на FT2232 може да се използва като BitBang, по предложение на батето, шината да се направи 4-битова.

Аз вече поприключих с лятното обикаляне на планинините и моретата и мога вече по сериозно да се занимая с работа.
Значи доколкото схващам връзката FTDI <-> FPGA ще е bitbang a FTDI <-> АТМега ше е серийна.
За да си продължа работата по процесорния модул,даите да уточним какъв протокол на обмен да се ползва. Predator даде един вариант,аз дадох друг даите и още някоя идея та да подберем най подходящия вариант и да си продължа работата.

И още няма съгласие каква организация на паметта да ползваме 16 или 32 битова. Ако стигнем до консенсус по този въпрос може вече да се работи и по FPGA модула.

Хммм .. аз мисля че дори и с FPGA в 208 пинов корпус 32 канален анализатор трудно ще поместим ...

оптималното решение за мен е да ползваме 2 памети с по 16битова организация .. така си запазваме опцията за бързо скениране в 16битов режим и евентуално в 32битов .... макар че лично според мен 16 канала са пре достатъчно ...

Иначе относно връзките FPGA<>Mega ... ще е добре да е SPI

FTDI_ch0<>Mega .... UART

FTDI_ch1<>FPGA ..... UART/Bit-Bang

Хищника спомена за проблем при ползването на БитБанг режима (предаването на отделните пакети става бавно ...) така че това трябва да се има в предвид ...

Нещо напоследък няма никакъв интерес по този проект.
Относно процесорния модул аз понаправих някои неща.

Изследвах цветен графичен дисплеи 101/80 picsel 4096 color с управление по i2C от SONY ERICSSON T230. Големината му е 29 / 23 мм. Изводите са удобно изведени на лентов кабел а самия дисплей се предлага в удобна за монтаж пластмаса. Има вградена подсветка,доста икономична на това отгоре И се предлага на дребно за 25 лева което ще рече че зая 20-30 броя ще е около 20лева. Може да изобразява 9 текстови реда. Просто перфектно решение за случая. Единствения проблем е че не можах да разгадая как се чете паметта му. Просто документация за него няма и експериментално открих как се управлява. Но това не е пречи да се ползва за целта.
Направих и библиотека за работа с него.

Направих нещо като операционна система,която представлява списък от задачи. С нея се работи доста удобно в мултизадачен режим. И за разлика от RTOS гълта малко ресурси.

Направих протокол за работа с процесорния модул и направих библиотеки за работа с него и за процесора и за PC-to. Прилагам една проста схема.

Вече лятото мина и жегата не пречи на работата,ще се захващаме ли дружно да го направим това творение или вече няма интерес към този проект?

<API> група команди
<LEN>
<CMD> команда
<Data...>
<CS xor all>

Е протокол които го ползват дори GSMs Siemens - доста добър и бърз е... експериментирал съм доста с него и дава добри резултати
Ако командите са от 0-255, API-то може да отпадне - протокола печели време от 1 char

А относно FT-то(може да отпадне) - този които се занимава с USB-то да погледне PIC18F4550 ...