ох... и как жить? почти любой парсер входящих сообщений занимается разбором символьных массивов в нечто большее...

следить надо читать и помнить. Тем профик и отличается от не пойми кого, у него есть опыт

Сергей, Вы правы. В 2014 году. Для 2009-2010 высказывание смысла не имеет. Как никто бы лет 20 назад не понял, почему смешно, что телефон фотографировать может, а фотоаппарат не может звонить. Кстати, уже и фотоаппарат почти может, коль WiFi в нем уже есть. А лет 30 назад никто бы не понял фразу: "забыл трубу дома". Подумали бы, что музыкант.

П.С. Не удержусь, расскажу случай с собственным ребенком в садике. Дело было 2 года назад. В стране, где я живу, в саду проводят тесты, насколько хорошо дети владеют языком, чтобы вовремя отправить к логопеду, например, или позаниматься дополнительно в группе. Для этого им показывают картинки, просят назвать предмет, эмоции лица, и т.п. Родители могут молча присутствовать. И вот показывают моему мальцу картинку, на которой изображено что-то закругленно кубическое, красное, с кругом посередине и точками. Он смотрит долго, хмыкает и говорит: "божья коровка". Тетка начинает ставить наводящие вопросы. Реакция та же - жук, и все. Тогда тетка раскрывает ребенку глаза на этот удивительный мир и утверждает, что изображен телефон (для меня было очевидно: телефон с тубкой сверху, наборной диск с дырочками). На что мой малец говорит: "это не телефон, телефон - с кнопочками и картинкой". Вот так. Что скажут его дети на нынешние смартфоны, имея вживленные сети с приемом прямо в мозг?

Получается (с), что в голове у программера надо навести порядок. Что программеру предоставлен такой инструмент, как типизация. Что этот инструмент помогает избежать ошибок. Что используя void, программер отказывается от этого инструмента, а значит, всю ответственность, по части контроля за ошибками, программер берет на себя. Из чего следует, что очень желательно избегать void, где это только возможно. А если по каким-то причинам пришлось отказаться от типизации, то худшее место, где это можно сделать - "пограничная застава". ИМХО, серьезный повод пересмотреть стиль программирования.

даже в мего защищенном С# есть object и var. Так что насчет стиля не согласен, согласен с тем что если пошли по этому пути то надо следить самому и учитывать особенности архитектуры.

В большинстве случаев void * может быть прекрасно заменен на char * без какого либо ущерба для функционала или производительности. Void нужен больше стилистически, что-ли, для понятности кода.

Похоже, я окончательно потерял нить ваших рассуждений. Если вы работаете с CM-0 - используйте документацию и примеры от CM-0. Причем тут CM-3 независимо от года его рождения?

Это глубокое заблуждение. Будет ущерб производительности программиста. В подавляющем большинстве случаев void * используется в параметрах функций, подобных memcpy(), read(), write(). Это позволяет существенно разгрузить исходник от явных приведений типа при вызове таких функций (приведение в этом случае делается один раз внутри функции). При замене на char * возможность неявного приведения теряется, исходник загромождается явными приведениями. А загроможденный исходник - это совершенно ненужные потери времени на написание и сопровождение.

Нет, известно не было. Но ARM7TDMI (как и нынешний CM0) не поддерживает невыровненные обращения к памяти. Пишете переносимый код - пишите его правильно. Ассемблерный код не переносим между архитектурами.


А от PDP-11 ассемблерный код не пробовали Cortex-у скормить? CM0 и CM3 - разные процессоры, с разной системой команд.


используйте time_t именно как time_t, не приводите его к другому типу.


И в чем проблема написать
?
Получите более переносимый результат.


