• Система автоматизации с открытым исходным кодом на базе esp8266/esp32 микроконтроллеров и приложения IoT Manager. Наша группа в Telegram

Делюсь опытом Power Profiler на рельсах AdHoc protocol

pvvx

Активный участник сообщества
ой, оказывается call многозначное слово, банщику приоткрылся удивительный мир английского.
хорошо что не как звонок дежурного перевел, через гугл транслэйт правда... ну да ладно....
Чё ладно -то? Не знаете языков программирования - не юлите, так и пишите - "не знаю!"
 

pvvx

Активный участник сообщества
настало время рассказать банщику про приоритеты прерываний ?
Обязательно, а то клоун cheblin не знает что номерки могут быть в другую сторону - приоритет больше, номерок меньше. :p
гы..
банщик, для меня английский - язык работы и повседневного общения...так то.
в гугель меня посылать не нужно
Заметно по вашей полной мещанине в голове и сообщениях по типу Эллочки-Людоедочки.
С одним не справились, кинулись на другой...
 

pvvx

Активный участник сообщества
Вот тут не выполняются ваши предсказания на кофейной гуще, что прерывание не является "это функции которые сам не вызываешь":
Функции DOS - INT 20H: завершить программу, или любой int N синхронного прерывания у x86 :p
И многих других ядер... Та и аппаратное прерывание можно вызвать из main() :p
NVIC отдыхает.
 

cheblin

Member
опять включил дурочку? ткни пальцем где я написал что их вызвать невозможно?

у банщика проблема и с русским и с английским и с....
 

pvvx

Активный участник сообщества
Ваше определение к NVIC:
это и есть таблица колбэков прибитая гвоздями.

хочешь, можешь создать свой массив указателей на функции колбэков. и дергать их.

колбэки это функции которые сам не вызываешь, а передаёшь комуто, кудато указатель на них. в надежде на то, что в нужный момент они будут вызваны.

потому они и называются callback = call me back
Уже и с памятью плохо? Видимо киш-миш с языками к этому и приводит...
 

pvvx

Активный участник сообщества
Тут явно делать нечего – начинающий клоун программер с гонором пытается изучить элементарный MCU уже месяц :confused: Позорище...
 

pvvx

Активный участник сообщества
банщик, я с тебя такие лулзы ловлю, не останавливайся... плиз
Это от вашей безграмотности. Ему гриш bus - а он думает что это автобус :) :)
Англ. язык = Лексикон Эллочки... одно слово и тысяча значений.
это НЕ значит что сам не можешь вызвать... ку-ку
Таблица функций хде и для кого? NVIC говоришъ callback - вот они и вызываются из main() :p
 

pvvx

Активный участник сообщества
банщик, я с тебя такие лулзы ловлю, не останавливайся... плиз
А ежели переходить к более специализированным "западенским" названиям, то клиент путает I2C c I2S и подобное. Про метать бисер перед свиньями уже говорили…
И оно ещё пытается что-то написать для MCU :) :)
 

cheblin

Member
во время реализации I2C Grabber обнаружилась очень интересная возможность, реализовать которую у меня страшно зачесались руки...
I2C Grabber в моей версии, предполагается должен "проигрывать" массив инструкций, которые могут быть как чтение(2 байта адрес и ренистр) так и запись(4 байта адрес, регистр и записываемые данные) .

в AdHoc есть массивы, я уже было начал делать на массивах, но задумался...

ибо в AdHoc протоколе есть встроеннные пакеты(сущности) и даже многомерные массивы из них. Но все сущности должны быть одного типа.
можно было бы сделать отдельный массив для инструкций чтения и отдельный для записи

хм... а что мешает мне положить их в один массив?

и это вполне реализуемо, и для этого НЕ придется много дописывать. описание будет выглядить примерно так

upload_2020-2-8_0-7-33.png

будет единый массив (на скриншоте длинной 255) инструкций. причем в случае Grabbing_Instructions, они будут в перемешку и инструкции записи и инструкции чтения....
уже существующая инфраструктура AdHoc протокола после небольшой доработки позволит легко класть разнородные сущности, оправлять, и получив пакет, вынимать их строго именно того типа которую положили, на всех языках

беру небольшую паузу, уж очень мне хочется реализовать всё это.

stay tuned ;)
 

pvvx

Активный участник сообщества
Универсальный драйвер I2C/SMBUS.

На линии I2C/SMBUS может быть несколько устройств.

