-
- Дело в другом. Я ведь тебе написал про многопоточность,
реентерабельность и поддержку RTOS, но хочется плюнуть, потому что
реакции не было. LL-код не болеет "детскими болезнями" (ошибками
дизайна) HAL и только за одно это стоит двигаться в направлении LL. - RxTx(07.05.2024 16:33)
- Я несколько дней пытался написать работу с i2c на LL. Не осилил,
бросил. Там во первых нестандартная работа с ACK/NACK при работе с
eeprom, потом нестандартная работа с Stop опять же при работе с
eeprom при выставлении адреса чтения. В связи с этим регистры у
stm32 для i2c сильно замороченные и не очевидные. Короче бросил, и
за полчаса сделал все на HAL. Там все проработано из коробки, в том
числе все нестандартные моменты. И не только в том дело что сложно,
я понял что я не Mty1(91 знак., 09.05.2024 16:16)
- Допустим. Если вам удалось сделать на HAL, это каким-то опровергает сказанное про HAL или то что он предназначен в целом для демонстрационных программ или как разросшееся средство поддержки CubeMX (бывший MicroXplorer)? Драйвера HAL действительно более проработанные чем LL, в них меньше багов и они быстрее исправляются. И еще HAL/LL в разной степени готовности у разных серий. Более того, для USB/ETH LL драйверов вообще нет. А у многих серий и LL драйвера есть далеко не на RxTx(4 знак., 09.05.2024 17:49)
- и это правильно. :-) - Лaгyнoв(09.05.2024 16:59)
- И кроме того, почитав свежую доку на HAL я увидел, что они обещают
полную совместимость с RTOS, в другом месте я прочел что таймауты в
HAL строятся не на циклах на на systick. Ну и стало ясно, что с i2c
на LL мне упираться не стоит. Думаю более крутой программер осилил
бы, но закопаюсь в этом. Mty1(8 знак., 09.05.2024 16:31, картинка)
- Вам же никто не сказал "не используйте HAL, он вообще неработоспособен". Сказано было иное, что есть проблемы. - RxTx(09.05.2024 18:04)
- все хулители HAL-а делают это из принципа, свою ученость показать. Т.е. вот это как раз - "я более крутой программер". А когда надо, чтобы всё просто работало и нет времени на свою крутизну, делаем на HАL-е. :-) - Лaгyнoв(09.05.2024 17:02)
- Я много думал над твоим сообщением, это серьезная тема. И не отвечал не потому что забил. Не раз читал его. И кажется есть что возразить. Напишу завтра, дай собраться с мыслями. - Mty1(09.05.2024 02:13)
- Я несколько дней пытался написать работу с i2c на LL. Не осилил,
бросил. Там во первых нестандартная работа с ACK/NACK при работе с
eeprom, потом нестандартная работа с Stop опять же при работе с
eeprom при выставлении адреса чтения. В связи с этим регистры у
stm32 для i2c сильно замороченные и не очевидные. Короче бросил, и
за полчаса сделал все на HAL. Там все проработано из коробки, в том
числе все нестандартные моменты. И не только в том дело что сложно,
я понял что я не Mty1(91 знак., 09.05.2024 16:16)
- Если ловите наносекунды - то регистры, а если вы не знаете какой МК в устройстве будет через пол года, по принципу какой смогли купить - то куб. - =AlexD=(07.05.2024 16:13)
- Если углубленно знаете матчасть, то да - регистры. Мне нужно быстро собирать проекты на разных платформах - отсюда времени на углубленное изучение нет. Поэтому LL и если сложная периферия HAL, в случае с STM. Ели постарее микросхемы - SPL. С китайскими, понятно, их SPL подобные библиотеки. Я только STM8 на регистрах ваял из экономии места. - vesago(04.05.2024 14:26)
- Пример длинного и сложного можно? И желательно в виде асма после
-flto - POV(04.05.2024 14:06)
- Ну например чтение из eeprom. После HAL выглядит монструозно Mty1(1314 знак., 04.05.2024 14:31)
- абалдеть... :-) то ли дело - HAL_I2C_Mem_Read(&hi2c1, (uint16_t) TARGETADR<<1, ADR24C, I2C_MEMADD_SIZE_16BIT, CHT24C64, 64, 15); - Лaгyнoв(04.05.2024 15:56)
- А причем тут LL? Это ж просто обертка над обращением к регистрам... POV(130 знак., 04.05.2024 14:48, картинка)
- А что у вас под EXEC() спрятано? Поделитесь, пожалуйста? - Dingo(07.05.2024 11:30)
- Выход если нет указанного события... POV(138 знак., 07.05.2024 11:58, картинка, картинка)
- В копилку. Dingo(139 знак., 07.05.2024 12:04, картинка)
- Ну а как сделать компактнее? Да и код весь линейный, нет тут беды
от гото... POV(87 знак., 07.05.2024 12:13, картинка)
- Канонично так наверно Andreas(304 знак., 07.05.2024 12:29)
- Тут break от goto отличается только чувством прекрасного
конкретного персонажа. На этот случай у меня выше приведен макрос
TIMED_THIS ))) - POV(07.05.2024 12:31)
- Это да, но любителям больших макросов отдельный котел. Разбирался с
sdk от nrf, там сдохнешь в таких черезподвывертах. - Andreas(07.05.2024 12:38)
- Да, работал и с их кодом для 52840 - опплевался - POV(07.05.2024 14:08)
- Это да, но любителям больших макросов отдельный котел. Разбирался с
sdk от nrf, там сдохнешь в таких черезподвывертах. - Andreas(07.05.2024 12:38)
- Тут break от goto отличается только чувством прекрасного
конкретного персонажа. На этот случай у меня выше приведен макрос
TIMED_THIS ))) - POV(07.05.2024 12:31)
- Канонично так наверно Andreas(304 знак., 07.05.2024 12:29)
- Ну а как сделать компактнее? Да и код весь линейный, нет тут беды
от гото... POV(87 знак., 07.05.2024 12:13, картинка)
- В копилку. Dingo(139 знак., 07.05.2024 12:04, картинка)
- Выход если нет указанного события... POV(138 знак., 07.05.2024 11:58, картинка, картинка)
- А что у вас под EXEC() спрятано? Поделитесь, пожалуйста? - Dingo(07.05.2024 11:30)
- Ну например чтение из eeprom. После HAL выглядит монструозно Mty1(1314 знак., 04.05.2024 14:31)
- Дело в другом. Я ведь тебе написал про многопоточность,
реентерабельность и поддержку RTOS, но хочется плюнуть, потому что
реакции не было. LL-код не болеет "детскими болезнями" (ошибками
дизайна) HAL и только за одно это стоит двигаться в направлении LL. - RxTx(07.05.2024 16:33)