[makc 197]

https://github.com/T-head-Semi/xuantie-gnu-toolchain смотрели? Очень даже неплохой тулчейн.

[kan35 7]

On 2/12/2024 at 3:13 PM, BSACPLD said:

Коллеги, можно ли в MounRiver Studio for RISC-V выбирать размер кода (полноту реализации) для функций sprintf/sscanf аналогично тому, как это сделано в IAR?

Чтобы вручную не переключать --specs=nano.specs, полнота выбирается в свойствах линкера. Там же включается поддержка плавающей точки.

[Arlleex 131]

В 13.02.2024 в 21:31, dimka76 сказал:

Тяжело этот форум читать. Глазки выпадают )))

20 лет назад выпадали, и щас зашел посмотреть - ничего не изменилось...😆

[AlexRayne 7]

В 13.02.2024 в 00:19, BSACPLD сказал:

На вывод ещё проще - вся телеметрия в формате "%s%d\r\n" либо "%s%x\r\n".

Других форматов ввода/вывода не предполагается - устройство максимально простое и тупое.

тогда зачем вам printf в 16К кода?  достаточно itoa, puts

[kan35 7]

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

Как вариант - есть еще от coremark printf (а может они сами его где-то позаимствовали), с опциональной поддержкой плавающей точки. Он тоже единицы кБ занимает.

https://github.com/eembc/coremark/tree/main/barebones

[BSACPLD 9]

5 minutes ago, kan35 said:

Он тоже единицы кБ занимает.

Это очень жирно 🙂

Я уже сделал свои функции и устройство уже в серии.

Тему можно закрывать.

[kan35 7]

10 minutes ago, BSACPLD said:

Это очень жирно 🙂

Я уже сделал свои функции и устройство уже в серии.

Тему можно закрывать.

А Вы нам и не нужны уже! Мы же тут плодотворно общаемся)))

(шучу, конечно же)

[Arlleex 131]

1 час назад, AlexRayne сказал:

тогда зачем вам printf в 16К кода?  достаточно itoa, puts

itoa не возвращает длину строки, или хотя бы указателя на последний записанный элемент в предоставленном буфере.

А то получилась полная фигня - передаем буфер - функция возвращает указатель на него же

Из-за этого приходится вызывать strlen() каждый раз после itoa() при самостоятельном формировании строк.

[jcxz 191]

22 минуты назад, Arlleex сказал:

itoa не возвращает длину строки, или хотя бы указателя на последний записанный элемент в предоставленном буфере.

Это ещё ерунда. Хуже что она не позволяет контролировать переполнение буфера. И не позволяет перегрузить функцию записи выходного потока символов на пользовательскую. А семейство printf это всё умеет.

PS: Бесконтрольный sprintf (без контроля переполнения) имхо - моветон.

[Arlleex 131]

21 минуту назад, jcxz сказал:

Хуже что она не позволяет контролировать переполнение буфера.

Насколько я помню - itoa ограничивает длину строки 33 и 65 символами для int и long long, соответственно.

Буквально вчера отказался от монструозных sprintf(), чтобы ужать first-bootloader под МК на нужный размер.

[AlexRayne 7]

1 час назад, jcxz сказал:

Это ещё ерунда. Хуже что она не позволяет контролировать переполнение буфера

а какой буффер вы ожидаете переполнить от itoa?
но так таки да, если функция неудобно, лучше свое наколхозить - из того же printf надергать

[Arlleex 131]

28 минут назад, AlexRayne сказал:

лучше свое наколхозить

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

[AlexRayne 7]

13 минут назад, Arlleex сказал:

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

помойка с кучей "стандартных библиотек". линуксы свои навороты давно пропихивают в стандарт, но он на то и стандарт чтоб как в палате мер и весов неприксновенно лежать

[dimka76 42]

On 4/10/2024 at 12:21 PM, Arlleex said:

чтобы ужать first-bootloader под МК на нужный размер.

http://elm-chan.org/fsw/strf/xprintf.html

 

On 4/10/2024 at 12:21 PM, Arlleex said:

Насколько я помню - itoa ограничивает длину строки 33 и 65 символами для int и long long, соответственно.

Эта функция не включена в стандарт. Поэтому все зависит от реализации.