FlProg

Продолжал "опыты" с F401CCU. Переписал описание платы, проверил периферию. На разогнанной до 1 МГц шине I2C, обычный генератор, с циклом вывода одной строки на OLED выдавал до 300 Гц. В принципе неплохо, НО...
Проделал те же тесты с esp32 и на тесте в цикле
digitalWrite(out, 1);
digitalWrite(out, 0);
получил на выходе овер 3 МГц... И соответственно цикл с генератором и дисплеем тоже почти 3-кратный прирост производительности.

Теперь дилемма - скорость + WiFi против малых габаритов...
А что думаете вы?
Можно ли применить ESP в ответственном изделии (не медицина конечно и не военка)? В наличии такие модули.

Ingwar писал(а): 08 сен 2020, 21:39 А что думаете вы?

А если BL & WiFi вообще выключить. И пользовать.

Ingwar писал(а): 08 сен 2020, 21:39 Можно ли применить ESP в ответственном изделии (не медицина конечно и не военка)?

А почему бы и нет. Сделал коммерческий проект автомобильного диагностического адаптера на WROOM ESP32, обмен с приложением по UDP. Скорость обмена не уступает адаптеру USB K-Line. Бонусом обновление прошивки по воздуху.

Sancho писал(а): 09 сен 2020, 09:57 А если BL & WiFi вообще выключить.

Если заливаем проект без беспроводных сетей из Flprog, эти интерфейсы отключаются автоматически? Или нужно глубже "копнуть"?

Ingwar писал(а): 09 сен 2020, 13:54 Если заливаем проект без беспроводных сетей из Flprog, эти интерфейсы отключаются автоматически? Или нужно глубже "копнуть"?

esp32 нету, была, отправил Автору на эксперименты
На 8266 без указания wifi чего-то периодически происходит - возможно вачдог какой-то дёргает цикл - пробовал в while(1).
Но в нём около 1us на каждое переключение, чуть более 500кгц.
[spoiler][/spoiler]
Есть SDK для 8266 от известного "Виктора с ТВ таблицей" с вырезанным WiFi, может поставлю и попробую...

DrMario писал(а): 09 сен 2020, 13:16 Скорость обмена не уступает адаптеру USB K-Line.

Это что за такие древние машины? В современных CAN используют.

Тема начиналась про STM32 сползли на ESP32

Ardudue писал(а): 09 сен 2020, 15:48 Это что за такие древние машины? В современных CAN используют.

Под зеленой платой камень STM32 с прошивкой ELM329. К линия для древних помоек определенной марки.

Неожиданно обнаружились проблемы нового адона https://github.com/rogerclarkmelbourne/Arduino_STM32
при работе с PWM:
1.STM32F103C - работает плохо (хаотично и прочее, подробно описать много получиться);
2.STM32F401 - вообще не работет.
Тестировал [spoiler]
uint8_t pinADC=PA0;
uint8_t pinPWM=PB9;
uint16_t valADC,valPWM;

void setup() {
Serial.begin(115200);
while(!Serial){}
Serial.println(F("Test STM32 - PWM"));
pinMode(pinADC,INPUT_ANALOG);
pinMode(pinPWM,PWM);
}

void loop() {
valADC=analogRead(pinADC);
valPWM= map(valADC, 0, 4095, 0, 0xFFFF);
analogWrite(pinPWM,valPWM);
Serial.print(F("STM32 -ADC,PWM=")); Serial.print(valADC);Serial.print(',');Serial.println(valPWM);
delay(500);
}
[/spoiler]
Есть ли какой-нибудь опыт работы с PWM STM32?

Кто нибудь победил Modbus на STM32F1 ?

[ref]masterw[/ref], работает без проблем. тестил RTU.

ecoins писал(а): 10 сен 2020, 17:40 Есть ли какой-нибудь опыт работы с PWM STM32?

На 401-ой работают штатные блоки ШИМ при использовании https://github.com/stm32duino/Arduino_Core_STM32
Выходная частота около 1 кГц.
Или Вас только ядро от Кларка интересует?

Много времени потратил на ядро stm32duino - если обобщить, то очень сырой.
Перешел снова на адро от Кларка.
Уже многое удалось оттестировать. Но вот PWM на 401 никак не получается.

Sancho писал(а): 10 сен 2020, 19:22 [ref]masterw[/ref], работает без проблем. тестил RTU.

Можно пример, у меня не компилируется никак

