Hi there,

I am trying to build tye yaplc_runtime to flash the stm32f4discovery, as I can't use codeblocks to build the project, I am creating my own makefile, but when I try to build the compiler can't find the variable 'plc_hw_status'.

I am using the following bsp: RTE/src/bsp/stm32f4/

This variable apper to be defined in the file but as extern.

The definition PLC_HW_ERR_DEADLINE also appears not to be declared.

Do I need to implement my own sistick handler?

Thanks in advance..
The project is really fantastic...

Здравствуйте.
Пробовал запустить yaplc-runtime на отладочной плате STM32F429-DISC1, но столкнулся с несколькими проблемами.

1. Скорость порта не соответствует исходному коду, а работает в два раза ниже.
   Предположительно связано с тем, что таргет yaplc делался для STM32F407VG, судя по линкерскрипту
   

   RTE/src/bsp/nuc-227-dev/stm32f4disco-rte.ld

   Line 21 in 65341e5

   /* Linker script for ST STM32F4DISCOVERY (STM32F407VG, 1024K flash, 128K RAM). */

   
   Так вот, пришлось (найти, додуматься и) внести изменения в

   RTE/src/bsp/stm32f4/plc_config.h

   Line 21 in 65341e5

   #define PLC_HSE_CONFIG rcc_hse_16mhz_3v3

   
   (поставить rcc_hse_8mhz_3v3), заодно поменяв GPIO для светодиодов LD3, LD4 (PG13, PG14). Но это полбеды.

2. LSE Oscillator failed!
   На плате нету кварца 32.768кГц. Совсем. Соответственно при попытке задействовать LSE, время не идёт, и рантайм корректно валит предупреждение. Попробовал исправить переключением источника на LSI вручную в одном месте, оглядываясь на STM32CubeIDE HAL примеры. Примеров на libopencm3 не нашёл, поэтому спрашиваю у вас.

diff --git a/src/bsp/common/stm32/f4/plc_rtc.c b/src/bsp/common/stm32/f4/plc_rtc.c
index 996d3be..1576656 100644
--- a/src/bsp/common/stm32/f4/plc_rtc.c
+++ b/src/bsp/common/stm32/f4/plc_rtc.c
@@ -40,11 +40,15 @@ void plc_rtc_init(tm* time)
     pwr_disable_backup_domain_write_protect();
 
     PLC_BKP_RTC_IS_OK = 0;
-
+#if TARGET_LSE_AVAILABLE
     /* LSE oscillator clock used as the RTC clock */
     RCC_BDCR |= 0x00000100;
     RCC_BDCR |= RCC_BDCR_LSEON;
-
+#else
+    /* LSI RC used as the RTC clock */
+    RCC_BDCR |= 0x00000200;
+    RCC_CSR |= RCC_CSR_LSION;
+#endif
     rcc_periph_clock_enable( RCC_RTC );
 
     rtc_unlock();

Видимый эффект есть после перезашивки рантайма (приложение осталось), полного выключения (очистка регистров RTC) и подачи чистых 5V. При низком напряжении уплывает и начинает часто мигать обоими светодиодами.
gcc version 10.2.1 20201103 (release) (GNU Arm Embedded Toolchain 10-2020-q4-major)
CodeBlocks 17.12 (2016)
Linux Mint 19.3 (Ubuntu bionic)

Предлагаю добавить два коротких патча в README для варианта discovery.

Здравствуйте.
Проект собрался после того как в свойствах компилятора в проекте поменял значение -mcpu-ab на soft, также в библиотеке libopencm3\lib\stm32\F4 в maikfile FP_FLAGS = -mfloat-abi=soft. проект собрался и запустисля под отладчиком.
Возниккла такая проблема, программа доходит до строки 135 файла plc_tick.c и начинает выполняться сначала.
Как с этим бороться, Вы можете мне помочь?
В код программы никаких изменений не вносил.

Проблема коротко

Скачиваю YAPLC-RTE, собираю, прошиваю в stm32f4-discovery, при помощи конвертера USB — UART TTL подключаю discovery к ПК. Далее, в YAPLC-IDE нажимаю «Подключится к целевому ПЛК», получаю сообщение:

