fatlortroll

Проблемы при линковке C++-кода обычно возникают при попытках использовать декорированные функции, как обычные C-шные. А вообще было бы неплохо в первом же сообщении эти проблемы и продемонстрировать. Пытаться угадать, что-же сломалось без какой-либо информации -- тяжко.

Выделяется память, и не освобождается. Уже проблема. Почему-то выделяется _tcpСlient.Available байт памяти, а читать пытается buffer.Length (кстати, откуда у buffer, который простой массив, берётся Length? как это вообще компилируется?). Ну и в конце концов, отчего не передать в ns.Read указатель на глобальный массив, и его размер? Не надо будет каждый раз выделять память в потоке.

Вот здесь пишут, что привилегированный режим по умолчанию доступен сразу после сброса контроллера: Thread mode is privileged out of reset, but you can change it to user or unprivileged by...

А в прошивке используется выделение памяти на куче (операторы new, new[]), или всё статически на этапе компиляции задаётся?

Массив с изменяемыми данными, или с константами? Насколько сильно отбирает ОЗУ остальная программа? Если добавить-убрать глобальных переменных, расположенных в ОЗУ, размер массива, с которого появляется ошибка, будет изменяться?

Можно и в OpenModelica попрактиковаться. Вполне достойная штука, много примеров, хорошая справочная система.

Ещё с утра смотрел -- не было, а тут вот какая радость! Будем пробовать.

Скопируй ту переменную в оперативку, и изменяй её, как хочешь. И, кстати, используется встроенная flash-память контроллера, как я понимаю? Она, разве, позволяет изменять данные меньше, чем страницей?

Хе... Так скрипт вместо размера увидит это самое sizeof(TestStruct), и, вдогонку, не узнает количество полей в той структуре, или элементов в массиве. А какой профит от заполнения полей через define-ы?

