Harvester

Вы передаете какие-то значения. Откуда их возьмет программа? Если константые данные помещаются в регистры, то их значение хранится в коде команды, как длина data[] в Вашем случае.

Про какие области вопрос? Если про DataTable, то, естественно, разные - это области из FLASH, откуда читаются команды. Если про передаваемые параметры (стек), то одинаковые. Точнее, начало одинаковое, а конец зависит от размера пакета.

Немножко не так. Вы заранее выделили на стеке 16 байт и при каждом вызове функции нужно руками указывать, сколько байт передается. То есть уже две точки возможных ошибок. А у ТС в каждом блоке выделяется ровно столько, сколько нужно и длина блока, передаваемая в функцию, считается автоматически. Это не противоречит стандарту, позволяет исключить возможные ошибки - что еще надо программисту для счастья :)

У меня были определенные глюки с утилитами STM (какими уже не помню) из-за учетной записи на русском языке.

Из опыта могу сказать - когда I2C вытаскивают за пределы платы, ничем хорошим это не кончается. Каждый интерфейс должен использоваться по назначению. Либо делать свой термодатчик: I2C + мелкий МК, а это уже по RS-485 цеплять

Никак. На этапе разработки закладывать стек побольше (прикинуть число уровней вложенности подпрограмм/прерываний, сколько байт нужно на каждый, есть ли функции с 20-ю передаваемыми параметрами и т.п.). На этапе отладки уточнить его размер. Самый простой вариант - перед стартом программы заполнить пространство стека FF, а потом смотреть, сколько программе реально понадобилось.

Прошу совета. Имеется 4-контактный разъем GT36 (Hirose) В каталоге в графе "Примечания" написано: Contact numbers 1 to 3 are available by de-embedding При этом в самом datasheet об этом ни слова. Как в данном случае можно перевести этот de-embedding? Насколько я понял, этот термин используется применительно к мат. моделированию. А какое отношение он имеет к реальной железке - непонятно :(

Я не знал, думал, что "e300" будет достаточно. MPC5125YVN400:

Может и не нужны, но так в оригинале написано :) Прямо вторая строчка документа по первой ссылке: Several STM32 microcontrollers address market segments requiring digital signals with highly accurate timings, namely digital power supplies, lighting, non-interruptible power supplies, solar inverters and wireless chargers.

А слона-то я и не заметил. :))) Я почему-то уверил себя, что в процессоре нет контроллера. Думал, что просто ногодрыгом выводится. На самом деле контроллер TFT есть. Спасибо.

Основная проблема - TFT без контроллера и CPU без контроллера. Но спасибо за наводку, посмотрю.

С таким же (вроде как) успехом можно просто задать необходимый буфер для fwrite() - setvbuf(). Поэтому и возник вопрос - это хитрость или глупость? :)

Программа формирует на диске бинарный файл достаточно большого размера (десятки мегабайт). Содержимое этого байта формируется из 32-битных значений. Предыдущий программист реализовал самодельную буферизацию вывода: записываемые данные сначала заносятся в промежуточный буфер (127 КБайт), а при его заполнении вызывается функция write(). Не могу понять - чем этот подход лучше по сравнению с использованием fwrite(), которая, по факту, делает то же самое?

GPU нет, разрешение маленькое 480 x 272, 4.3'' Сложной отрисовки тоже нет, только стандартные элементы интерфейса

Сам спросил - сам ответил. 1. Qt самостоятельно пишет в Framebuffer, не требуя никаких прослоек. http://doc.crossplatform.ru/qt/en/4.4.3/qt-embedded.html 2. Похоже, только оптимизацией приложения. 3. Реализовать для данного фреймворка вывод в Framebuffer. Но вовсе не факт, что удастся как-то ускорить графический интерфейс.