Connecting to:COM28
<yaplcconnectors.YAPLC.YAPLCProto.GET_PLCIDTransaction instance at 0x057D38C8>Exception in PLC protocol : PLC protocol transaction error : Exception in PLC protocol : controller did not answer as expected!

Подробнее

Дело происходит на ПК с Windows 7 32.
До этого я ими никогда не пользовался этими инструментами, поэтому могу совершать очевидные ошибки (в смысле, не ПК с Windows, а тем, что описано ниже).
Устанавливаю Code::Blocks 17.12. Устанавливаю GNU Arm Embedded Toolchain. Выбираю GNU Arm Embedded Toolchain компилятором по умолчанию, указывая Toolchain Executables.
Скачиваю libopencm3, собираю по инструкции:
В инструкции, в разделе Fine-tuning the build, сказано, что можно менять настройки, касающиеся плавающей точки, ничего этого не делал.
Скачиваю matiec.
Скачиваю и настраиваю Open OCD.
Скачиваю проект YAPLC-RTE
Открываю файл проект yaplc-runtime.cbp в Code::Blocks и пытаюсь собрать. Проект не видит компилятора.
В Project-Build options выбираю компилятор GNU Arm Embedded Toolchain. Во вкладке Compiler Settings выбираю Policy: Use Project options only.
После этого получаю следующую ошибку:

_f:/work_yaplc/armgnu/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/bin/ld.exe: error: bin\Debug\yaplc_runtime.elf uses VFP register arguments, f:/work_yaplc/armgnu/bin/../lib/gcc/arm-none-eabi/7.2.1\libgcc.a(udivmoddi4.o) does not

Насколько я понимаю, это ошибка линковщика.
Далее, начинаю поиск решения этой в интернете, помогает совет добавить опцию линкера -mfpu=fpv4-sp-d16, (отсюда).
После этого, проект собирается.
Прошиваю его в STM32F4-DISCOVERY, сообщений об ошибках не вижу.

На всякий случай, логи

Подключаю выходы выводы Rx и Tx преобразователя USB-UART-TTL к портам discovery PA9 PA10. Преобразователь втыкаю в ПК, COM-порт на всякий случай, переименовываю в COM28.
В Beremiz пытаюсь подключится к целевому ПЛК, и получаю сообщения вида:

<yaplcconnectors.YAPLC.YAPLCProto.GET_PLCIDTransaction instance at 0x056861C0>Exception in PLC protocol : PLC protocol transaction error : Exception in PLC protocol : controller did not answer as expected!

Добрый день!

Пытаюсь подключится из YAPLC-IDE к YAPLC-RTE, прошитой в STM32F4-discovery, не получается. Дошел до отладки связи по COM-порту.
На моем экземпляре discovery, похоже, убит uart1, используемый в RTE.
В RTE/src/bsp/stm32f4/plc_config.h меняю настройки DBG_USART на USART2, порты и прерывания, соответственно, тоже.
Тестирую Tx/Rx при помощи терминала на ПК.
Модифицирую программу RTE для циклической отправки байт, в терминале вижу нужные символы.
Тестирую Rx. Ставлю точку останова в обработчике прерывания USART, ввожу в терминале разные символы. Прерывание срабатывает не на все символы, например, "U" и "u" не работают, "Y" и "y" работают. В отладчике вижу принимаемые байты, они не соответствуют кодам символов, чаще всего это 0xF3, 0xF5, 0xFC.

Протестировал связь по COM-порту аналогичным образом на проекте из STM32CubeMX, там все прекрасно работает, т.е. проблемы с железом можно исключить.

Подскажите пожалуйста, в чем может быть дело?

Hi! Thank you for sharing your work!!!

Добрый день.
С последним релизом libopencm3 проект не собирается, ошибка в src\bsp\common\stm32\plc_wait_tmr.c: в структуре rcc_clock_scale нет поля power_save. От него избавились в 2018 году libopencm3/libopencm3@cc8c8a2

Для начала хочу собрать проект с тем релизом libopencm3, с которым собирали его последний раз. Можете сориентировать на дату или коммит?

upd: https://github.com/libopencm3/libopencm3-examples/tree/766f89c724ec2405a6b9dda0d65e67f5cb2d0f2e этот пока собрался без вопросов