Rogerclark
Пт. 16 сентября 2016 г. 11:14
Я начал рефактор код, загруженный Фредериком, так что в каждой серии есть своя отдельная репутация.глин. STM32F1XX, STM32L4XX и т. Д
Инструменты теперь также находятся в своем отдельном репо.
На данный момент каждая доска «вариант» все еще находится в его родительской папке E.глин. Источник ucleo_f103rb находится в папке STM32F1XX, однако, если мы ожидаем, что сообщество будет создано множеством различных досок, он может быть полезно, чтобы каждая доска была в своем собственном небольшом репо, а затем ссылается на них как подмодусы
Однако в настоящее время кажется проблемой, так это то, что папка System/Libstm32f1 действительно является источником для специфического варианта, а не всей серии
Я смог восстановить вариант ядрево -ядров, просто изменив путь к GCC (поскольку DEV должен был использовать Linux и установил GCC в USR/Bin)
Поэтому я думаю, что самое быстрое решение - просто переименовать папку libstm32f1 в lib_nucleo_f103rb, а затем скопировать дубликат этой папки, чтобы сделать другие варианты
Может быть возможно переместить источник варианта в папку варианта, чтобы ускорить отладку нового ядра, но у меня не было времени, чтобы исследовать это.
Инструменты теперь также находятся в своем отдельном репо.
На данный момент каждая доска «вариант» все еще находится в его родительской папке E.глин. Источник ucleo_f103rb находится в папке STM32F1XX, однако, если мы ожидаем, что сообщество будет создано множеством различных досок, он может быть полезно, чтобы каждая доска была в своем собственном небольшом репо, а затем ссылается на них как подмодусы
Однако в настоящее время кажется проблемой, так это то, что папка System/Libstm32f1 действительно является источником для специфического варианта, а не всей серии
Я смог восстановить вариант ядрево -ядров, просто изменив путь к GCC (поскольку DEV должен был использовать Linux и установил GCC в USR/Bin)
Поэтому я думаю, что самое быстрое решение - просто переименовать папку libstm32f1 в lib_nucleo_f103rb, а затем скопировать дубликат этой папки, чтобы сделать другие варианты
Может быть возможно переместить источник варианта в папку варианта, чтобы ускорить отладку нового ядра, но у меня не было времени, чтобы исследовать это.
Сжимать
Пт. 16 сентября 2016 г., 23:39
libstm32f1 должен оставаться общим (на уровне исходного исходного уровня) для всех членов F1, в противном случае разработка и поддержка станут кошмаром, конечно, каждый вариант будет иметь свою собственную библиотеку в области библиотеки в вариантах. Любые исходные различия должны быть реализованы в каталоге вариантов.
Можно перенести некоторые функции из системы/LIB в вариант, если это обязательно, но сохранить почти те же копии источников так много раз, что это не мудрый.
Просто мое мнение....
PS: я еще не изучал код....
Можно перенести некоторые функции из системы/LIB в вариант, если это обязательно, но сохранить почти те же копии источников так много раз, что это не мудрый.
Просто мое мнение....
PS: я еще не изучал код....
Rogerclark
Сб 17 сентября 2016 г. 1:17
@slammer
Я думаю, что Libstm32f1 должен быть разделен, он содержит как конкретный вариант, так и код, который общий для ядра STM32F1
эн.глин. инициация варианта в варианте.CPP
вызовы hw_config_init (), который находится в libstm32f1 (в hw_config.в)
Но в HW_CONFIG.c, hw_config_init () вызывает SystemClock_Config (), который является конкретным вариантом E.глин. В случае нуклео он устанавливает часы HSI и т. Д
Так что я думаю, что внутри libstm32f1 должно быть общий и варианты папка, затем внутри варианты Папка будет источник, включать и build_gcc папки.
Или, возможно, есть папка вариантов под папкой системы, которая имеет подпапки для каждой платы
Я не уверен, как компания по разработке планировала выпустить более одного варианта на серию MCU, возможно, это не было частью их перехода
Я думаю, что Libstm32f1 должен быть разделен, он содержит как конкретный вариант, так и код, который общий для ядра STM32F1
эн.глин. инициация варианта в варианте.CPP
вызовы hw_config_init (), который находится в libstm32f1 (в hw_config.в)
Но в HW_CONFIG.c, hw_config_init () вызывает SystemClock_Config (), который является конкретным вариантом E.глин. В случае нуклео он устанавливает часы HSI и т. Д
Так что я думаю, что внутри libstm32f1 должно быть общий и варианты папка, затем внутри варианты Папка будет источник, включать и build_gcc папки.
Или, возможно, есть папка вариантов под папкой системы, которая имеет подпапки для каждой платы
Я не уверен, как компания по разработке планировала выпустить более одного варианта на серию MCU, возможно, это не было частью их перехода
Рик Кимбалл
Сб 17 сентября 2016 г. 1:21
Может быть, просто сделайте функцию hw_config_init () слабым ссылкой .. Поместите по умолчанию один в LIB и пусть доски переопределяются в варианте
Rogerclark
Сб 17 сентября 2016 г. 1:24
Хорошая идея
Где будет hw_config.c для каждой доски идут ?
Где будет hw_config.c для каждой доски идут ?
Рик Кимбалл
Сб 17 сентября 2016 г. 1:26
в папке варианта
Rogerclark
Сб 17 сентября 2016 г. 1:29
ХОРОШО. Таким образом, это составлено IDE..
Конечно, USB CDCACM материал вообще не в исходном коде, потому что эта плата Nucleo не использует его ;-(
Конечно, USB CDCACM материал вообще не в исходном коде, потому что эта плата Nucleo не использует его ;-(
Rogerclark
Сб 17 сентября 2016 г., 3:07
Рик
Я не уверен насчет слабой справочной идеи
Разве нет проблемы, которую Libstm32f1 может быть скомпилирован без некоторых функций HAL, которые необходимы отдельный вариант, или может обременять некоторые функции вариантов, которые не используются
эн.глин. Nucleo не использует USB CDCACM, но синей таблетки нуждаются в этом
Ну, возможно, USB CDCACM в конечном итоге оказался бы во всех вариантах LIB -файла, но тогда не будет связан с бинарным
Мне все еще кажется более гибким, иметь варианты в папке системы.
Я не уверен насчет слабой справочной идеи
Разве нет проблемы, которую Libstm32f1 может быть скомпилирован без некоторых функций HAL, которые необходимы отдельный вариант, или может обременять некоторые функции вариантов, которые не используются
эн.глин. Nucleo не использует USB CDCACM, но синей таблетки нуждаются в этом
Ну, возможно, USB CDCACM в конечном итоге оказался бы во всех вариантах LIB -файла, но тогда не будет связан с бинарным
Мне все еще кажется более гибким, иметь варианты в папке системы.
Сжимать
Сб 17 сентября 2016 г. 9:26 утра
Инициализация часов, обычно происходит в HALMX в функциональной наборе, в файле System_stm32f1xx.в. Этот файл должен быть конкретным для каждой платы и, следовательно, должен находиться в каталоге варианта.
Невозможно выполнить общую функцию в системной библиотеке как слабую из -за системы сборки Arduino, системная библиотека находится в архивной форме во время связывания, одно и то же происходит для всех файлов Core и Variant (Arduino строит все во временной библиотеке ). Для линкера невозможно выбрать, какая функция должна быть разрешена, потому что обе версии находятся в разных библиотеках. Я не вижу причины для определения в любом месте общей версии (на самом деле пустой, что означает, что MCU будет работать по внутренним часам по умолчанию), эта функция должна быть определена в каталоге варианта любого варианта.
Невозможно выполнить общую функцию в системной библиотеке как слабую из -за системы сборки Arduino, системная библиотека находится в архивной форме во время связывания, одно и то же происходит для всех файлов Core и Variant (Arduino строит все во временной библиотеке ). Для линкера невозможно выбрать, какая функция должна быть разрешена, потому что обе версии находятся в разных библиотеках. Я не вижу причины для определения в любом месте общей версии (на самом деле пустой, что означает, что MCU будет работать по внутренним часам по умолчанию), эта функция должна быть определена в каталоге варианта любого варианта.
Rogerclark
Сб 17 сентября 2016 г. 10:28
Сламмер написал:Инициализация часов, обычно происходит в HALMX в функциональной наборе, в файле System_stm32f1xx.в. Этот файл должен быть конкретным для каждой платы и, следовательно, должен находиться в каталоге варианта.
Невозможно выполнить общую функцию в системной библиотеке как слабую из -за системы сборки Arduino, системная библиотека находится в архивной форме во время связывания, одно и то же происходит для всех файлов Core и Variant (Arduino строит все во временной библиотеке ). Для линкера невозможно выбрать, какая функция должна быть разрешена, потому что обе версии находятся в разных библиотеках. Я не вижу причины для определения в любом месте общей версии (на самом деле пустой, что означает, что MCU будет работать по внутренним часам по умолчанию), эта функция должна быть определена в каталоге варианта любого варианта.
Невозможно выполнить общую функцию в системной библиотеке как слабую из -за системы сборки Arduino, системная библиотека находится в архивной форме во время связывания, одно и то же происходит для всех файлов Core и Variant (Arduino строит все во временной библиотеке ). Для линкера невозможно выбрать, какая функция должна быть разрешена, потому что обе версии находятся в разных библиотеках. Я не вижу причины для определения в любом месте общей версии (на самом деле пустой, что означает, что MCU будет работать по внутренним часам по умолчанию), эта функция должна быть определена в каталоге варианта любого варианта.
Сжимать
Сб 17 сентября 2016 г. 10:41
Может быть, пришло время внести некоторые изменения в хранилище, у меня будет некоторое время на выходных. Первая цель - поддержать 2 варианта (например,. Nucleo и Bluepill), разделяя необходимые функции. Поскольку Рик работает в своем собственном репозитории, нам нужно лучше работать, каково ваше предложение?
Rogerclark
Сб 17 сентября 2016 г., 11:02
Наверное, лучший подход - клонировать репо, как Рик сделал.
У меня есть мастер -версия, клонированная на мою локальную машину, но я также могу покинуть репо с моей собственной учетной записью GitHub (не в учетной записи STM32Duino), и попробую некоторые подходы
Оригинальный подход Ricks был просто использовать #ifdef, чтобы выбрать другой код в HW_CONFIG, но я думаю, что это станет очень грязным
Затем мы кратко обсудили, используя слабое определение hw_config_init (), но у меня есть опасения по поводу этого.
Так что я собирался просто добавить папку вариантов где -нибудь в папке системы, E.глин. Inside Libstm32f1 и отделяйте общий код от конкретного варианта кода
Я думаю, что решение будет работать нормально, и завтра (воскресенье) у меня будет время, чтобы попробовать его (я UTC +10, так что это уже 21:00, а суббота почти закончилась)
У меня есть мастер -версия, клонированная на мою локальную машину, но я также могу покинуть репо с моей собственной учетной записью GitHub (не в учетной записи STM32Duino), и попробую некоторые подходы
Оригинальный подход Ricks был просто использовать #ifdef, чтобы выбрать другой код в HW_CONFIG, но я думаю, что это станет очень грязным
Затем мы кратко обсудили, используя слабое определение hw_config_init (), но у меня есть опасения по поводу этого.
Так что я собирался просто добавить папку вариантов где -нибудь в папке системы, E.глин. Inside Libstm32f1 и отделяйте общий код от конкретного варианта кода
Я думаю, что решение будет работать нормально, и завтра (воскресенье) у меня будет время, чтобы попробовать его (я UTC +10, так что это уже 21:00, а суббота почти закончилась)
Сжимать
Сб 17 сентября 2016 г. 14:00
ОК, Роджер, я буду разорвать F1 Repo STM32Duino для начала.... И мы видим, теперь это немного сложно.... Но, как я понимаю, это репо, должно быть, соединяет ссылку всех нас.
Рик Кимбалл
Сб 17 сентября 2016 г. 18:21
Я был удивлен количеством используемой оперативной памяти, поэтому я немного копал.
$ arm-none-eabi-readelf-a blinknodelay.эльф >/tmp/a
$ sed -e 's/\+//g'/tmp/a | Sort -t '' -n -k 3,3 | grep -v '08' | grep -v '0'
Num: тип значения, связывание NDX Имя NDX
455: 20000d0c 1 объект Global Default 7 G_RX_DATA
438: 20000004 4 Object Global Default 6 SystemCoreClock
468: 20000b58 4 Object Global Default 7 LEDSTATE
504: 20000000 4 Объект Global Default 6 Интервал
537: 20000b54 4 Object Global Default 7 предыдущая миллис
86: 20000b98 4 объект локальный по умолчанию 7 Uwtick
423: 20000B70 20 Object Global Default 7 Serial1
477: 20000b5c 20 объект Global Default 7 Serial Serial
566: 20000B84 20 Object Global Default 7 Serial2
180: 20000b9c 128 объект локальный по умолчанию 7 g_uarthandle
548: 20001080 140 Object Global Default 7 G_AninputPinconFigured
226: 200001A8 208 Объект локальный по умолчанию 6 g_timer_config
228: 20000c1c 240 объект локальный по умолчанию 7 g_timerhandle
287: 20000278 320 Объект локальный по умолчанию 6 gpio_irq_conf
178: 20000008 416 Объект локальный по умолчанию 6 g_uart_config
391: 20000EC8 440 Object Global Default 7 G_AnoutputPinconFigured
409: 20000d10 440 Object Global Default 7 G_DigpinConfigured
526: 200003b8 1920 Object Global Default 6 G_ANALOG_CONFIG
1920, 440, 440 416 байтов в ОЗУ
Похоже, что g_analog_config, g_digpinconfigured, g_anoutputpinconfigure, может быть некоторыми структурами, которые можно посмотреть, чтобы увидеть, можно ли их оптимизировать
$ arm-none-eabi-readelf-a blinknodelay.эльф >/tmp/a
$ sed -e 's/\+//g'/tmp/a | Sort -t '' -n -k 3,3 | grep -v '08' | grep -v '0'
Num: тип значения, связывание NDX Имя NDX
455: 20000d0c 1 объект Global Default 7 G_RX_DATA
438: 20000004 4 Object Global Default 6 SystemCoreClock
468: 20000b58 4 Object Global Default 7 LEDSTATE
504: 20000000 4 Объект Global Default 6 Интервал
537: 20000b54 4 Object Global Default 7 предыдущая миллис
86: 20000b98 4 объект локальный по умолчанию 7 Uwtick
423: 20000B70 20 Object Global Default 7 Serial1
477: 20000b5c 20 объект Global Default 7 Serial Serial
566: 20000B84 20 Object Global Default 7 Serial2
180: 20000b9c 128 объект локальный по умолчанию 7 g_uarthandle
548: 20001080 140 Object Global Default 7 G_AninputPinconFigured
226: 200001A8 208 Объект локальный по умолчанию 6 g_timer_config
228: 20000c1c 240 объект локальный по умолчанию 7 g_timerhandle
287: 20000278 320 Объект локальный по умолчанию 6 gpio_irq_conf
178: 20000008 416 Объект локальный по умолчанию 6 g_uart_config
391: 20000EC8 440 Object Global Default 7 G_AnoutputPinconFigured
409: 20000d10 440 Object Global Default 7 G_DigpinConfigured
526: 200003b8 1920 Object Global Default 6 G_ANALOG_CONFIG
1920, 440, 440 416 байтов в ОЗУ
Похоже, что g_analog_config, g_digpinconfigured, g_anoutputpinconfigure, может быть некоторыми структурами, которые можно посмотреть, чтобы увидеть, можно ли их оптимизировать
typedef struct {
GPIO_TypeDef *port;
uint32_t pin;
void (*alFunction)(void);
ADC_TypeDef *adcInstance;
ADC_ChannelConfTypeDef adcChannelConf;
#if defined (STM32F100xB) || defined (STM32F100xE) || defined (STM32F101xE) || defined (STM32F101xG) || defined (STM32F103xE) || defined (STM32F103xG) || defined (STM32F105xC) || defined (STM32F107xC)
DAC_TypeDef *dacInstance;
uint32_t dacChannel;
DAC_ChannelConfTypeDef dacChannelConf;
#endif
TIM_TypeDef *timInstance;
uint32_t timChannel;
uint32_t useNchannel;
TIM_OC_InitTypeDef timConfig;
TIM_HandleTypeDef timHandle;
} analog_config_str;
... a sample of an entry ...
analog_config_str g_analog_config[NB_ANALOG_CHANNELS] = {
{
.port = GPIOA,
.pin = GPIO_PIN_0,
.adcInstance = ADC1,
.adcChannelConf = {
.Channel = ADC_CHANNEL_0,
.Rank = ADC_REGULAR_RANK_1,
.SamplingTime = SAMPLINGTIME
},
#if defined (STM32F100xB) || defined (STM32F100xE) || defined (STM32F101xE) || defined (STM32F101xG) || defined (STM32F103xE) || defined (STM32F103xG) || defined (STM32F105xC) || defined (STM32F107xC)
.dacInstance = NULL,
#endif
.timInstance = NULL
},
Сжимать
Сб 17 сентября 2016 г., 8:38 вечера
HALMX широко использует большие структуры в качестве аргументов для функций. Никто не ожидает, что HALMX Core будет меньше....
Rogerclark
Ср 21 сентября 2016 г., 21:29
Я думаю, мы, вероятно, можем обсудить это навсегда и ничего не делать
Самый безопасный вариант, вероятно, - дублировать весь Libstm32f1 и назвать его LibbluePill, тогда мы можем взломать, не нанесло никакого повреждения версии Nucelo.
Мы можем определить, что является общим, и какие изменения, после того, как мы произвели несколько вариантов платы.
Примечание. Я жду или STM, чтобы обратиться ко мне о том, как мы можем идти вперед и изменить код без какого -либо риска нарушения их официальной функции (ы) до совета директоров.
Дублируя Libstm32f1, похоже, делает это, если нам также не нужно изменять файлы в папке Cores
Самый безопасный вариант, вероятно, - дублировать весь Libstm32f1 и назвать его LibbluePill, тогда мы можем взломать, не нанесло никакого повреждения версии Nucelo.
Мы можем определить, что является общим, и какие изменения, после того, как мы произвели несколько вариантов платы.
Примечание. Я жду или STM, чтобы обратиться ко мне о том, как мы можем идти вперед и изменить код без какого -либо риска нарушения их официальной функции (ы) до совета директоров.
Дублируя Libstm32f1, похоже, делает это, если нам также не нужно изменять файлы в папке Cores