Прошу прощения, банально позабыл. Пятница была, всё же. :-) Вот куски кода: struct { uint8_t first; uint8_t second; uint8_t third; } TestStruct; const int16_t TestInteger = 9000; float TestFloat; struct { const char command; // Номер переменной const void* addr; // Указатель на переменную, приведённый к void* const char access; // Доступ к переменной (чтение/запись) const char len; // Размер переменной (в байтах), и, после '*', количество подобных переменных в массиве/структуре } const ptable[] = { //!PT_BEGIN {0x00, (void*) &TestStruct, A_R | A_W, 1 * 3}, // "TestStruct" {0x01, (void*) &TestInteger, A_R, 2}, // (signed) "TestInteger" {0xF0, (void*) &TestFloat, A_R | A_W, } // (float) "TestFloat or another text" }; Поскольку указатель на переменную кастуется к void*, то скрипту надо узнать её тип, и размер. Сейчас они явно указываются в самой структуре и комментарии, но есть вероятность ошибиться, или просто забыть обновить информацию после смены типа переменной, или размера массива. Вот я и захотел это дело автоматизировать. А поскольку лучше компилятора никто не знает, что творится в коде -- отдать эту работу ему. Ну и просто интересно стало, как же пишутся плагины на кросскомпилятор. Идея интересная, спасибо. Но в выхлопе map-файла указывается только общий размер массива/структуры. Есть ли возможность попросить у компилятора более подробную информацию о них? Размеры полей структуры, размер элемента массива.

Если не смутит ссылка на Хабр, то здесь достаточно подробно описаны внутренности чисел с плавающей точкой, и сразу станет ясно, отчего более короткие float не удастся приспособить под работу с double, которые длиннее их.

Смех смехом, но я про то, что в скрипт придётся пихать информацию о том, что uint16_t весит 16 бит, а uint8_t таки 8, т.е. делать вручную то, что компилятор уже знает. Лениво мне за компилятор работать, вот и пытаюсь оценить, что обойдётся "меньшей кровью" -- писать плагин к компилятору, или писать кусок компилятора. OK, в понедельник зашлю куски кода.

float и double, если я не ошибаюсь, могут иметь одинаковый размер, а могут и разный. По крайней мере мне вспоминается, что на AVR sizeof(float) == sizeof(double). И опять же, не хочется выносить во внешний скрипт часть парсера C-C++, хочется отдать максимум работы компилятору.

А как сам контроллер зовут? STM-овский?

Нет, этого, пожалуй, не требуется. Если очень кратко -- то структура в контроллере содержит следующие поля: номер, под которым структура значится в массиве; адрес переменной (или функции), приведённый к void*; доступ к переменной (функции) -- чтение/запись/выполнение; длина в байтах переменной (для функции неактуально). В сгенерированный файл пишется: имя переменной (или функции); идентификация поля, как переменной, или функции; номер структуры; кодовое обозначение типа данных для переменной; длина переменной в байтах. Уф... Вроде, всё. Из этого файла общалка формирует запросы к контроллеру, а тот пытается их обработать в соответствии с полями структуры.

Возможно, будете смеяться и издеваться -- но красивой идеи, как заставить именно кросс генерировать подобный файл в хостовую среду без влезания в сам процесс компиляции (что и делает плагин) у меня нет. Может, хватит флудить? Виктория, вот, убеждает меня, что тут исключительно серьёзные люди живут. Или вы тут так, проездом?

Что было в ТЗ, то и использую. Это уж не мне решать. Внезапно, наружу могут отдаваться не только целочисленные, но и с плавающей точкой. В любом случае внешнему скрипту надо будет знать, сколько байт в том же uint16_t, то есть реализовывать часть парсера C / C++. А ещё POD-структуры наружу могут отдаваться. И массивы. С ними что прикажете делать? Подозрения -- штука такая, сродни гаданию по юзерпику. Ничего особо сакрального в сборке компилятора нет, всё уже давно расписано, и готовые скрипты сборки лежат на каждом углу. Мне хочется знать, есть ли смысл во всё это ввязываться, или пусть уже по старинке, руками, прописывать размеры данных.

От кросса мне хотелось бы создание файла конфигурации по C-шной структуре. Внутри контроллера живёт некое подобие MODBUS, и общается с внешним миром. Внешняя общалка использует сгенерированный файл с описанием данных и функций. Сейчас этот файл генерируется внешним скриптом, но скрипт не может знать, сколько байт в, например, int-е контроллера. Оттого и хочется генерировать файл плагином. Ему можно явно сказать sizeof(int), и размер посчитается без участия человека. Целевая платформа -- STM32F373. Ник -- привет из прошлого. Он мне дорог, как память. :-) How to build-то я прочитать могу, и даже прочитал. Но меня интересует техническая сторона вопроса. Придётся ли пересобирать с нуля ещё и хостовый компилятор? Откуда хостовый компилятор, если им собирать плагин, узнает размеры базовых типов платформы кросса? Зачем в каталогах кросса такие подробные include для создания плагинов? Не хочется биться лбом в стену -- может, рядом есть дверь, да я её не вижу.

Доброго времени суток. Подскажите, чем и как собирать плагины к кроссу GCC? Если хостовым компилятором -- то как плагин узнает о специфичных для платформы типах (могут отличаться по размерам, например, int-ы у хоста и кросса), и не придётся ли собирать по новой как хостовый компилятор, так и кросс (subj собран под линуксом тамошним MinGW, а я сейчас на виндовсе). Если самим кроссом (на что намекают файлы в каталоге /lib/gcc/arm-none-eabi/4.7.4/plugin/include), то как кодогенератор под ARM будет кодогенерировать под самого себя, исполняющегося на x86?

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

Печально. Так хорошо всё в теории получалось с DMA, и так отвратно на практике. А вообще ST за такую реализацию I2C пинают? Хоть какие подвижки происходят?

Например, только для F3xx отдельно искать надо.

Всё же, хотелось бы услышать непосредственно от автора, какую задачу он решает. Может, действительно её возможно реализовать заметно проще.

Я правильно понял, что для определения, единица на входе, или ноль, используется АЦП? Если да, то это уж очень явный overengineering. Не проще ли инициализировать ноги, как входы, с подтяжкой к земле встроенными резисторами (PullDown), и считывать уже их состояние?

Пробовал -- оно вообще отказалось взлетать. Собственно, отчего я и полез вручную всё это раскручивать. А какие проблемы с CPAL-ом были?