Прочитал следующее в ARM System Developer's Guide.

И переделал все локальные переменные на uint32_t.
Вопрос - как я понимаю это касается и аргументов передаваемых в функцию?

Да. И возвращаемых значений тоже.
Не касается это лишь управляющих структур, массивов, которые используются в программе. Чтобы место экономить.

А чтобы код оставался более-менее оптимальным при использовании на других архитектурах, можно использовать uint_fastXX_t

Ну а вот например

тут у меня unsigned char потому что это касается UART я передаю данные 8 бит. или все равно привести к uint32_t?

uint_fastXX_t это если я захочу перенести код на AVR

Конечно, нет. Где нужен char, там должен быть char.
Тем более, вы передаете указатель (32-битовый).

спасибо. придется засучить рукава. этож тысячи строк кода надо править.

Сообщение отредактировал Jenya7 - Jan 20 2015, 12:06

Если есть ну очень сильное желание, то этот код можно соптимизировать, чтобы он работал с 32-битными значениями. А оно сильно надо ? Этот код критичен к скорости выполнения ?
Да, тогда еще возникнет ряд проблем, если размер массива не будет кратен 4 байтам, придется вводить пляски с бубном. Кроме того, могут возникнуть проблемы с выравниванием всего массива входных данных по границе слова. Если char* автоматически выравнен по границе байта, то uint32* будет выравнен по границе 4-х байтов. Если попытаться вычислить сумму начиная с невыравненного адреса, будут проблемы, в т.ч и с производительностью

Общие замечания:
1. в качестве первого параметра надо использовать const unsigned char*, облегчается жизнь себе и компилятору
2. эта контрольная сумма - дерьмо. Она не обнаруживает перестановку байтов, например. Есть гораздо более надежные методы и довольно простые - adler, fletcher checksum, ну и классические CRC

Сообщение отредактировал CrimsonPig - Jan 20 2015, 12:09

это poor man CRC - быстро и просто без заморочек.
а вообще прибор работает от батарейки поэтому скорость любой функции для меня важна - быстро отработал и пошел спать.
а чем const упрощает жизнь кроме того что не дает модифицировать строку?

Сообщение отредактировал Jenya7 - Jan 20 2015, 12:17

1. "Просто и без заморочек" - это очень хорошо... только вот с обнаружением ошибок будет весьма плохо.
2. про батарейку - вопрос спорный "быстро отработал" - не значит "мало съел". "Скорость любой функции" соптимизировать невозможно. Например, после долгого вырывания волос из попы автор таки соптимизирует свой алгоритм для работы с 32-битными числами. При этом размер кода вырастет в 2 раза, скорость выполнения увеличится на 0.1%, в то время как эта функция как вызывалась раз в секунду, так и вызывается. Оно того стоило ? Все равно потребление электричества надо будет мерять. Не факт что оптимизация по скорости уменьшит потребление энергии.
3. если гениальный автор с бодуна в своей функции напишет не val=*p++, а *p++ = val, и не протестирует (а некоторые вещи почти невозможно протестировать), то впоследствии может быть горько и обидно. Для меня использование const - это как личная гигиена.

обратите внимание на reduces code size.

Книжки надо не только читать, но еще и понимать.
Например, замена uint_8 на uint_32 в этом примере вполне себе сможет уменьшить размер кода и сделать мир лучше:
for(uint8_t i=0; i<100, ++i)
{ [do something] }

Что будем делать тут?

uint32_t CalcCRC(void* apData, uint32_t aNumBytes);

uint8_t buffer[100];
uint32_t crc = CalcCRC(buffer, 64); //-- очень хорошо, правда ?
crc = CalcCRC(buffer+17, 13); //-- а тут ? Весело? как насчет оптимизации CalcCRC для работы с uint32_t* ?

Сообщение отредактировал CrimsonPig - Jan 20 2015, 12:48

нет извините меня. то что вы передаете в функцию в качестве аргумента это ваша ответственность. на то вы и программист.

А вот и не извиню, такая я свинья если благородный дон вдруг посмотрит на имплементацию нормально написанной функции, типа библиотечной strlen, то он вполне может рассчитывать увидеть там не
while (*p++), а вполне себе развесистый код, который пытается считать длину строки наиболее оптимальным способом с учетом выравнивания данных, учета невыравненных хвостов итп. В общем случае, этот код вообще платформо-зависим для достижения макс. производительности.
При этом strlen не заботит, передают ли ей указатель на выровненные или невыровненные данные.
Опять же, такая оптимизация может быть избыточна. Если всегда работать с правильно выровненными данными, многи вещи становятся проще, правда можно получить exception при попытке поковыряться с байтами в середине буфера

А складываете вы их всегда в массив unsigned char? И берете всегда из массива unsigned char? Эта функция по идее считает CRC чего угодно. Вот и передавать ей надо "указатель на что угодно", т.е void const *, а внутри заводите уже временную переменную типа "указатель на байт" и присваивайте ей переданный указатель с явным приведением типа. Это позволит написать
избежав явного приведения типа (unsigned char const *)&Message в большинстве точек вызова. А это разгружает исходник, делая его более легкочитаемым.

Привести к uint32_t что? Вы передает указатель. От того, на какой тип этот указатель указывает его размер не изменится. А вот если размер ваших сообщений по спецификации протокола не может превышать 255 или 65535 байт, то параметр len имеет смысл делать uint_fast8_t или uint_fast16_t.
Не обязательно AVR. Вы можете захотеть его перенести на 16- 32- или 64-битную архитектуру, которая умеет делать арифметику с числами 8- или 16-битной разрядности (MSP430 или персоналку). И чтобы этот код и на другой архитектуре тоже был оптимальным без перелопачивания тысяч строк кода, имеет смысл сразу писать его грамотно (или хотя бы стараться писать грамотно).

Ик... найдите 3 отличия
1. void*
2. const void *
3. void* const
4. const void* const

void Foo(const void* apData), так ведь ?