Jump to content

    

All Activity

This stream auto-updates     

  1. Past hour
  2. Спасибо! Это хороший вариант, так как доп разъём со входами xadc есть, останется прикрутить кабель и обновить прошивку. Триггер есть отдельный на фотодиоде, главное успеть померить мощность до следующего выстрела
  3. Мне не ТУ, а ТО - техническое описание нужно.
  4. Не вводите начинающего в заблуждение! Чтобы ориентироваться в HDL-дизайне от МатЛаб надо хорошо знать азы языка. Он ладу не даст исходникам на предмет оптимизации и скорее всего сделает в лоб! А это в большинстве своем медленно...
  5. Разрядность 12 бит вполне достаточна, внутренний АЦП STM32 вполне справляется. Частоты очень низкие- торлабсовские датчики имеют полосу сигнала на выходе до 100 гц макс ( именно на выходе, на входе по оптике могут быть единицы наносекунд). Но есть одно но- обнаружение фронта импульса. Для медленных АЦП можно фронт "проспать" и непроинтегрировать самые интенсивные отсчеты. Поэтому частоту отсчетов АЦП приходилось увеличивать. Ну и обнаружение импульсов (триггер) плохо работает в оригинальных измерителях торлабса при уровне импульса меньше 2-5% от полного диапазона, а внешний запуск не у всех измерителей есть. Я с этим намучался когда делали оптический аттенюатор с большим диапазоном регулировки- канал на выходе аттенюатора просто не запускался, хотя по осциллографу уровень сигнала еще вполне обнаружимый был. Пришлось ставить дешевый китайский осциллограф и интегрировать импульс в цифре в компе. Торлабсовские датчики кстати удобные потому что имеют BNC разьем, отсоединяемый от переходника на DB9 где спрятан 1-wire eeprom с серийным номером и индивидуальной калибровкой датчика.
  6. process (we, CS,iactive_sel) begin if ( CS = '1' ) then IFCR_r <= (others => '0'); start_tx_bus <= '0'; ControlRx_r(1) <= '0'; wt_fifo_256 <= '0'; iwr_tx_fifo_4096 <= '0'; res_fifo <= '0'; TXBufControl_r(1) <= iactive_sel; if (resControlR = '1') then TXBufControl_r(2) <= '0'; TXBufControl_r(3) <= '0'; end if; elsif (rising_edge(we)) then case (addr) is when "00000" => Control_r <= data_in; --Управления модулем приемопередатчика when "00001" => BoudRate_r <= data_in; --Настройка скорости передачи и приема when "00011" => IER_r <= data_in; --Разрешения прерываний when "00101" => IFCR_r <= data_in; --Сброс флагов запроса прерываний when "00110" => --ControlTx_r <= data_in; start_tx_bus <= data_in(0);--Управления передатчиком when "00111" => CntTx_r <= data_in; res_fifo <= '1'; --Размер транзакции для передачи when "01000" => ControlRx_r <= data_in; --Управление приемником when "01100" => TXBufControl_r <= data_in;--Выбора буфера передатчика when "01101" => T1_CMP_r <= data_in;--Компаратор времени окончания приема when "01110" => T2_CMP_r <= data_in;--Компаратор времени разрешения передачи when "01111" => wt_fifo_256 <= '1'; data_fifo_tx<= data_in (7 downto 0);--Регистр FIFO записи в 256 байтный буфер передатчика when "10001" => iwr_tx_fifo_4096 <= '1'; --Регистр FIFO записи в 4к байтный буфер передатчика when others => null; end case; end if; end process; Всех делов.....
  7. Думаю - заключает следующий рекламный контракт с новым производителем чипов. И скоро мы услышим хвалебные оды в их честь. Как ранее уже слышали про Кинетис, Ренесас, ...
  8. Нет, вы пишете об обратном: А "такое" засовывать не нужно. Для этого программисту голова и дана. Опишу свое решение, может оно натолкнет кого-то на полезную мысль. У меня дерево классов работы с УАПП не имеет виртуальных функций. А вот класс console имеет виртуальные функции write(), read(), is_connected() и уже от console наследуются serial_console, vcp_console и telnet_console, членами которых являются, соответственно, ссылки на serial_port, usb_device::vcp_interface и telnet. И еще один класс, терминал, соотвественно, имеет указатель на console. В результате в устройстве может быть несколько независимых одновременно работающих терминалов на разных интерфейсах.
  9. Today
  10. Вспоминается тут мне один мой бывший коллега. Который несколько лет назад решил освоить ООП. И начал везде где ни попадя создавать классы. Со всякими наследованиями и перегрузками. Я потом заглянул в его код и......! о УЖАС!!! Там где раньше были вызовы типа: SetEvent(...), ResetEvent(), SetAlarm(...), ResetAlarm(...), SetState(), ResetState() и т.п. с говорящими названиями, когда глядя на такой код более/менее понимаешь, что там происходит. То теперь там значилось: некий_объектA_с_ничего_не_значащим_названием.Set(...); некий_объектB_с_ничего_не_значащим_названием.Set(...); некий_объектC_с_ничего_не_значащим_названием.Reset(...); ... и так несколько десятков set()/reset()/get() в одной функции, но для разных переменных разного типа. вобщем - код состоящий из огромного множества Set()/Reset()/Get() и т.п. методов с одинаковыми названиями, но внутри совершенно разных. А чтобы понять - что за Set() в данном месте, нужно каждый раз отматывать исходник к месту объявления каждого такого объекта, чтобы увидеть его тип. Таким образом - вместо улучшения читаемости (которое вроде должно давать применение ООП), получили прямо противоположный результат. Стало совершенно нечитаемо. Если раньше можно было просто поиском по имени функции, найти место её определения и посмотреть что она делает, то теперь поиск выдавал тучу одинаковых Set(). Всё как на вашей каринке - вместо столового прибора на столе: с ложкой, вилкой, ножом, тарелкой, получили вот такой ряд из одних вилок!
  11. Написал в личку, но ответов пока нет. Пробую здесь напомнить. Мои извинения другим читающим.
  12. Thorlabs выпускают разную продукцию, измерители у них были неплохие. Возможно, они продают "голые" фотодиоды с индивидуальной калибровкой. Про АЦП: берите любой Вам среднюю мощность цифровать или импульсную? Если импульсную, то АЦП там - дело десятое.
  13. Единичный случай, для которого не подходит общий подход никак не доказывает то, что задачу не нужно решать в общем виде.
  14. Коллеги одобрили в новых платах ставить thorlabs, мы у них моторы покупаем, качество хорошее. Если кто использовал, какое АЦП лучше - 12 бит 1МГЦ или 24 бит 96 кГц?
  15. Для CAN лучше STM32, не надо там ПЛИС, но и на Zynq вполне поднимается, читаю, что ядро нужно и умение кодить на Си.
  16. Конечно. И предназначен для передачи не только собственно кадра данных (единый 24-битный кадр (точнее = 26-битный, если считать со старт- и стоп-битами)), но и точки точной синхронизации (по началу старт-бита) между двумя устройствами. Вот именно об этом я и пишу!
  17. Есть и другой подход - использовать его для описания объектов, имеющих похожее поведение, а свойств он может вообще не иметь.
  18. 250мДж, импульс 3нс, частота 10-20Гц, т.е. средняя мощность единицы Вт. Измерять среднюю мощность и на такой диапазон длин волн удобнее болометром (как выше советовали). Альтернатива - фотодиодные измерители, но на диапазон выше 1100нм нужен InGaAs фотодиод, измерители с такой головкой будут подороже. Или таки нужно измерять мощность каждого импульса? тогда нужен быстрый PiN фотодиод, а далее TIA или интегратор. Откалибровать можно самому по измерениям средней мощности.
  19. Вы на ровном месте сделали сущестенный оверхед. Совершенно искусственно. Даже не заметив этого. Это собственно то, с чего я и написал Вам изначальное замечание. С которым Вы всё продолжаете спорить, говоря что "не спорите". И каждый раз, своими же примерами, доказываете мою правоту! PS: Да и не будет там перегрузки. Метод же виртуальный. Т.е. - указатель. Будет то, что сказал Arlleex. Я смотрю - тут как раз много любителей создания лошади из каждого атома. Жесть какая! Теперь ещё для инита порта, вместо простого BL, будет стоять кучка команд LDR с последующей BLX: чтение указателя на таблицу виртуальных методов, чтение указателя на конкретный виртуальный метод (Init()), а затем - BLX. И вся эта кухня - вместо простого BL! (которого может и не быть если компилятор заинлайнит его). Ну ладно ещё инит порта, но ведь и чтение/запись символов будет работать через такой-же бурелом!!! Каждый символ! А потом удивляемся, почему на казалось бы ещё вчера мощном CPU, сегодня наша программа еле ворочается. Вот это и есть - оверхед в полный рост!
  20. Избежать дублирования исходного кода. Если у вас там вообще ничего общего - то и смысла нет, разумеется. У меня же скорость может настраиваться отдельно от инициализации и, соответственно, есть одна для всех УАПП функция настройки скорости в классе variable_speed_uart, которому в качестве базового через параметр шаблона может быть указан generic_uart (который хранит указатель на базовый адрес УАПП и скрывает разницу в именах флагов разных моделей STM32). Аналогично потомкам базовый класс передается в качестве параметра шаблона и можно собирать любую нужную мне комбинацию, например using serial_port = shutdownable_uart<rx_irq<tx_dma<variable_speed_uart<generic_uart>, 8192>, 8>>
  21. А какой тогда смысл в таком классе? Если следовать вашей логике, то тогда надо создать такой базовый класс для всех устройств ввода/вывода - UART, USB, SPI и т.п. А какой смысл в таком объединении и чем оно лучше простого UartWrite(), SpiWrite() если кроме имён методов оно ничего не объединяет. Это уже искусственное притягивание классов за уши туда, где они совсем не нужны. И бесполезное загромождение кода бессмысленными сущностями. Так "обязан" или "может"? По Вашим же постам: Если у вас в одном проекте нужна функция Close() для UART, а вдругом - не нужна, то даже там где она не нужна, всё равно нужно её реализовывать? Или нет? Это с чего они "платформонезависимы"??? Вы ведь мой пример выше читали, забыли? Там где размер символа UART = 24 бита. Сможете Вы на STM32 или на LPC такую длину символа установить? Вот опять оверхед! О котором я говорил. Вы похоже не замечаете просто этого.... Нафига мне создавать и передавать какую-то структуру с настройками в функцию инита порта, если у меня в данном проекте нужно для UART устанавливать только скорость (остальные все параметры = const). Только потому, что в каком-то N-ном проекте мне в UART требовалась не только скорость, но и ещё куча параметров? И потому теперь, во всех проектах вместо передачи бодового значения скорости по значению, мне нужно везде тащить этот интерфейс со структурой! Вот именно! А классо-поклонники я вижу просто не замечают этого.
  22. Скачал, спасибо.!!! Проверил на копии со старым патчем, на которой воспроизвел проблему. Все в порядке!!!
  23. Из описания: Меня же интересует Classic Timing Analyzer, так как целевая ПЛИС (5576) не поддерживает TimeQuest, но за книгу спасибо! Опять же, если они работают идентично, что мне кажется сомнительным, то было бы прекрасно об этом узнать!
  24. https://ekspla.com/product/photosonus-m-series-high-energy-tunable-laser-system-for-photoacoustic-imaging/#specifications В регистре ПО считал 2-2000 в режиме симуляции, на самом деле вроде как 300-2300 на включенном не я работаю, опасная машина
  25. да. А какой тогда смысл? Если только одна функция будет похожая на другие подобные - инициализация, но и та внутри (и по аргументам) - вся другая. Какой тогда смысл в таком наследовании? Когда собственно и ничего не наследуется от родительского. Класс - он для объединения объектов, имеющих похожие свойства. Чем менее объекты имеют похожих свойств, тем такое объединение бессмысленнее и неэффективнее. Это просто уже - притягивание за уши классов туда, где они совсем не нужны. Только потому что модно/молодёжно. Считаю что объединять в какие-то логические единицы (в виде класса или ещё как) нужно на более высоком уровне. Например (как у меня) - драйвер отладочного потока. Он передаёт поток как правило через UART (иногда бывают другие каналы) и внутри может вызывать функции установки скорости UART, передачи/приёма символов и т.п. Которые - обычные функции. Т.е. - построение по типу: middleware / IO-уровень.
  1. Load more activity