masterw писал(а): 10 сен 2020, 22:45 Можно пример, у меня не компилируется никак

Самый простой пример для хард сериала для 328, в ide выбираю нужную плату stm32, порт maple, т.к. гружу по usb и всё работает.
Для тестов - на пк инсатовский бесплатный opc на 32 тега.
[spoiler][/spoiler]

Чудеса, но загрузилась. Грузил через st-link. Я вообще пробовал для 2560 на второй сериал. Вообще в моей задумке нужно два 485

Отправлено спустя 2 часа 10 минут 26 секунд:
Все хорошо, пока не добавишь pin PE-DE. Пробовал менять даже в ide на PA8, все равно ошибка "UCSR0A" was not declared in this scope

masterw писал(а): 11 сен 2020, 21:55 Все хорошо, пока не добавишь pin PE-DE

А он Вам точно нужен?

UCSR0A в STM обозван USART_SR а флаг завершения передачи TXC0 в STM TC. Пока это мысли вслух

Отправлено спустя 25 минут 9 секунд:

Ingwar писал(а): 11 сен 2020, 22:06

masterw писал(а): 11 сен 2020, 21:55 Все хорошо, пока не добавишь pin PE-DE

А он Вам точно нужен?

Ну как бы в моем понимании без PE-DE MODBUS куцеватый, вроде простого UART

Отправлено спустя 36 минут 13 секунд:
Вообще я думаю, если продвигать STM, то на сегдняшний день нужно идти по пути вроде ecoins, т.е создавать пользовательские блоки для работы с STM, где можно прописывать конкретные регистры, вывода STM. У ecoins вроде все не плохо, но они зациклились в основном на i2c шине, а кроме этого есть и MODBUS и энкодеры и шаговые двигателя, с которыми STM справится быстрее и лучше и в большинстве случаев с теми задачами, которые вешают due, mega и т.п.

masterw писал(а): 11 сен 2020, 23:39 кроме этого есть и MODBUS и энкодеры и шаговые двигателя, с которыми STM справится быстрее и лучше и в большинстве случаев с теми задачами, которые вешают due, mega и т.п.

DUE я бы не включал в этот список - он побыстродействию не медленнее STM32. Из исследований, пока основными "тормозами" являются" применяемые библиотеки, которые зачастую используют используют функцию delay() вместо организации программного прерывания.Или библиотеки с не эффективной загрузкой шины i2c - например блоки FLProg mcp23x17 и pca9685, HC-SR04, DHT21. Поддержка FLProg протокола ModBus Slave - при передаче образуются задержки на время передачи транзакции из UARТ.
Разработка "новых" библиотек для наиболее часто используемых устройств - вот на наш взгляд важная задача. В этой части аналогов библиотек ecoins для устройств пока не попадались. К слову - все устройства с этими библиотеками допускают горячее переподключение и отфильтровывают единичные ошибки.
В настоящее время проходит успешное испытание библиотек на стендах с STM32F103Cx и STM32F401. Вроде должно получиться и на STM32F411 и STM32F411.
Шаговые двигатели и и энкодеры очень интересуют для собственных прикладных задач - но пока надо "поднять" коммуникации (SPI,CAN, ZigBee, nrf2401, протокол MQTT и пр.).
Хорошо бы объединить усилия с желающими и могущими - требуется и разработка, и тестирование, и новые идеи.

[ref]ecoins[/ref],
Про DUE согласен, подразумевалось UNO), по тормозам из за delay тоже вопросов нет. А вот по ModBus Slave, задержки и сбои получаются даже когда на 485 несколько Slave т.е когда master обращается к соседнему устройству другим нужно понять, что это не к ним стучатся и каким образом они это определяют в flprpg аппаратным или программным я пока не могу сказать, у меня получается даже если добавить в master опрос еще нескольких Slave даже не подключенных к 485, это вешает единственный подключенный, хотя используются всего два holding регистра. В этом проекте используется 23017 на i2c, при подключении RS485 и со стандартным блоком и с вашим на выходах периодически появляются хаотичные сигналы.
Ваши труды тоже поддерживаю, но вот мое мнение, как то нужно пошире тормозов хватает, а у вас с ними не плохо получается бороться.
Про объединить усилия тоже согласен, много голосов было за то, чтобы добавить STM в flprpg, даже когда это реализуется автору flprpg будет гораздо проще это сделать опираясь на какие то отработанные решения, иначе будут использованы те же тормозные библиотеки.