Arduino.ru

Никак не надо преобразовывать. Положите свои байты в переменную типа long в правильном порядке и ничего делать не нужно - переменная сама станет равной 320400

А вы батенька - ВРУН. Ай-яй-яй. Int в Ардуине умещается в двух байтах.

/**/
//---------------------------------------------
//-------компоновка--------------------------------------
//------main()---------------------------------------
void setup() {
  unsigned long num = 0x90E30400;
  Serial.begin(9600);
  Serial.println(num);// выводится 2430796800
  Serial.println((long)num);// выводится -1864170496
}

void loop() {
}
/*Скетч использует 1694 байт (5%) памяти устройства. Всего доступно 32256 байт.
  Глобальные переменные используют 186 байт (9%) динамической памяти, оставляя 1862 байт для локальных переменных. Максимум: 2048 байт.
*/

Порядок байт обратный

У Т.С. чихарда в исходных и выходных данных   0x4E390 == 320400

/**/
//---------------------------------------------
//-------компоновка--------------------------------------
//------main()---------------------------------------
void setup() {
  unsigned long num = 0x0004E390;
  Serial.begin(9600);
  Serial.println((long)num);// выводится 320400
}

void loop() {
}
/*Скетч использует 1584 байт (4%) памяти устройства. Всего доступно 32256 байт.
  Глобальные переменные используют 186 байт (9%) динамической памяти, оставляя 1862 байт для локальных переменных. Максимум: 2048 байт.
*/

всё верно - Протоны должны бомбить Туву.

я имел ввиду, что 2 символа это один байт )) 

Вы не поняли, что хотел сказать Вам qwone.

В разных реализациях Си целый тип имеет различную длину. У Ардуино - это два байта, а на той платформе, с которой Вы читаете данные - 4.

В этом случае на Ардуино нужно использовать не int, а long (как Вам указал ЕвгенийП). Ну  и по порядку: младший байт идет первым.

что значит младший? меньший по значению?

https://ru.wikipedia.org/wiki/%D0%9F%D0%BE%D1%80%D1%8F%D0%B4%D0%BE%D0%BA...

Значит так - для начала, Вы ДОЛЖНЫ знать, какой байт старший и какой младший и в Вашем примере старший именно самый правый байт. Предположим, что эти 4 байта - элементы массива a[4] и имеют номера с 0 по 3 (слева направо).

А вот дальше преобразование (достаточно простое и правильное - это немаловажно) будет выглядеть приблизительно так
long l = (((((a[3]<<8)+a[2])<<8)+a[1])<<8)+a[0];

Я бы через union или через указатель на байт положил бы и не парился бы.

Евгений, мы об этом уже говорили - это небезопасно (в смысле непереносимо на разные endian), но в данном конкретном случае вполне допустимо.
Но я всегда пропагандирую правильный подход, даже когда он не то, чтобы совершенно необходим.

ГарриС! Я вот подумал, аж вспотел, но ни одного пром.контроллера, из актуальных, и чтобы big endian, не вспомнил.

Это в порядке деMISRAизации ;).

Здесь форум по Ардуино. Вы можете назвать модель Ардуино для которой это создало бы проблемы?

Правильность понятие не абсолютное. В разных местах разные вещи правильны.

AVR32 (оба семейства), STM8 - это из современных, с которыми я работал.
А из распространенных ранее с которыми я работал - ARM7, ARM1176 (по выбору) мотороллеры практически все (без вариантов).
Ну и конечно, Cortex M3 во всех видах, который bi-endian, Вы хотите рискнуть и поставить на то, что компилятор в конкретной среде на включен на big?

AVR32 и моторолы это да, про них забыл. И как-то стм-8 на ум не пришел. Спасибо!

АРМ, они би, а значит будут настроены как литл, что естественно.

Ведь понятно, что биг ендиан - извращение. ;)

Я рискнуть - да Господь с Вами. Я Вас попросил назвать модель Ардуино, для которой мой код бы не работал. Назовёте - буду знать. Пока же Вы ничего не назвали, а вместо этого я слышу про какие-то моторолы, и прочие кортексы. Здесь форум про Ардуино - если Вы не заметили.

Что же касается переносимости между Ардуино и Кортексом, так её нет и не будет вовсе не из-за формата чисел :)

Не в этот раз.

Достаточно запустить простейшёю проверку и убедиться в "правильности"

void setup() {
	Serial.begin(115200);
	const char unsigned a[] = { 1, 2, 3, 4 };
	
	const long l = (((((a[3]<<8)+a[2])<<8)+a[1])<<8)+a[0];
	
	Serial.print("l=");
	Serial.println(l, HEX);
}
void loop() {}

Если здесь "плохо видно", можно напечатать более наглядно, результат тот же.

#include <stdio.h>
static int serial_fputchar(const char ch, FILE *stream) { Serial.write(ch); return ch; }
static FILE *serial_stream = fdevopen(serial_fputchar, NULL);

void setup() {
	stdout = serial_stream; // эта строка первая в setup
	Serial.begin(115200);
	const char unsigned a[] = { 1, 2, 3, 4 };
	const long l = (((((a[3]<<8)+a[2])<<8)+a[1])<<8)+a[0];
	printf("l=0x%08lx\n", l);
}
void loop() {}

Может так?

static int serial_fputchar(const char ch, FILE *stream) {
  Serial.write(ch);
  return ch;
}
static FILE *serial_stream = fdevopen(serial_fputchar, NULL);

void setup() {
  stdout = serial_stream; // эта строка первая в setup
  Serial.begin(9600);
  const char unsigned a[] = { '1', '2','3', '4' }; //< делать через ' '
  const long l = (((((a[3] << 8) + a[2]) << 8) + a[1]) << 8) + a[0];
  Serial.print("l=");
  Serial.println(l, HEX);// вывело l=3231
}
void loop() {}

  Serial.println(l, HEX);// вывело l=3231

Так неправильно ж вывело!? Зачем спрашивать "так или не так"?

Да ладно придираться, ну, забыл человек преобразовать тип. При первом же запуске увидит лажу и подправит.

Так-то понятно, что он имел в виду.

Когда человек врубает ментора и пишет

То, неплохо бы преобразовывать типы, и, что самое главное для программиста, проверять код перед публикацией.

Я нормально отоншусь к структурастам, мисрастам и прочим, считающим, что если из чемоданчика мастера выбросить половину инструментов, то качесво его работы улучшится, но лишь до тех пор, пока они не лезут везде с утверждениями, что их ересь - самая правоверная, и уж тем более не иллюстрируют это "простым, правильным, но неработающим" кодом.

Сначала никак не мог понять, что за проблема, на которую указал Ворота (а она действительно есть) - потом понял.
В последнее время чаще работаю под MinGW, естественно на х86 и там все нормально, но лишь потому, что там int имеет длину 32.
А для Ардуино, действительно, получается неверно, может быть, можно ключами компиляции вытащить, но это очень плохой путь и должно быть явно указано, что тип промежуточных результов (long)
long l = ((((((long)a[3]<<8)+(long)a[2])<<8)+(long)a[1])<<8)+(long)a[0];
Что интересно,
long l = ((((((long)a[3]<<8)+a[2])<<8)+a[1])<<8)+a[0]; или
long l = (((((a[3]<<8)+(long)a[2])<<8)+a[1])<<8)+a[0]; тоже приводит к верным разультатам, а вот
long l = (((((a[3]<<8)+a[2])<<8)+(long)a[1])<<8)+a[0]; все равно приводит к ошибке.

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

Еще раз скажу - недопустимая небрежность, приношу извинения.