cheblin
Member
настало время рассказать банщику про приоритеты прерываний ?
-
Система автоматизации с открытым исходным кодом на базе esp8266/esp32 микроконтроллеров и приложения IoT Manager. Наша группа в Telegram
Делюсь опытом Power Profiler на рельсах AdHoc protocol
- Автор темы cheblin
- Дата начала
pvvx
Активный участник сообщества
Чё ладно -то? Не знаете языков программирования - не юлите, так и пишите - "не знаю!"
cheblin
Member
гы..
банщик, для меня английский - язык работы и повседневного общения...так то.
в гугель меня посылать не нужно
pvvx
Активный участник сообщества
Обязательно, а то клоун cheblin не знает что номерки могут быть в другую сторону - приоритет больше, номерок меньше.
Заметно по вашей полной мещанине в голове и сообщениях по типу Эллочки-Людоедочки.
С одним не справились, кинулись на другой...
pvvx
Активный участник сообщества
Вот тут не выполняются ваши предсказания на кофейной гуще, что прерывание не является "это функции которые сам не вызываешь":
Функции DOS - INT 20H: завершить программу, или любой int N синхронного прерывания у x86
И многих других ядер... Та и аппаратное прерывание можно вызвать из main()
NVIC отдыхает.
Функции DOS - INT 20H: завершить программу, или любой int N синхронного прерывания у x86
И многих других ядер... Та и аппаратное прерывание можно вызвать из main()
NVIC отдыхает.
pvvx
Активный участник сообщества
Ваше определение к NVIC:
Уже и с памятью плохо? Видимо киш-миш с языками к этому и приводит...
pvvx
Активный участник сообщества
Это от вашей безграмотности. Ему гриш bus - а он думает что это автобус
Англ. язык = Лексикон Эллочки... одно слово и тысяча значений.
Таблица функций хде и для кого? NVIC говоришъ callback - вот они и вызываются из main()
pvvx
Активный участник сообщества
А ежели переходить к более специализированным "западенским" названиям, то клиент путает I2C c I2S и подобное. Про метать бисер перед свиньями уже говорили…
И оно ещё пытается что-то написать для MCU
cheblin
Member
... а ещё очки надел..
cheblin
Member
во время реализации I2C Grabber обнаружилась очень интересная возможность, реализовать которую у меня страшно зачесались руки...
I2C Grabber в моей версии, предполагается должен "проигрывать" массив инструкций, которые могут быть как чтение(2 байта адрес и ренистр) так и запись(4 байта адрес, регистр и записываемые данные) .
в AdHoc есть массивы, я уже было начал делать на массивах, но задумался...
ибо в AdHoc протоколе есть встроеннные пакеты(сущности) и даже многомерные массивы из них. Но все сущности должны быть одного типа.
можно было бы сделать отдельный массив для инструкций чтения и отдельный для записи
хм... а что мешает мне положить их в один массив?
и это вполне реализуемо, и для этого НЕ придется много дописывать. описание будет выглядить примерно так
будет единый массив (на скриншоте длинной 255) инструкций. причем в случае Grabbing_Instructions, они будут в перемешку и инструкции записи и инструкции чтения....
уже существующая инфраструктура AdHoc протокола после небольшой доработки позволит легко класть разнородные сущности, оправлять, и получив пакет, вынимать их строго именно того типа которую положили, на всех языках
беру небольшую паузу, уж очень мне хочется реализовать всё это.
stay tuned
I2C Grabber в моей версии, предполагается должен "проигрывать" массив инструкций, которые могут быть как чтение(2 байта адрес и ренистр) так и запись(4 байта адрес, регистр и записываемые данные) .
в AdHoc есть массивы, я уже было начал делать на массивах, но задумался...
ибо в AdHoc протоколе есть встроеннные пакеты(сущности) и даже многомерные массивы из них. Но все сущности должны быть одного типа.
можно было бы сделать отдельный массив для инструкций чтения и отдельный для записи
хм... а что мешает мне положить их в один массив?
и это вполне реализуемо, и для этого НЕ придется много дописывать. описание будет выглядить примерно так
будет единый массив (на скриншоте длинной 255) инструкций. причем в случае Grabbing_Instructions, они будут в перемешку и инструкции записи и инструкции чтения....
уже существующая инфраструктура AdHoc протокола после небольшой доработки позволит легко класть разнородные сущности, оправлять, и получив пакет, вынимать их строго именно того типа которую положили, на всех языках
беру небольшую паузу, уж очень мне хочется реализовать всё это.
stay tuned
pvvx
Активный участник сообщества
Универсальный драйвер I2C/SMBUS.
На линии I2C/SMBUS может быть несколько устройств.
Атомарной транзакцией для конкретного устройства на шине I2C/SMBUS называется последовательность записи-чтения байт от сигнала START до сигнала STOP. В транзакции может существовать повторный сигнал START.
Для выполнения одной транзакции по I2C/SMBUS требуются одна универсальная функция.
У неё задается:
Задаются модификаторы исполнения:
Адрес устройства c битом RD/WR помещается в массив байт для записи. Нет никакого смысла задавать адрес устройства отдельно и это решает и другие варианты специфических транзакций для кривых устройств.
По старту исполнения транзакции всегда передается сигнал START. Далее передаются байты из массива записи. Запись байт всегда прекращается по получении NACK. Если нет ACK, но ещё есть байты для записи до генерации повторного START - это означает ошибку транзакции и в линию передается STOP и происходит выход из драйвера с сигнализацией ошибки.
При совпадении номера байта записи с номером перед которым генерируется повторный START в линию передается повторный START. Далее массив записи обычно содержит адрес устройства с доп. адресацией в устройстве или пусто и операции переходят к режиму чтения, если кол-во байт чтения не равно нулю.
Прием байт осуществляется с передачей ACK, кроме последнего читаемого байта. Для него генерация ACK или NACK задана в модификаторе исполнения.
По концу обработки транзакции всегда передается STOP.
Это весь алгоритм универсального драйвера I2C/SMBUS.
На линии I2C/SMBUS может быть несколько устройств.
Атомарной транзакцией для конкретного устройства на шине I2C/SMBUS называется последовательность записи-чтения байт от сигнала START до сигнала STOP. В транзакции может существовать повторный сигнал START.
Для выполнения одной транзакции по I2C/SMBUS требуются одна универсальная функция.
У неё задается:
- Массив байт для записи и/или заголовка чтения. В него входит адрес устройства. (не может быть нулевой длины)
- Счетчик - кол-во байт для чтения. Может быть нулевым.
- Номер байта для массива записи перед которым генерируется повторный 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 устройствами, а не то что он придумывает
И нечего изобретать зоопарк драйверов I2c/SMBUS, включая аппаратные реализации мастера.
А для @cheblin-а - это указание какую минимальную атомарную посылку нужно гнать для работы с I2c/SMBUS устройствами, а не то что он придумывает
pvvx
Активный участник сообщества
Всё давно реализовано и работает -> 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 не поймет - надо разжевать):
Сейчас всё это барахло, т.е. протокол сериализации между устройсвами описывается в трех несовместимых стихиях:
И никаких сложностей в описании и реализациях протокола не встретил по мере опытов производимых в малые куски свободного времени которое можно выделить на хобби. Что говорит о том, что автоматическая генерация кода протокола нафиг не сдалась, а только усложнит задачу.
Главное в данном деле не описание и не код обработки сериализации потока, а создание универсального частного и оптимизированного для класса устройств протокола.
Это обеспечивает сжатие потока лучше чем какие-то ваши костыли и потуги с AdHoc. А так-же более быструю реализацию, т.к. не придется дописывать костыли или переписывать, если что-то забыто или не совмещается с непродуманными детскими реализациями...
Сейчас всё это барахло, т.е. протокол сериализации между устройсвами описывается в трех несовместимых стихиях:
- СИ
- Паскаль
- Javascript
И никаких сложностей в описании и реализациях протокола не встретил по мере опытов производимых в малые куски свободного времени которое можно выделить на хобби. Что говорит о том, что автоматическая генерация кода протокола нафиг не сдалась, а только усложнит задачу.
Главное в данном деле не описание и не код обработки сериализации потока, а создание универсального частного и оптимизированного для класса устройств протокола.
Это обеспечивает сжатие потока лучше чем какие-то ваши костыли и потуги с AdHoc. А так-же более быструю реализацию, т.к. не придется дописывать костыли или переписывать, если что-то забыто или не совмещается с непродуманными детскими реализациями...