Добрый день Всем.
Прежде всего хочу выразить огромную благодарность автору и всему сообществу за создание поддержание программного языка FLProg, отличный программный продукт.
Вот назрел вопрос к знатокам и автору, а возможно ли появление в списке STM32F103C8T6 контроллера, у меня периодически возникают проблемы с ардуино контроллерами поэтому я периодически использую stm32, они с более широкими возможностями и по портам и по периферии?

Вроде обещал Сергей

Очень нужно ждем с нетерпением еще раз спасибо!

romanmeteo писал(а): ↑

13.07.2018{, 13:35}

у меня периодически возникают проблемы с ардуино контроллерами

А можно узнать какие?

обещали поддержку, я только что в другом посте написал про свой опыт теста пакета стм32
простой блинк почти 10к сожрал

вот проглядел сейчас и собрал не блинк, а рфид
Example sketch/program showing how to read data from a PICC to serial.
This is a MFRC522 library example; for further details and other examples see: https://github.com/miguelbalboa/rfid
Sketch uses 26356 bytes (40%) of program storage space. Maximum is 65536 bytes.
Global variables use 1288 bytes (6%) of dynamic memory, leaving 19192 bytes for local variables. Maximum is 20480 bytes.

а вот и блинк
Sketch uses 10156 bytes (15%) of program storage space. Maximum is 65536 bytes.
Global variables use 892 bytes (4%) of dynamic memory, leaving 19588 bytes for local variables. Maximum is 20480 bytes.

а вот для сравнения тот же блинк для меги328
Sketch uses 928 bytes (2%) of program storage space. Maximum is 32256 bytes.
Global variables use 9 bytes (0%) of dynamic memory, leaving 2039 bytes for local variables. Maximum is 2048 bytes.

если взять процентное соотношение, то стм32 тут проигрывает и для плк я не вижу особого выигрыша (можно взять ардуину мега), а гимора с библиотеками хватит с головой

надо у флпрог менять концепцию и уходить с ардуины, т.к. генерируемый сишный код все равно непригоден для чтения, то пусть флпрог генерит не ардуиновский с++, а чистый си, который можно скормить компилятору кейла или какой там сейчас самый крутой компилятор считается

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

kalobyte писал(а): ↑

13.07.2018{, 14:37}

надо у флпрог менять концепцию и уходить с ардуины, т.к. генерируемый сишный код все равно непригоден для чтения, то пусть флпрог генерит не ардуиновский с++, а чистый си, который можно скормить компилятору кейла или какой там сейчас самый крутой компилятор считается

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

Одно маленькое, но весомое, замечание на Ваши "хотелки".
Автору, как и большинству пользователей, важным является графическое создание программы.
Что-бы Вы сказали, если на выходе FLProg будет бинарник?
Кстати, тема хотелок не здесь.

Sancho писал(а): ↑

13.07.2018{, 14:47}

Что-бы Вы сказали, если на выходе FLProg будет бинарник?

так и должен быть бинарник
флпрог будет запускать мейк файл для кейла

Sancho писал(а): ↑

13.07.2018{, 14:47}

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

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

а вот если флпрог будет использовать чистый си в блоках и библиотеки на чистом си, то тогда будет большой выигрыш у стм32 по памяти, скорости, количеству выводов и перефирии и самое главное по цене
я смотрел цену на blue pill - она стоит как ардуина мини, но у таблетки больше выводов, есть железный усб, часы, железная пищалка, модуля рассчета црц, уникальный серийник (можно привязывать прошивку к железке) и еще куча всего, что делает мегу328 непригодной для дальнейшего использования и следовательно нет смысла тратиться поддержку на устаревшего контроллера

еще более перспективное направление - осрв типа freertos или вот довольно известный человек, они пилят другую осрв вместе с немцами


придумать бы блок ртос и потом подцеплять к нему модули или как-то так

Sancho писал(а): ↑

13.07.2018{, 14:47}

Кстати, тема хотелок не здесь.

это пока мои размышления о дальнейшем развитии флпрог, хотелки слишком жирные

Может кому интересно будет http://micropython.org/

Достал свой STM32. Прошивается с помощью STM FlashLoader Demo.exe. Но никак не смог с помощью UART и ST-LINK, пишет при прошивке по UART: Couldn't find the DFU device: [1EAF:0003]. Так и не смог решить, хотя все делал по инструкциям.

PS. Решил, пытался прошивать через адаптер UART. Подключил к USB STM32, заработало все.

Обратите внимание на эту тему : viewtopic.php?f=181&t=5426

Попробовал скомпилировать в 3 контроллера программу эту. В таблице все видно!
Ардуино код съедает в STM32 много памяти, но из за того , что у него объем памяти (особенно динамической) немалый (хоть основной меньше у МЕГИ) , он работает хорошо данной программой (с настройкой платы на 128к).
Кстати у моего STM 32 объем памяти 128к (хотя пишут 64к). Когда в настройках ставлю 64 -программа не влезает.
Использование в этом проекте STM в этой программе оправдывает себя полностью, экономически тем более. Нужно иметь только МК с памятью не менее128к, тогда ардуино проекты будут работать неплохо.
Такой вывод я получил, начав мучить его.

Подтверждаю, все как Вы написали.
Но STM32 в разы быстрее работает чем Mega,Uno - зависит конечно от проекта.
Если в нем есть встроенные delay() ( в библиотеках к примеру ), тут быстродействие процессора мало на что повлияет.
-------
И еще снова о замечательном качестве - толерантность многих пинов к +5в.

.

Во всех библиотеках обходимся без delay(). Отсчёт идёт с точностью до ms. В диспетчере задач с точностью до mcs.

.

millis() и micros().
Подробнее в текстах открыто выложенных библиотеках - они с комментариями.

ecoins писал(а): ↑

17.07.2019{, 19:53}

Но STM32 в разы быстрее работает чем Mega,Uno - зависит конечно от проекта.

Согласен! Мне в нем понравился, что динамическая память большая , даже с учетом , что используется больше памяти чем 4 раза по сравнению с UNO и MEGA.

.

Nikan писал(а): ↑

17.07.2019{, 22:13}

Ну наконец то прямой ответ появился...
еще бы один - что будет если время цикла ( в котором считываете показания переменных millis() и micros() )
превысит необходимый интервал в библиотеке?

Будет не большое отставание для конкретного момента, которое потом будет скомпенсировано в следующем периоде, например:
500,500,499,501,500 - периоды в ms.
При правильно спроектированном проекте (среднего размере) изменение точности наступления события для Arduino Nano менее 1ms - я приводил фото с логического анализатора. На ESP32, STM32 - точность наступления каждого события в заданный период существенно выше.
Все это не так существенно в реальных проектах. В диспетчере есть и относительно точные метки времени (ограничения связаны с точностью таймеров контроллера) с периодом 10ms.

.