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

В поисках нужной скорости генерации импульсов (мигания) от Ардуино через всякие Канни и 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++).

 

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

 

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

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

 

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

 

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

 

Так это одна программа:

Код (C++):

  wiringPiSetup () ;
  pinMode (0, OUTPUT) ;
  pinMode (1, OUTPUT) ;
  for (;;)
  {
    digitalWrite (0, HIGH) ;
    digitalWrite (0,  LOW) ;
    digitalWrite (1, HIGH) ;
    digitalWrite (1,  LOW) ;
  }

Вместо 0 и 1 подставьте свои пины, естественно.
Причем тут 2 канала, мне не совсем понятно.

 

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

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

 

Т.е. Вы хотите сказать, что программа, которая написана мной не меняет на каналах (пинах) 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
для получения меньших периодов задержки.

 

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

 

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

 

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

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

 

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

 

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

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

 

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

 

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

 

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

 

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

 

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

 

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

 

ipsurin, а Analog Device DSS генератор не подойдет. Например такой http://ru.aliexpress.com/item/AD985...odule-0-40MHz-Test-Equipment/32601850164.html