Хочу посоветоваться
Это список библиотек, зависящих от ядра. Есть полностью готовые, есть готовые частично.
Это список библиотек не зависимых от ядра.
В какую сторону продолжать дальше двигаться?
Что нужнее?
Я думаю из периферии в первую очередь - таймер, USART, SPI. Из внешних устройств - дисплеи.
Сегодня кое как допилил симбиоз I2C и EEPROM AT24Cxx.
Есть такие функции
// Чтение/запись массива. Формат: Адрес в EEPROM, Буфер, Количество байт
int16_t Read(uint16_t MemAddress, uint8_t* DataBuff, uint16_t Size); // Чтение массива
int16_t Write(uint16_t MemAddress, uint8_t* DataBuff, uint16_t Size); // Запись массива
// Чтение/запись одного байта. Формат: Адрес в EEPROM
int16_t Read(uint16_t MemAddress); // Чтение одного байта
int16_t Write(uint16_t MemAddress, uint8_t Data); // Запись одного байта
Что ещё туда добавлять?
Пока меня прёт.
Тест
Проверяем уведомления на почту при новом ответе в теме.
@aveal Тест прошёл.
Доделал сегодня датчики BME280, BMP280. По I2C.
Но выложу позже. Сейчас готовлю статью по UART, так как очень удобно отлаживать программу.
Я провел сравнение по объему занимаемой памяти, что-то результат оказался не так внушителен, как я ожидал... Итак, первый проект - из этой статьи - вообще без изменений:
И я создал тестовый проект на HAL с инициализацией USART1 и отправкой 32 тестовых байт:
8.4 КБ флеша против 9.49 КБ.
Вся идея не уменьшении кода, а удобстве пользования.
На МК с малым объёмом памяти - 16 и меньше, HAL забивает вообще 60%.
Здесь можно выборочно взять нужные библиотеки.
Кроме этого. Этот размер занимает вся откомпилированная библиотека. И уже работа с ней отъедает мизер памяти.
Вся идея не уменьшении кода, а удобстве пользования.
На МК с малым объёмом памяти - 16 и меньше, HAL забивает вообще 60%.
Здесь можно выборочно взять нужные библиотеки.Кроме этого. Этот размер занимает вся откомпилированная библиотека. И уже работа с ней отъедает мизер памяти.
Да, понимаю. Также быстродействие будет намного выше я думаю, потому что HAL медленная довольно, даже в некоторых проектах были из-за этого трудности.
потому что HAL медленная довольно, даже в некоторых проектах были из-за этого трудности.
У меня знакомец пишет на HAL.
Когда писал трёхфазный двигатель на таймере, инициализацию делал на HAL. А всё остальное на CMSIS. Почему то на HAL не хотело работать хоть тресни. А там всего то таблица синусов да перегон её в таймер через DMA.
Я то же начинал писать на HAL. Один раз столкнулся с тем, что HAL ни в какую не хотел запускать таймер в одноимпульсном режиме. Один раз запустил и больше не захотел. В чём дело, так и не нашёл.
А насчёт того, что Вы говорили, что переводить старые проекты на новый тип программирования. Зачем. У меня запущен проект на чистом HAL. Потом появились проекты где я HAL обернул в классы. Потом начал куски HAL переводить на прямую работу с регистрами. А потом просто начал писать библиотеки и постепенно в каждом следующем проекте доля написанных библиотек увеличивалась.
Кроме этого, я конечно столкнулся с несовместимостью версий библиотек в разных проектах. В этом случае, при архивации проекта я вместе с проектом пакую и текущие на тот момент библиотеки. Если приходится вернуться к старому проекту, я просто сваливаю в один каталог и проект и библиотеки идущие с ним и редактирую пути доступа.
Случайно наткнулся на этот цикл статей, автору респект громадный, делает свои библиотеки, делится ими, так еще и описывает в статьях.
Всем, кто пользуется библиотеками, так как я начал выкладывать библиотеки без их описаний для разных ядер.
У вас могут возникнуть проблемы с компиляцией. Например есть ядро, для которого не написан SPI, а в библиотеке лежит драйвер дисплея работающего по SPI, компилятор будет ругаться.
Вот здесь ругается на драйвер дисплея:
Заметьте, что крестик стоит напротив *.h и *.cpp, чаще всего он стоит напротив *.h файла.
Что бы этого не происходило, необходимо исключить библиотеку из компиляции.
Делается это таким образом:
Правой кнопкой мыши щёлкаем на соответствующем *.cpp файле и выбираем
Ставим галочки и нажимаем ОК. Больше он нам мешать не будет. Так делается на всех файлах, на которые будет ругаться.
Есть нюансик с SPI. Драйвер зависимый от ядра лежит в каталоге драйверов. "Софтварный" SPI лежит в каталоге библиотек. Вместе они компилиться не будут. Так как они одинаковы по структуре и переменным. Только часть отвечающая за передачу разная. Поэтому нужно исключить из компиляции именно тот, который не собираетесь использовать. Позже могут ещё появиться такие дубликаты. С ними придётся поступать так же.