Атомарной транзакцией для конкретного устройства на шине I2C/SMBUS называется последовательность записи-чтения байт от сигнала START до сигнала STOP. В транзакции может существовать повторный сигнал START.

Для выполнения одной транзакции по I2C/SMBUS требуются одна универсальная функция.

У неё задается:
  1. Массив байт для записи и/или заголовка чтения. В него входит адрес устройства. (не может быть нулевой длины)
  2. Счетчик - кол-во байт для чтения. Может быть нулевым.
  3. Номер байта для массива записи перед которым генерируется повторный START. Может быть нулевым – нет таковой операции.

Задаются модификаторы исполнения:
  • При чтении последнего байта выводить ACK или NACK.

Адрес устройства c битом RD/WR помещается в массив байт для записи. Нет никакого смысла задавать адрес устройства отдельно и это решает и другие варианты специфических транзакций для кривых устройств.

По старту исполнения транзакции всегда передается сигнал START. Далее передаются байты из массива записи. Запись байт всегда прекращается по получении NACK. Если нет ACK, но ещё есть байты для записи до генерации повторного START - это означает ошибку транзакции и в линию передается STOP и происходит выход из драйвера с сигнализацией ошибки.

При совпадении номера байта записи с номером перед которым генерируется повторный START в линию передается повторный START. Далее массив записи обычно содержит адрес устройства с доп. адресацией в устройстве или пусто и операции переходят к режиму чтения, если кол-во байт чтения не равно нулю.

Прием байт осуществляется с передачей ACK, кроме последнего читаемого байта. Для него генерация ACK или NACK задана в модификаторе исполнения.

По концу обработки транзакции всегда передается STOP.

Это весь алгоритм универсального драйвера I2C/SMBUS.
 

pvvx

Активный участник сообщества
Просьба найти микросхему I2c/SMBUS с которой с помощью указанной атомарной транзакции (драйвера) не получится работать.
И нечего изобретать зоопарк драйверов I2c/SMBUS, включая аппаратные реализации мастера.
А для @cheblin-а - это указание какую минимальную атомарную посылку нужно гнать для работы с I2c/SMBUS устройствами, а не то что он придумывает :p
 

pvvx

Активный участник сообщества
во время реализации I2C Grabber обнаружилась очень интересная возможность, реализовать которую у меня страшно зачесались руки...
Всё давно реализовано и работает -> https://esp8266.ru/forum/threads/ble-modul-jdy-10-na-chipe-tlsr8266.4654/page-12#post-70351
USB/BLE драйвер переписан и жрет все микросхемы I2C/SMBUS которые я нашел у себя и которые помню...
В PowerProfiler следующая стадия - сочленение нескольких потоков от разных устройств.
Пока вторым поточным устройством является ADC и у него своя скорость выходного потока... Потом ADC будет несколько каналов.
Третьим поточным устройством будет логический анализатор с нескольких входных пинов... (он уже есть в PowerProfiler, но нет в варианте BLE)
Четвертым поточным устройством будет вывод на пины out... (он уже есть в PowerProfiler, но нет в варианте BLE)
Пятым поточным устройством будет вывод во встроенный DAC (он уже есть в BLE варианте, но нет в варианте PowerProfiler с STM32).
.... :)
 

pvvx

Активный участник сообщества
Да, забыл про “Зри в корень” или саму суть (а то @cheblin не поймет - надо разжевать):

Сейчас всё это барахло, т.е. протокол сериализации между устройсвами описывается в трех несовместимых стихиях:
  • СИ
  • Паскаль
  • Javascript

И никаких сложностей в описании и реализациях протокола не встретил по мере опытов производимых в малые куски свободного времени которое можно выделить на хобби. Что говорит о том, что автоматическая генерация кода протокола нафиг не сдалась, а только усложнит задачу.

Главное в данном деле не описание и не код обработки сериализации потока, а создание универсального частного и оптимизированного для класса устройств протокола.

Это обеспечивает сжатие потока лучше чем какие-то ваши костыли и потуги с AdHoc. А так-же более быструю реализацию, т.к. не придется дописывать костыли или переписывать, если что-то забыто или не совмещается с непродуманными детскими реализациями...
 

cheblin

Member
верное замечание.

небольшая поправка:
да, пишется максимально универсальный I2C Grabber , но примеры и детализацию расписал на примере частной реализации под INA219
 

cheblin

Member
@pvvx. опять пришел и нарыгал?

для чего? чтобы тебя потом натыкали носом в твое наследие? мазохистЪ штоле??
 
Сверху Снизу