BSACPLD

Для ALTDDIO нужно строго соблюдать соответствие типа порта. Если хотите работать с inout, то поставьте двунаправленный вариант ALTDDIO.

Для начала начните изучать RFC на ARP, ICMP и UDP. https://tools.ietf.org/html/rfc791 https://tools.ietf.org/html/rfc826 https://tools.ietf.org/html/rfc792 https://www.ietf.org/rfc/rfc768.txt Затем когда разберетесь со структурой пакета попробуйте собрать следующую систему: Ethernet PHY <-> IP Ethernet MAC <-> IP CPU <-> IP UART (консоль для отладки) В качестве первого варианта можно реализовать только ARP и ICMP. Полностью руками без готового стека :) Так быстрее придет понимание структуры пакетов :) Для анализа посылаемых/принимаемых пакетов рекомендую использовать Wireshark.

По нему как раз и считал. Дело было не в настройках. Покупные антенны оказались бракованные плюс я поставил слишком маленький конденсатор по цепи питания. Конденсатор заменил на 100мкФ электролит, а вместо покупных антенн поставил самодельные GP антенны. Теперь связь стабильная на 250кбит/с :). Дальность пока не тестировал.

Коллеги, работал ли кто-нибудь с RFM23BP на скоростиях отличных от стандартных? С настройкой скорости передачи вроде разобрался, а вот с приёмной скоростью никак не получается добится приёма данных. В общем если я оставляю дефолтные 40кбит/с, то всё работатет. Если пытаюсь выставить 250кбит/с, то пакеты отпраляются, но не принимаются :( Вот код инициализации RFM23BP: // init_RFM23BP.cpp #include "AVR_CPU.h" #include "main.h" #include "system.h" #include "control_rfm.h" #include "init_RFM23BP.h" #define RFM_ID 0x08 //--------------------------------------------------------------------------- void init_RFM23BP (void) { __delay_cycles (const20ms) ; // Reset ALL registers wr_rfm_byte (0x07, 0x81) ; __delay_cycles (const1ms) ; // Check DEVICE_TYPE if (rd_rfm_byte(0) != RFM_ID) LED_PORT |= (1<<LED1) ; // FREQ = 868.95MHz wr_rfm_byte (0x75, 0x73) ; // sbsel=1, hbsel=1, fb=19 wr_rfm_byte (0x76, HIBYTE(28640)) ; // fc=28640 (868.95MHz) wr_rfm_byte (0x77, LOBYTE(28640)) ; // wr_rfm_byte (0x74, HIBYTE(0)) ; // fo=0 wr_rfm_byte (0x73, LOBYTE(0)) ; // wr_rfm_byte (0x79, 0x00) ; // fhch=0 wr_rfm_byte (0x7A, 0x00) ; // fhs=0 // Modulation wr_rfm_byte (0x70, 0xC0) ; // txdtrtscale=0, enphpwdn=0, manppol=1, enmaninv=1, enmanch=0, enwhite=0 wr_rfm_byte (0x71, 0x23) ; // dtmod=FIFO, modtyp=GFSK, fd=160 (100kHz) //wr_rfm_byte (0x72, 0xA0) ; // wr_rfm_byte (0x34, 64) ; /* // TX data rate wr_rfm_byte (0x58, 0xC0) ; // if >100kbps 0xC0, else 0x80 wr_rfm_byte (0x6E, HIBYTE(16384)) ; // txdr=16384 (250kbps) wr_rfm_byte (0x6F, LOBYTE(16384)) ; // */ // TX power = 10dBm wr_rfm_byte (0x6D, 0x1B) ; /* // RX wr_rfm_byte (0x1C, 0x8B) ; // dwn3_bypass=1, ndec_exp=0, filset=11 wr_rfm_byte (0x20, 48) ; wr_rfm_byte (0x21, HIWORD(LOBYTE(174763))) ; wr_rfm_byte (0x22, LOWORD(HIBYTE(174763))) ; wr_rfm_byte (0x23, LOWORD(LOBYTE(174763))) ; wr_rfm_byte (0x24, 0x0E) ; // rxncocomp=1, cgainx2=1, crgain=1708 wr_rfm_byte (0x25, 0xAC) ; // */ // PLL ON wr_rfm_byte (0x07, 0x03) ; __delay_cycles (const1ms) ; } //--------------------------------------------------------------------------- Если убрать комментарии, то данные перестают приниматься. Подскажите, как правильно настраивать приёмную скорость для данного модуля.

Попробуйте поставить Current Strength в минимальное значение. Это будет эквивалентно изменению slew rate.

Брал из местных закромов.

Отнюдь. Я работал с парой чужих плат где клоки были заведены на обычные пины. И я всегда обходился без PLL. Доворачивал их с помощью задержек либо в ПЛИС, либо в самой микросхеме PHY. Главное было пропустить их через глобальный буфер и получить временной сдвиг в пределах 1,1-1,9нс.

Попробуйте довернуть клок не с помощью PLL, а с помощью ALTCLKCTRL настроенной в качестве глобального буфера. В этом случае при прохождении клока через глобальный буфер будет получаться задержка порядка 1,2 нс, что должно быть вполне достаточно. Также задержки можно крутить и в 88E1111. Посмотрите в datasheet описание 20 регистра.

Спасибо. Помогло. :a14:

Возникла необходимость повернуть кусок разводки с трассами и компонентами на 45 градусов. На 90 и 180 это можно сделать с помощью Circuit Move & Copy. А вот как на 45?

1367МН015 http://www.mri-progress.ru/products/bis-i-...sintezator-dds/ Правда насколько они покупабельны я не знаю.

Не будет. Если трансивер соответствует стандарту RS485, то он совместим с любым другим трансивером, который соответствует стандарту RS485. Посмотрите для примера: https://avrlab.com/upload_files/MAX3082-1.pdf https://datasheets.maximintegrated.com/en/d...0E-MAX3079E.pdf http://www.ti.com/lit/an/slla070d/slla070d.pdf http://www.musidora.ru/format485.htm Для приведённых трансиверов входное/выходное напряжение дифференциальных линий соответствует стандарту RS485 (-7...+12), стало быть они совместимы.

Если рассматривать задачу в том ключе, в каком её сформировал топикстартер, то самый правильный вариант это взять RS485 трансивер с питанием 3.3В.

Взял код из RFC2435. Скомпилировал и посмотрел, что он выдаёт. Итог: D-Link соответствут RFC2435 и тому, что Вы написали, а Waveserver - нет. P.S. Насчёт заголовка Вы всё правильно сказали.

Можно использовать любую микросхему из серии 74AHC/AHCT или 74VHC/VHCT. Например 3.3В->5В 74AHCT1G125 5В->3.3В 74AHC1G125 Также можно взять специализированный преобразователь 74LVC1T45. P.S. А вообще можно спокойно брать любой RS485 преобразователь с питанием 3.3В.

Я тут разбирался с RTP для JPEG и обнаружил несовпадение при вычислении FragmentOffset у разных видеокамер. У D-Link DCS-2132L камеры FragmentOffset считается по полю payload, а у Waveserver 3554 по payload+dqt_header+dqt. Во втором пакете у DCS-2132L FragmentOffset = 1292, а в третьем FragmentOffset = 1424, т.е. длина поля dqt не учитывается (1424-1292 = 132 - как раз длина поля dqt). У Waveserver 3554 FragmentOffset всегда равен 1400, т.е. он учитывают ещё и длину dqt. В общем вопрос как правильно?

Ура заработало! :biggrin: :biggrin: :biggrin: Тестбенч во вложении - может кому-нибудь пригодится. testbench.rar

Ещё странный момент. Если записывать в pixelin одни нули, по идее, выдаваемые квадраты должны быть чёрного цвета. Вместо этого они тёмно зелёные...

Пытаюсь заюзать данную корку для сжатия оцифрованного видео. С конфигурированием и регистрами вроде разобрался, а вот с pixelin возникли непонятки :( Разрядность у него 8 бит. В каком виде ему нужно отдавать пиксели? Если последовательно записывать R, G и B, то не влезает - сигнал scanactive падает примерно на середине потока.

Под проектом я имею ввиду плату, которую я делал в Expedition PCB. В письме был архив с файлом платы в формате CAM350 и кратким описанием устройства.

У меня как раз есть такое умение. :) Три дня назад отсылал Вам свое резюме с примером проекта, а Вы мне даже не ответили. :(

Начал понемногу изучать Cyclone V и наткнулся на совершенно непонятные грабли с LOANIO: 1. В качестве отладочной платы взята DE0-Nano-SoC. 2. В FPGA части на 53-й LOANIO на входы IN и OE поданы 1. В настройках HPS соответствующий пин отмечен как LOANIO. 3. В bsp-editor заданы дефолтные настройки для загрузки с SD карты. Полученный после make preloader-mkpimage.bin закинут в корень SD карты. 4. FPGA часть зашита в EPCS. Итог: FPGA часть стартует и работает нормально, а вот HPS_LED на который я хотел подать 1 упорно находится в 0. Пробовал разные настройки bsp, очищать папку software и пересобирать заново проект. Такое ощущение, что полученный прелоадер не хочет загружаться. Что я могу не так делать? Нет ли ни у кого самого минимально рабочего примера с LOANIO? Интересует именно самый минималистичный вариант, т.к. в текущем проекте мне совершенно не нужен HPS, нужно просто вытащить сигналы с соответствующих HPS пинов на FPGA часть. P.S. Проект залил вот сюда: https://yadi.sk/d/CciXdG3SqL9vs

Решил таки проблему :) Нужно было скачать VirtualBox Extension Pack и включить поддержку USB2.0 (EHCI).

Решил попробовать поработать с UsbBlaster II из под VirtualBox, но тут внезапно столкнулся с непонятной проблемой: 1. UsbBlaster II является составным usb устройством, но VirtualBox почему-то видит его как одно устройство. 2. При попытке подключения в VirtualBox он появляется в диспетчере устройств гостевой ОС (Win 7), но не работает (код ошибки 10 - невозможно запустить устройство). 3. При попытке установить драйверы вручную винда пишет, что драйвер не подходит. 4. При этом в этой же виртуалке обычный UsbBlaster работает совершенно нормально. 5. Сам UsbBlaster II однозначно рабочий, т.к. на чистой винде работатет без каких-либо проблем. Пробовал на разных образах виртуалки, удалять и перподключать программатор - на виртуалке упорно не хочет работать. Кто-нибудь стакиваля с подобной проблемой? Уже не знаю в какую сторону копать...

Резюме отправил два дня назад, а ответа так и не получил. И совсем непонятно зачем скрывать название организации.