Приведение указателя от большего типа к меньшему переносимо всегда. В обратную сторону - непереносимо. Пляски с __packet (__attribute, #pragma pack и т.д.) зависят от компилятора. Использовать их можно (и иногда нужно), но переносимости ожидать нельзя.

Я о том, что нельзя предвидеть будущее с одной стороны, и легко умничать (не упрек Вам, а общее рассуждение) и тыкать НЫНЕ носом в код, несовместимый с процессором, которого не было и в помине в период написания библиотеки. И о том, что несмотря на стремление и утверждение ARM "забыть" ассемблер при работе с Cortex (это же их рекламный слоган был!), есть навороты, когда без этого самого ассемблера (смотри тот же ARM для SVC) ну никак. Я не спорю, что -M0 это иное, чем -M3, и надо учитывать СЕЙЧАС особенности -M0, но учесть их 4-5 лет назад было невозможно по определению. И так будет всегда. И допахивать код придется всегда - тот же time_t. Тут один советчик опустился до вопроса, не пробовал ли я код с PDP-11 на Cortex перенести. Он, видимо, предполагал, что я не знаю, что такое PDP-11. Но в отличие от него, я еще помню НАИЗУСТЬ многие бинарные коды инструкций PDP-11: в советское время CM-1420 и "Электроника". Кстати, MSP430 - это тот самый PDP-11 по идее.

Задолго до появления CM3 были процессоры, требовавшие правильного выравнивания данных. Более того, таких процессорных архитектур и тогда и сейчас - большинство.
Вы заложились на редкую фишку и теперь на что-то жалуетесь.

Вот что-то не уверен я, что там не обойтись без ассемблера. С другой стороны, низкоуровневый обработчик исключения по определению не может быть переносимым.

В _одном_ месте переопределите time_t как long long - и все остальное поедет без переделок. Конечно если вы не преобразовываете time_t в void-указатель.

Я тоже прекрасно помню коды PDP-11, не стоит со мной мериться известным предметом. И придумывать за меня, что я предполагал, тоже не надо.

Сергей Борщ очень правильно указал зачем применяется тип void *. Правда часто для массивов в том же memcpy я явно привожу их к типу void *, тем самым убивая полученную выгоду, но мне кажется что так код понятнее в некоторых местах. Это сродни комментариям, то есть как бы явное указание что в этом месте я не ошибся, а именно это хотел передать в функцию...

Но конструкция (char *)& - правда весьма не маленькая, и если параметров много, строчка будет длинной...

Перевожу на русский язык: в большинстве случаев "грузовик" может быть заменен на "автомобиль". У меня только один вопрос, стоит ли при таком подходе удивляться, что вместо контейнеровоза, прислали Форд Фиеста? А в качестве такси, к подъезду подали Камаз?


Стесняюсь спросить, а какая связь, между ТИПОМ time_t и неким ЗНАЧЕНИЕМ? Подобный вопрос говорит лишь о непонимании, что есть тип/типизация.


Вот именно поэтому, надо научиться мыслить абстрактно. Надо научиться простой вещи, забыть сами понятия "сколько бит", "какой адрес". Если, не дай Б-г, в голове у программера всплывает вопрос "а сколько бит char?", он должен тут же себе ответить - не твое собачье дело. Аналогично с адресом. Надо вбить себе в голову, что у переменных есть только один адрес - "где-то". Сколько это "в граммах" - не программерова ума дело. И, предвосхищая следующий вопрос, сразу отвечу, что понятия "адрес" и "область памяти"/"тип памяти" означают совершенно разные вещи.

Вот так, легко и непринужденно, раскрывается тема сисек написания переносимого кода.


Ну включаем логику. Как может стать понятнее, если табличку "Иванов, 28 лет, пневмония, лечащий врач Сидоров" заменить на табличку "очередной больной"?

А вы по специальности работали? ...

мне вот очень важно сколько бит int, потому что когда вы его массивами на компьютер шлете и обратно принимаете хорошо бы знать сколько переменных пошло. Так же я напомню что есть big endian и little endian, хорошо про них не знать, но в железе редко имеем дело с одним процессором, а если еще ПЛИС, а в ней удобнее big endian, а между процом и ПЛИС тоже интерфейсы и передача данных.

также мы вспоминаем о структурах и их преобразовании в байтовый массив и обратно, где так же важно знать типы, размеры полей, их последовательность и прочее... И тут в полный рост встает архитектура, по посылайте на компьютер не пакованные структуры с какого-нить СМ0, и попробуйте их с позиции "не програмерово собачье дело" их преобразовать.


Ну и пример про грузовик:
void - это не просто машина, это такая машина, которая может все, и потому если запросили void машину, то она сто пудово подойдет, только надо с пониманием к ней отнестись, и найти где вход, а все остальное она сделает, и груз перевезет и на работу по пробкам доставит. И продолжая этот пример, трудности на себя берет водитель, чтобы клиенты не парились!




не такая замена как вы говорите, а такая:
"Иванов, 28 лет, пневмония, лечащий врач Сидоров"
меняем на
(очередной больной) "Иванов, 28 лет, пневмония, лечащий врач Сидоров"
согласитесь что во 2 случае информации чуть больше, как минимум что мы именно хотели включить этого человека как нашего очередного больного.

Иногда в поисках ошибок находятся разные места кода, и смотрите на них и думаете а нет ли тут ошибки, и иногда с таким явным уточнением вы понимаете что тут все верно. Особенно это часто это происходит когда идут двойные указатели и всякие их разименования...

Это очень плохо. Потому что все, что должен знать программер о типе int, что это тип, _удобный_ для процессора.


Пересылка int между машинами, это тоже очень плохо, говорит о низкой квалификации программера. Обмен между машинами должен идти в каких-либо data_t, а не int. И пусть не вводит в заблуждение тот факт, что по каким-то причинам, в т.ч. из-за совпадения кол-ва разрядов, данные представляют все тем же int. Повторюсь, int, это некоторый тип, удобный для процессора и ничего более. Любые совпадения - случайны, все персонажи - вымышлены. (с)


А причем здесь железо? Мы говорим о том, насколько программер понимает/чувствует инструмент, которым пользуется. В общем случае, программа должна быть написана так, что бы было плевать, на каком endian работает процессор. Вот мы снова вернулись к переносимости кода.
Если писать так, то будет зависимость от endian:


А если написать так, то исполняться будет одинаково, при любом endian:
l = d >> 0;
h = d >> 8;


Какой любопытный постулат. Можно с этого места попобробнее. А то моим ПЛИС всегда было по-барабану, с каким endian работать.

- грузины, лучше чем армяне
- чем лучше?
- чем армяне!
(с)


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


Ну вот не надо фантазировать, а? Здесь void, это то же, что и просто машина. Без уточнений, что она там может, а что не может.


Вот опять, выдаем желаемое за действительное. Если запросили void машину, это не значит, что она подойдет. Это значит, что клиент ничего не сообщил о том, какая машина ему нужна. Подойдет или нет - никто не знает. Собсно, в обсуждении выше это и произошло - на каком-то ядре void * работало корректно, но в один прекрасный день, случилось то, что и должно было случиться.


Да-да. Я прям представил себе, как на погрузку 2т сахара, приехало такси и водитель "взял на себя все трудности". На своем горбу, видимо, перетаскал, от склада до магазина. Главное, что клиенты не парились.


Сдаюсь. Видимо, умение программировать дано не каждому.

последние вы верно заметили. Точно не каждому%)...

