RaspberryPi 3 и программирование на C++

Тема в разделе "Raspberry Pi", создана пользователем ipsurin, 19 май 2016.

  1. ipsurin

    ipsurin Нуб

    В поисках нужной скорости генерации импульсов (мигания) от Ардуино через всякие Канни и STM32 дошёл до Pi 3.
    Поставил все рекомендованные библиотеки и WiringPi.
    Поставил Ubuntu-Mate. Выглядит как-то солиднее. И работает почти без сбоев
    в отличии от Raspberianа.
    Поставил Geany. Пришлось там в командах сборки в разделе Build немного
    дописать - gcc -Wall -o "%e" "%f" -L/usr/local/lib -lwiringPi
    Взял программу Blink из книги Петина....
    Программа работает, но сигналы на нужные GPIO не поступают.
    Такая же программа на Питоне в среде Geany прекрасно выполняется.
    Похоже, что дело в адресации GPIO на Pi 3. Может кто в курсе...
    Кстати, скорость генерации импульсов на Pi 3 в исполнении Питона оказалась на порядок
    ниже, чем на NUCLEO446 в исполнении ARM MBED (C++).
     
  2. joman

    joman Гик

    Там есть разные инициализации WiringPi. Вот подробнее:
    http://wiringpi.com/reference/setup/
    В зависимости от инициализации пины нумеруются по разному.
    Я точно не скажу про малину, т.к. имел дело только с клонами - Banana pi
    Но с точки зрения программирования там, вроде, все тоже самое:
    Инициализируем библиотеку
    обращаемся к пину по номеру, соответствующему Вашей инициализации.
    Профит
     
  3. ipsurin

    ipsurin Нуб

    Программа немного работает. Там есть команда инициализации. Но главная проблема, что Рпи не показывает ожидаемой мною скорости коммутации. И при работе на двух каналах на одном из них попросту нет никакого сигнала. Подобная же программа на Питоне работает и на одном и на двух каналах.
    Кстати. Есть изделия от FTDI (USB-MPSSE), которые вроде должны работать на коммутации до 30 мегагерц. Заказал. Везут. Что-то подобное есть и от Adafruit.

    FTDI выпустило контроллеры серии FT90x и утверждает, что они на 100 мегагерцовом процессоре коммутируют быстрее, чем все ARMы, в том числе и сидящие в Распберри.
     
    Последнее редактирование: 31 май 2016
  4. joman

    joman Гик

    Что значит "при работе на двух каналах"?
     
  5. ipsurin

    ipsurin Нуб

    Например, GPIO7 и GPIO 32. Сначала единица заводится на GPIO7, потом заводится ноль на GPIO7. Затем единица на GPIO32 и ноль на GPIO32. И так в цикле. Сигналы на GPIO измеряются осциллографом. Предполагается, что в таком режиме контроллер выдаст всё что может аппаратура и транслятор. В Распберри ещё операционная система мешает.
     
  6. joman

    joman Гик

    Так это одна программа:
    Код (C++):
      wiringPiSetup () ;
      pinMode (0, OUTPUT) ;
      pinMode (1, OUTPUT) ;
      for (;;)
      {
        digitalWrite (0, HIGH) ;
        digitalWrite (0,  LOW) ;
        digitalWrite (1, HIGH) ;
        digitalWrite (1,  LOW) ;
      }
    Вместо 0 и 1 подставьте свои пины, естественно.
    Причем тут 2 канала, мне не совсем понятно.
     
  7. ipsurin

    ipsurin Нуб

    Всё именно так. Мне удобнее говорить слово канал. Специфика задачи. Можно называть пинами.

    Так и получается, что если с одним пином 0 всё работает, хоть и медленно, то при работе с пинами 0 и 1 управление сигналом происходит на канале 0, на канал (пин) 1 сигнал не изменяется. Пробовал разные варианты. Возможно, что есть варианты, когда сигнал меняется на обоих пинах.
    А в программе на Питоне всё работает как надо... Но очень медленно. Скорость коммутации падает раз в десять...
     
  8. joman

    joman Гик

    Т.е. Вы хотите сказать, что программа, которая написана мной не меняет на каналах (пинах) 0 и 1 напряжения? Это будет весьма странно...
    Предлагаю начать издалека:
    1. Запустить это:
    Код (C++):
      wiringPiSetup () ;
      pinMode (0, OUTPUT) ;
      for (;;)
      {
        digitalWrite (0, HIGH) ;
        delay (100) ;
        digitalWrite (0,  LOW) ;
      }
    Найти пин (канал), который будет менять напряжение. Потом убрать delay и посмотреть, что получится.
    2. Запустить это:
    Код (C++):
      wiringPiSetup () ;
      pinMode (1, OUTPUT) ;
      for (;;)
      {
        digitalWrite (1, HIGH) ;
        delay (100) ;
        digitalWrite (1,  LOW) ;
      }
    Найти пин (канал), который будет менять напряжение. Потом убрать delay и посмотреть, что получится.
    3. Повесить на оба пина осцилограф(ы) и запустить программу выше (для начала, поставив задержки между digitalWrite).

    P.S. не может быть, что уровни не меняются, это нонсенс.

    p.p.s. вместо delay можно использовать функцию usleep
    http://all-ht.ru/inf/prog/c/func/usleep.html
    для получения меньших периодов задержки.
     
    Последнее редактирование: 31 май 2016
  9. ipsurin

    ipsurin Нуб

    Нонсенс, конечно. Традиционно я брал за нулевой канал пин7. А второй у меня был самый разный. Так на пине7 сигнал менялся. А на другом не менялся.
    Я сейчас далеко от своей малины. Приеду к малине, попробую. Надо заметить, что ни на какие ошибки в ходе трансляции-сборки-выполнения не указывалось. И наглое игнорирование написанных команд контроллером огорчает.
    Я это явление связываю с тем, что реальные контроллеры ARM имеют некоторую внутреннюю задержку при выполнении программы. Вот на сайте FTDI нашёл их контроллер FT90x, который работает на переключение быстрее всех. И это контроллер с частотой 100 мегагерц. В этом документе http://www.ftdichip.com/Support/Documents/AppNotes/AN_304 FT900 Microcontroller Benchmark.pdf изготовители исследуют разные контроллеры. Говорят о внутренних задержках при переключении режима GPIO. И спроектировали контроллер специально для быстрого переключения GPIO.
     
  10. r1000ru

    r1000ru JS-технократ Команда форума

    А какая конечная частота вам нужна? По приведенной вами ссылке указано соотношение вычислительной мощности, деленной на частоту. Т.е. для того чтобы вычислить количество операций в секунду, не забудьте умножить на частоту конкретного контроллера и увидите цифры далеко не в пользу изделия FTDI.
    Что касается частоты ногодрыгания, то для достижения максимальной скорости, это нужно делать записывая необходимые значения в регистры. Причем в идеале нужно чтобы используемые пины были в одном регистре. На тех же кортексах за группу из 16-и пинов отвечает 32-х битный регистр, где запись бита в первые 16 бит означает подачу на ножку логической единицы, а запись единицы во вторые 16-ть бит выставляет логический ноль. Соответственно вы можете одновременни менять состояния в любом соотношении до 16-и пинов. Еще следует заметить, что частота перефирии, и пинов в том числе - часто ниже частоты ядра микроконтроллера. Так на Iskra JS вы можете менять состояния ног 80 миллионов раз в секунду (на практике немного меньше)
     
    BAR__MEN нравится это.
  11. ipsurin

    ipsurin Нуб

    Мне нужна частота 20 мегагерц. Так поставлена задача. Причём эта частота должна быть на двух ногах. Понятно, что до регистров я пока не дотянулся. Сделал программу в MBED на Си++.

    А вот, если на Искре JS на самом деле можно менять состояние ног с частотой 20 мегагерц- это было бы интересно.. Этой Искры у меня пока нет. И пробовал ли кто и когда менять состояние ног с предельно достижимой частотой? Меня несколько смутило, что для программирования на Искре используется интерпретатор Джаваскрипт.
    А пока я решил реализовать задачу на NUCLEO446. Три с лишним мегагерца на канал тоже неплохо. Можно отладить установку. А там что-нибудь пошустрее появится. У меня надежда на кабель USB-MPSSE типа C232HM-EDHSL-0 от FTDI. Обещают 30 мегагерц. Есть и другие потенциально пригодные варианты. Вплоть до детектирования высокочастотной синусоиды..... Ну чем не вариант...
     
  12. r1000ru

    r1000ru JS-технократ Команда форума

    Разумеется ногодрыгание придется делать не на Javascript, а с использованием ассемблерных вставок. Попробую сегодня прогнать тест и посмотреть на осцилографе частоту.
     
  13. ipsurin

    ipsurin Нуб

    Формально у РПИ более чем достаточно скорости процессора. И вообще их там целых четыре штуки. А вот позволит ли механизм управления выводами обеспечить необходимую скорость, пока неизвестно.

    Я тем временем пошёл другим путём. Выяснилось, что в мире есть всякие контроллеры, позволяющие сигналы USB сочленять со всякими GPIO. И скорости вроде обещают приличные. Пока заказал такую штуку от FTDI. Есть ещё подобные изделия и от Adafruit и от Cypress (все жутко дешёвые). Тоже вариант повесить такой контроллер на USB разъём того же РПИ и реализовывать необходимую скорость. Там пропасть всякой документации по программированию этих изделий. Понятно, что эти контроллеры рассчитаны на работу с Виндоусом.
     
  14. Unixon

    Unixon Оракул

    Зря вы STM32 проскочили мимо, это был самый прямой путь получения нужных сигналов. К тому же, их генерацию можно поручить таймерам и иметь эти импульсы на ногах с точностью до такта. А на RPi у вас поверх формально быстрого процессора накручена многозадачная ОС не в режиме реального времен и тормозной Python, у которого преимущество не в скорости, а в гибкости.
     
  15. ipsurin

    ipsurin Нуб

    Я не проскочил. У меня этих стээмов аж три штуки. Проблема в программировании. Для Nucleo я использую MBED. Для DISCOVERY попробовал графическую среду Mechbios от Мехатроники (Рекомендую для непрограммистов).. Вот на NUCLEO446 получилось более 6 мегагерц на одной ноге и по три с небольшим мегагерца на двух ногах. А добраться до нутра STM пока не получилось.
    Чтобы не мучиться я решил попробовать всякие USB-GPIO аппараты.. Тут и FTDI и Adafruit и Cypress, Есть и другие. Кабель USB-MPSSE от FTDI заказал. Едет. Контроллеры от Adafruit и Cypress можно купить прямо сейчас.. Придётся для повышения научно-технического уровня..
    Тропы эти для меня нехоженные. Тем более, что вокруг тех же STM явно существует заговор профессионалов. Хорошо, что есть MBED. А вот вокруг аппаратов USB-GPIO (MPSSE. GPIF) такого заговора нет. Наоборот. Бездна документации. Голова пухнет. А ещё надо конструкцию всего изделия делать..
    На Распберри есть операционные системы реального времени.. Я пока не стал влезать. А вот Убунту-Мэйт на РПИ работает прекрасно.
     
  16. Unixon

    Unixon Оракул

    А в чем именно проблема?
     
  17. ipsurin

    ipsurin Нуб

    Надо получить два потока импульсов с характерной частотой 20 мегагерц. Импульсы идут в противофазе.
    Выяснилось, что на НУКЛЕО446 (180 мегагерц) получается 3,3 Мегагерца на каждом канале.
    Подумалось, что на РПИ 3 можно получить желаемый результат в 20 мегагерц. Не получается. РПИ 3 решительно не хочет быстро переключать сигналы на ножках (GPIO). . Поэтому начал обходной манёвр. Есть контроллеры USB-GPIO разных фирм и модификаций. Заказал всё что смог. Идут. Теоретически такие контроллеры вполне реагируют на скорости USB-2 (480 Мгц). ЮСБ есть всюду. Может и на РПИ удастся обеспечить нужную скорость. Благо ЮСБ на нём хватает.
     
  18. Unixon

    Unixon Оракул

    А это обязательно делать программно?
     
  19. ipsurin

    ipsurin Нуб

    Конечно, нет. Есть вариант с обработкой синусоиды от генератор сигнала. Такой генератор (микросхема синтезатора сигнала на плате с ножками) будет у меня прямо завтра. Генератор, впрочем, тоже программно управляемый. Можно просто использовать импульсный двухканальный генератор. Дорогая штука, но не очень. В планах имеется такой (16-канальный) генератор завести. Отечественный, надо заметить.
    Комп удобен тем, что легко менять параметры программы, которая управляет контроллером.
    Тут сказалась некоторая предистория. Я поначалу делал генератор магнитных импульсных помех для проверки помехоустойчивости проводных интерфейсов.. На Ардуино. А тут вот эта задача на 20 мегагерц. Обычный двухканальный Blink. Начал наращивать параметры контроллеров. Упёрся.
    Ну а контроллер USB-GPIO (и тп) от Cypress предполагается заиметь прямо завтра. Надо заметить, что изделия от Cypress отличаются отменной документацией... Не позднее понедельника ожидается изделие от Adafruit (женщины делали- одно изящество). А там и из Англии привезут кабель USB- MPSSE от FTDI..
    Короче, осталось немного подучиться...Тем более, что данная задача является только частью более общей задачи.
     
  20. ZAZ-965

    ZAZ-965 Гуру