Jump to content

    

Ruslan1

Свой
  • Content Count

    2455
  • Joined

  • Last visited

Community Reputation

0 Обычный

About Ruslan1

  • Rank
    Гуру
  • Birthday 01/09/1973

Контакты

  • Сайт
    http://
  • ICQ
    0

Информация

  • Город
    Кишинев

Recent Profile Visitors

9523 profile views
  1. Не согласен. Если есть деньги- то оригинал U3Pro16, который может эти 400 МГц семплирование в потоке. Если денег нет- то клон Saleae 16-канальный. И Saleae и Plus оба тянут только 100 МГц в стриме, а буфер у Plus маленький, так что уж лучше Saleae-клон на Алиэкспресс найти. Ну а если денег нет совсем- то 8-канальный клон Saleae с Алиэкспресса за 8 баксов, но этот юнит просто "маст хэв" у каждого. Во-во, все можно сделать. Но очень многое делать экономически невыгодно. Можно за это время что-то другое сделать, а на часть заработанного купить готовый ЛА. Кстати, с этой задачей отлично справляется 8-долларовый клон Saleae: валить в лог байты принятые с интерфейсов. Я как-то неделю данных так собирал с двух синронизированных Saleae8 в параллель (чтоб каналов хватило).
  2. Очень внятное описание DSLogic на ютубе Я хочу DSLogic U3Pro16, но меня удерживает что он не поддерживается софтом от sigrok. Это большое ограничение, как думаете? У sigrok есть только DSLogic Plus. P.S. от жеж жулики, у них "Upgrade to free express shipping for order over $300", а этот анализатор стОит 299 :) Кстати про задачи: Вот сейчас возникла задача подтвердить что два цифровых сигнала отличаются по фазе не более чем на 25 наносекунд. Я бы сказал, что хочу разрешение 10% от тайминга, то есть около 2 нс. А это семплрейт 500 МГц. Врочем, и 400 хватит, а вот 100 уже никак не устраивает Добавлю. Посравнивал U3Pro и Plus: Большая разница при потоковой работе (из-за USB3 vs. USB2): у Plus максимум: "3 channels: 100MHz". То есть в стриме он свои "400MHz" семплрейта просто не может использовать. У U3Pro все гораздо веселее: "4 channels: 400MHz"
  3. Я ориентировался на описание "возможности как у Saleae", поэтому сильно не приглядывался, это же базовая вещь- показывать байтики, а не сигналы. Как я понял из даташита и из картин в интернете, он вполне себе может сигналы в байты конвертировать, а мне больше от SPI ничего не нужно. Но появился еще один вопрос: Он к какому-нибудь стомегагерцовому сигналу действительно нормально подключается и не давит его? на вид просто проводочки, а не щуп с делителем. Пишут про "250 kOhm/10pF", но это больше на точку выхода с платы по емкости похоже, а не на провод. Пока что склоняюсь к U3Pro16, не из своего же кармана. Но аргументировать полезность покупки все равно придется :)
  4. У меня только клон Saleae Logic 16, там прям на корпусе написано "100 MHz". И смотреть им 50-мегагерцовые сигналы SPI я даже не пытаюсь. Было бы хоть 200-300 МГц - мне бы хватило. И я уверен что DSLogic все-таки умеет SPI в байтах показывать, а не только биты. Запуск от CS мне вполне достаточен. Про объем нужно смотреть на реальные задачи. Например, мне нужно было посмотреть полный цикл обмена с устройством в течении примерно 200 мс, на 50 МГц, для 5 сигналов. Если брать хоть 3 семпла на клок - то это уже 150 мегабит данных. Нужно или по частям смотреть, или просто иметь анализатор с хорошим буфером. По ценам: у Saleae продают "Logic Pro 8" - 500 MSPS, 8 каналов (правда, есть 2 аналоговых 50 MSPS), за 700 долларов. Так что у DSlogic очень все недорого получается.
  5. Так оригинал вроде 149, в стартовом письме темы оно: тынц В Saleae все кроме скорости устраивает, главное чтобы возможностей не меньше. Впечатлил их DSLogic U3Pro16:
  6. Так что, стоит брать? 149 долларов, как-никак. Позитива тут уже написали, давайте негатив :) Я вообще на DSLogic U3Pro16 смотрю. 299 это 299, но 1 Гигасемпл это 1 Гигасемпл... Его кто-то в руках держал? Пользуюсь Saleae (есть и 8- и 16- каналки). Обычно хватает, но вот на той неделе нужно было смотреть 50-мегагерцовый SPI, понял для чего народу гигасемпл нужен... Да и чем дальше- тем больше мегагерцов в анализируемых сигналах, Saleae все чаще не у дел.
  7. Вы смешали мух с котлетами. Мне нужно было удалить всех мух, а уже потом я собираюсь бороться за качество продукта. Ваш путь с DMA- применительно к обслуживанию пикселя- бесполезен. Даже нагрузку на МК не снизит и скорость не поменяет, так как передаются группы от 1 до 4 байт. Тут нужно сначала подход менять (переход от попиксельной обработки к пообъектной), а уж потом можно и DMA к большим объемам применять.
  8. Да, так и есть. Добавил ожидание окончание передачи перед переключение сигнала "команда-данные" и все заработало как надо. То-то я не мог понять, почему в исходниках интернетовских всегда ждут окончания передачи байта прямо в функции передачи- просто это универсальный путь, гарантирующий отсутствие такой проблемы как у меня. Но неоптимальный по скорости. И еще для скорости дефайны рулят. "INLINE" - это только просьба компилятору, а не требование. Набегает много, когда в кадре сотни тысяч вызовов.
  9. Как часто бывает- пока спрашивал что-то начало доходить. Кажется понял. Бит C/CX защелкивается в конце передачи байта. То есть нужно сначала передать, а потом менять режим с комаанды на данные и обратно. А время 1 мкс- это просто время до конца передачи байта. Получается, нужно ждять окончания передачи до переключения режима как и до деактивации CS. Попробую.
  10. Здравствуйте! Столкнулся со странной проблемой: Есть QVGA дисплей с набортной ILI9341. Используется интерфейс "4-wire SPI Interface II". Все работает замечательно, если между байтами есть пауза около 1 мкс. Перестает работать если пауза уменьшается до примерно 0.8 мкс. Пробовал на разных скоростях SPI: от 10 до 25 МГц, результат одинаков: с паузой работает, без паузы нет. Никто не сталкивался? Эффект стабильный, не единичный брак. Судя по отзывам в Интернете, народ десятки FPS имеет на таком интерфейсе, и нигде в примерах я не вижу специальных задержек. использую в STM32F429б 168 MHz ядра мой код установки бита экрана ниже. Работает только если "delay_after_byte()" содержит задержку примерно 1 us. void display_send_byte2(uint8_t byte) { while (!SPI_I2S_GetFlagStatus(DISPLAY_SPI, SPI_I2S_FLAG_TXE)); *(uint8_t*)&(DISPLAY_SPI->DR) = byte; delay_after_byte(); } void display_draw_pixel2(uint16_t x, uint16_t y, uint16_t color) { display_cs_low(); //CS is enabled (set to LOW) // display_set_active_area(x, y, x, y); { //display_send_command(ILI9341_COLUMN_ADDR); display_dc_low(); //command mode for next bytes display_send_byte2(ILI9341_COLUMN_ADDR); display_dc_high(); // data mode for next bytes display_send_byte2(x >> 8); display_send_byte2(x & 0xFF); display_send_byte2(x >> 8); display_send_byte2(x & 0xFF); display_dc_low(); //command mode for next bytes display_send_byte2(ILI9341_PAGE_ADDR); display_dc_high(); // data mode for next bytes display_send_byte2(y >> 8); display_send_byte2(y & 0xFF); display_send_byte2(y >> 8); display_send_byte2(y & 0xFF); } //display_send_command(ILI9341_GRAM); display_dc_low(); //command mode for next bytes display_send_byte2(ILI9341_GRAM); display_dc_high(); // data mode for next bytes display_send_byte2(color >> 8); display_send_byte2(color & 0xFF); while (!SPI_I2S_GetFlagStatus(DISPLAY_SPI, SPI_I2S_FLAG_TXE)); while (SPI_I2S_GetFlagStatus(DISPLAY_SPI, SPI_I2S_FLAG_BSY)); display_cs_high(); //CS is disabled (set to HIGH) } У меня на обход экрана примерно секунда тратится, что явно не есть гут. Да, работает. Но как-то уж очень меееедленноооооо....
  11. Так прям в стартовом сообщении же есть : Если далее зарплата предлагается хоть такая же (а, как правило, она должна быть больше чем в тестовый период) - то очень достойно получается. Ну, хорошо, для меня это выглядело бы очень достойно (от 400 зеленых в неделю за 8-часовую пятидневку). Зависит от стоимости жизни в точке проживания читателя объявления.
  12. Спасибо, интересно. Не застал. Да, в такой системе ясно для чего микросекунды- изменения в этих фазорах очень небольшие, и нужно иметь большую разрешающую способность. Про "на русском мало"- так если посмотреть ссылки в википедии, там вообше упомянуты чуть ли не единичные "лабораторки" в США-Канаде, и (сюрприз!) массовое внедрение этих технологий в Китае. Вероятно, в Штатах нет большого смысла- там не практикуется резервирование мощностей, то есть рулить особенно нечем, даже если измерения и показали что-то важное. А в Китае идет взрывная индустриализация, там ситуация очень быстро меняется, и нужно напрягаться чтобы держать под контролем поведение электросетей. Думаю, в Европе это еще менее интересно чем в США по причине стабильности и предсказуемости. Но это все мое IMHO.
  13. Микросекунды? Диспетчер? Выглядит как шутка. Я могу придумать, где эту микросекундную точность синхронизации в энергетике можно применить, но именно "придумать"- реально никогда не слышал о востребованности подобного. Если есть примеры реального использования такого- киньте ссылку, пожалуйста.
  14. В общем случае- согласен, ошибка интегрирования накапливается и никуда не девается. Абсолютное смещение после множества итераций и возврата в точку старта будет ненулевым. Но в частном случае, если нужно относительное смещение от точки, недалеко удаленной по оси времени - задача решаема. Например, у меня применения были - опоры, троссы. То есть оно закреплено на конце (или концах), но незакрепленный центр (или второй конец) может колебаться туда-сюда, вот эта амплитуда и интересует. Ошибка итрегрирования убиралась ВЧ-фильтрами.
  15. Можно и акселерометром, можно и геофоном. Акселерометром с цифровым выходом попроще, не нужно АЦП. Смотреть нужно не 1 mg/LSB, а что-нибудь получше, например ADXL355, у него разрешение 4 ug/LSB. Цена готовой платки "EVAL-ADXL355Z" на Дижикее 35 долларов. Это у Вас тема диплома, "измерение малых смещений"? Если просто как маленький кусочек- то не заморачивайтесь, берите готовый датчик перемещения. А если это и есть тема - то, конечно, берите первичный датчик ускорения, интегрируйте, делайте модель в Матлабе... Может круто получиться, и очень актуально: Сейчас МЕМС- технологии быстро прогрессируют, и решения на их основе очень востребованы.