из наводящих вопросов, если с big и little проблем нет, то нафига функция смены порядка байт иногда(напишем осторожно) поддержана на железном уровне?

И еще спрошу известна ли вам разница между SPI и UART? не очевидная в синхронизации, а другая, что в битах лежит?

Кстати, насколько удобен int для 8051?


Мне правда интересно каких приемов я не знаю. Вот мне дают описание что с компьютера придет структура

struct
{
int32_t OverLoadFlags;
int32_t SpeedX;
int32_t SpeedY;
int32_t SpeedZ;
int32_t SpeedRx;
int32_t SpeedRy;
}


вот как вы это оформляете в вашей программе, приемную часть? При условии что вы не заботитесь о битности? Приведите пример?

Конечно. В 2/3 случаев, мне попадается не программирование, а г*внокод(с). Главное, не путать эти два понятия.


Новое слово в интерфесах. Про ПЛИС ответа не дождался. Но может хоть про это дождусь. Шо, вот прям структура приходит? Там, поди, шина специальная, на каждого члена структуры - своя subbus?

ну в целом все как бы ясно, и про вас и про ваш подход. Творческих успехов вам.

Согласен. Потихоньку слиться - лучшее, что можно сделать в данной ситуации. Хотя немного жаль. Читать про "удобный для ПЛИС endianness" и "мега-интерфейсы, умеющие передавать данные целыми структурами" было весело.

Раз уж коды инструкций на наизусть помните, может и требования к выравниванию переменных не забыли? На всякий случай: ваш код и на PDP-11 работать не будет.

Подскажите пожалуйста, как увидеть карту занятости оперативной памяти например в Keil ?

если опустить маалоки и рекурсию, то надо поставить галку сгенерить карту памяти, и там будет написано сколько каких переменных и где лежит, какие функции, сколько они стэка отжирают и так далее...

project options -> listing -> memory map