esaulenka

Тут прерывание срабатывает два раза. После команды сброса флажка прерывания надо что-то типа __DSB(); или просто несколько nop'ов.

Увы, у Вас ВСЁ неправильно. Для начала надо б понять, на какие адреса приходится эта внешняя память. В том, что выложено, она волшебным образом накладывается на SRAM,SFR,... - в реальной жизни так не бывает. Также у этих C166 есть различные режимы адресации. Почитайте обязательно про регистры DPP0..DPP3. И сами данные - оно программатором прямо с флешки считано, или какой-то утилитой? Утилиты для чтения ECU, на мой дилетантский взгляд, могут отдельно выдавать область с настройками, и отдельно - с кодом (хотя "в железе" всё это хранится рядом). Так что вместо FF'ов в реальности могут быть данные. И про IDA почитать стоит. Она не особо умная, много чего надо делать руками (или скриптами).

Безнадёжно. FLASH_Status FLASH_ProgramWord (uint32_t Address, uint32_t Data) Programs a word (32-bit) at a specified address. Тридцать два. ТРИД-ЦАТЬ ДВА. Не шестнадцать.

amaora, Вы их где берёте? Вроде б на launchpad'е всё тихо и спокойно (а 7-й версии нет совсем).

Это получается, что для совместимости (с чем, я никогда не задумывался) команды 0x1B 0x2D 0x01 и 0x1B 0x2D 0x31 абсолютно идентичны. Там много таких.

Краткий исторический экскурс. Есть спецификация от Epson на ESC-команды (внучка спецификации на матричные принтеры из прошлого века). Там базовый набор - промотать бумагу, установить выравнивание влево-вправо, подчёркивание-италик и т.д. Большинство вендоров этот набор поддерживает, плюс имеет свой собственный набор команд работы с графикой, мильёном разных штрих-кодов и проч. Стандартной команды "выбрать кодовую страницу" не существует; более того, возможно, в Вашем случае не существует и самой 1251-й страницы, а можно пользоваться только user-defined шрифтами, которые надо отдельно загрузить в eeprom. Команды загрузки шрифтов у каждого бренда (да что уж там, у каждой линейки) будут свои, ни с чем не совместимые. Сниффить родной драйвер можно, но с большой вероятностью он переводит принтер в графический режим и дальше гонит туда растеризованную картинку. Писишному программисту так удобнее :)

Вот так оно работает: static void StartMain (const void * aAddr) { void (*code_entry)(void); struct StartVector { uint32_t stack_ptr; // stack pointer uint32_t entry_ptr; // code entry pointer }; StartVector *start = (StartVector*) aAddr; // set interrupt vectors SCB->VTOR = (uint32_t)aAddr; // get code entry code_entry = (void (*)(void)) start->entry_ptr; // set stack pointer __set_PSP (start->stack_ptr); // start application code_entry (); }

Гугл-то вы используете? По словам "gcc typeof" можно найти исчерпывающее описание. Примеры по первой же ссылке: #define pointer(T) typeof(T *) #define array(T, N) typeof(T [N]) ((typeof(x))-1) означает "привести минус единицу к типу исходного аргумента". Там они дальше проверяют, положительное это число (что, очевидно, будет если икс - беззнаковый тип), или отрицательное (для знакового икса). Более того, можно вбить в гугл слово "DIV_ROUND_CLOSEST". Также по ПЕРВОЙ же ссылке есть исходный заголовок, в котором есть подробный комментарий. /* * Divide positive or negative dividend by positive or negative divisor * and round to closest integer. Result is undefined for negative * divisors if he dividend variable type is unsigned and for negative * dividends if the divisor variable type is unsigned. */ #define DIV_ROUND_CLOSEST(x, divisor)( \ { \ typeof(x) __x = x; \ typeof(divisor) __d = divisor; \ (((typeof(x))-1) > 0 || \ ((typeof(divisor))-1) > 0 || \ (((__x) > 0) == ((__d) > 0))) ? \ (((__x) + ((__d) / 2)) / (__d)) : \ (((__x) - ((__d) / 2)) / (__d)); \ } \ ) Зачем что-то изобретать на ровном месте, если есть документация?!

Кто-нибудь занимался дизассемблированием бинарника для контроллера, у которого память представлена несколькими банками? В частности, у архитектуры C166 есть несколько режимов адресации. Вариант "в один регистр записывается номер data page, а в другой - 14-битное смещение внутри этой page" я в уме считаю с трудом. Как-то можно сказать "вот эта константа должна лежать в такой-то странице, сгенери для неё ссылки"? Вариант "номер data page берётся из DPPx" тоже почему-то работает криво. Вроде б в эти регистры пишутся один раз, при инициализации (точнее, два раза - при инициализации загрузчика, а потом при инициализации ядра), но половина переменных "промахивается" мимо SRAM... Все статьи - про x86, 16-битный режим там лет 20 не в чести :-) PS Пытаюсь сопрячь нашу железку с чужой. Документации нет и не будет (они большие, а мы маленькие...), метод разглядывания обмена особо не помогает...

Только предварительно он эту осциллограмму сохранит в своей внутренней памяти. А памяти этой там кот наплакал... PS блин, люди, вы считать умеете? Обычная ширпотребная флешка - это запись десяти мегабайт в секунду (с периодическими затыками, но умолчим пока). Приличная - 15..20. Пара 8-битных каналов с частотой семплирования аж в 50 мегагерц дают поток в сотню мегабайт. Ну какая тут нафиг флешка?!

В теме слово lwIP, в сообщениях вывод статистики по lwIP, в ответе - FreeRTOSconfig.h Forger, Вы вопрос-то читали? Возвращаясь к нашим утечкам. Во-первых, мы про какую версию разговариваем? Глянул последнюю, 2.0.2 - там счётчики занятых-свободных объектов - mem_size_t, который тот же size_t, т.е. на ARM'ах явно 32-битный. Гипотеза "счётчик буфера входящих пакетов в один прекрасный момент стал меньше нуля" работает только на 16-битных счётчиках. Во-вторых, во всё той же версии есть опция проверки утечек памяти - место, которое должно быть свободным, заполняется паттерном, при выделении памяти этот паттерн проверяется. Тормозить будет, конечно, но так только баг быстрее вылезет :-)

Что-то не понял, почему нельзя возвращать указатель на константу? Тогда оно "само" приведётся к неконстанте, если потребуется. char const *StrFunc(char const *str) { return str + 5; } int main(void) { const char str1[] = "Hello, world!\n"; char str2[] = "Hello, world!\n"; const char *res1 = StrFunc (str1); char *res2 = StrFunc (str2); printf(res1); printf(res2); return 0; } UPDATE. Чёрт, опять часть варнингов потерялась... warning: initialization discards ‘const’ qualifier from pointer target type [-Wdiscarded-qualifiers] char *res2 = StrFunc (str2); Да-а, беда. Плюсы с перезагрузкой ждут Вас :-)

А я тут как-то атмегу вспоминал. Интерфейс программирования атмеги похож на миландровский примерно так же, как и STM'овский - никак. А в данном случае надо определиться с терминологией, слегка почитать документацию и чуть-чуть погуглить. Загрузчик, или bootloader - программа, стартующая при запуске процессора. В нормальном режиме просто запускает основную программу, в режиме обновления получает откуда-то извне и перезаписывает основную программу. А тут нужно просто написать свои функции стирания и записи страницы флеши (последовательность действий расписана в документации), поместить их в ОЗУ (да, присвоив им нужные атрибуты и отредактировав скаттер; дальше кейл всё сделает сам). Ну и саму структуру с настройками надо придумать. И методику предусмотреть на случай "мы включились, а в прошлый раз вместо настроек какой-то мусор записался". И ещё можно вот сюда подсматривать: http://forum.milandr.ru/viewtopic.php?f=34...tart=300#p11419

MEM TCPIP_MSG_INPKT avail: 8 used: 65530 max: 65535 Ага, много-много прерываний :-)

Существует масса поделий, у которых данные пишутся во внутреннюю память, а только потом перекидываются на компьютер. Они собрали все недостатки - и малый объем памяти, как у настольных моделей, и неавтономность с неудобным управлением, как у USB-приставок. Лично общался с подобным осциллографом от Velleman (дальнего его потомка недавно видел в чип-дипе) и анализатором АКИП. Рекомендовать подобное, разумеется, не буду.

Поставил последнюю версию студии. Драйвер подхватился, студия адаптер показала. Нажатие кнопки connect - ошибка. Полистал советы, утилитой zadig подменил драйвер на libusb-win32. Студия успешно читает-пишет. Возможно, какой-то из шагов лишний (например, если поставить, а потом снести 4-ю студию, драйвера в системе остаются, надо руками чистить); проверять установку 7-й студии на чистую винду лень. Тем не менее, всё готово, требуемый результат получен.

Господа, подскажите, что нужно, чтобы считать-записать готовую прошивку. В наличии AVR ISP mk2 (оригинал), Win10 x64. Поставил по старой памяти AVR Studio 4.19, но там какая-то беда с драйверами (подписи нет, что-ли... винда говорит, что ничего подходящего для устройства не нашлось). Гугл советует миллион различных танцев вокруг клонов этого ISPmk2 (но мне оно не надо, кажется).

Можно просто в scmRTOS_TARGET.h добавить extern "C" { extern stack_item_t* os_context_switch_hook(stack_item_t* sp) __attribute__((used)); extern void __init_system_timer() __attribute__((used)); };

Тем не менее, боевой проект собрался компилятором 5.4 2016q3 (windows, скачан с arm.com) с галкой LTE и успешно работает. 6-я версия тоже работает, но требует некрасивых танцев вокруг шаблонов. Да, ещё и на аналогичные грабли с таблицей векторов наступил. PS что хорошо, размер бинарника уменьшился килобайт на 5. С учётом того, что свободного места у нас осталось впритык, идея LTO требует всяческого развития.

Прошу прощения за пятничный сумбур, очень уж домой хотелось :-) Building file: ../Drivers/AccelDrv.cpp Invoking: Cross ARM C++ Compiler arm-none-eabi-g++ -mcpu=cortex-m3 -mthumb -Os -fmessage-length=0 -fsigned-char -ffunction-sections -fdata-sections -flto -Wuninitialized -g -DSTM32F105xC -DSTM32F10X_CL -I /skipped/ -std=gnu++11 -fabi-version=0 -fno-exceptions -fno-rtti -MMD -MP -MF"Drivers/AccelDrv.d" -MT"Drivers/AccelDrv.o" -c -o "Drivers/AccelDrv.o" "../Drivers/AccelDrv.cpp" In file included from ../Drivers/AccelDrv.cpp:8:0: ../Drivers/AccelDrv.h:39:30: error: reinterpret_cast from integer to pointer static PeriphBit<(uintptr_t)&EXTI->IMR, EXTI_IMR_MR1> ExtiUnmaskIRQ; ^~~~~~~~~~ ../Drivers/AccelDrv.h:39:54: note: in template argument for type 'unsigned int' static PeriphBit<(uintptr_t)&EXTI->IMR, EXTI_IMR_MR1> ExtiUnmaskIRQ; Версия стандарта не влияет. Уровень оптимизации (проверял -Os и -Og) не влияет. Ещё более корявое решение static PeriphBit<EXTI_BASE + offsetof(EXTI_TypeDef, IMR), EXTI_IMR_MR1> ExtiUnmaskIRQ; работает.

Балуюсь свежим gcc с link time optimization. В двух проектах он как-то хитро оптимизировал os_context_switch_hook() и __init_system_timer() - почему-то решил, что символ не определён. Причём в одном выкинул одну функцию, в другом - другую. Помогло приписывание этим функциям атрибута used. Сейчас попробовал тестовый пример - там выкинуло обе :-) Invoking: Cross ARM GNU C++ Linker arm-none-eabi-g++ -mcpu=cortex-m3 -mthumb -Os -fmessage-length=0 -fsigned-char -ffunction-sections -fdata-sections -ffreestanding -flto -Wunused -Wuninitialized -Wall -Wextra -Wmissing-declarations -Wconversion -Wpointer-arith -Wpadded -Wshadow -Wlogical-op -Waggregate-return -Wfloat-equal -g -T mem.ld -T libs.ld -T sections.ld -nostartfiles -Xlinker --gc-sections -L"../ldscripts" -Wl,-Map,"scmRTOS.map" --specs=nano.specs -o "scmRTOS.elf" ./src/src/_cxx.o ./src/src/_exit.o ./src/src/_sbrk.o ./src/src/_syscalls.o ./src/src/assert.o ./src/_write.o ./src/main.o ./src/os_kernel.o ./src/os_services.o ./src/os_target.o ./src/recursive_mutex.o ./src/startup.o ./src/sysinit.o ./src/usrlib.o C:\Users\ESAULE~1\AppData\Local\Temp\ccEIkvE6.ltrans0.ltrans.o: In function `PendSV_Handler': <artificial>:(.text.PendSV_Handler+0x1c): undefined reference to `os_context_switch_hook' C:\Users\ESAULE~1\AppData\Local\Temp\ccEIkvE6.ltrans0.ltrans.o: In function `Reset_Handler': <artificial>:(.text.Reset_Handler+0x190): undefined reference to `__init_system_timer'

Спасибо большое!! Проверил на 5-м gcc (5.4 2016q3 от ARM.com). Он ест оба варианта, содержимое бинарника идентичное. 6-му gcc этот вариант тоже подходит. У меня не получилось, ругается невнятными словами. Ну да ладно. Следующий вопрос, если Вы не против. Ещё у меня есть конструкция static PeriphBit<(uintptr_t)&EXTI->IMR, EXTI_IMR_MR1> ExtiUnmaskIRQ; Откуда я её взял (слегка доработав), думаю, Вы узнаете :) // возвращает номер старшего бита constexpr int8_t mask2bit (uint32_t val) { return (val > 1) ? ( mask2bit (val/2) + 1 ) : 0; } enum { pPERIPH_BASE = 0x40000000UL, // Peripheral base address pPERIPH_BB_BASE = 0x42000000UL, // Peripheral base address in the bit-band region pSRAM1_BB_BASE = 0x22000000UL, // SRAM1(112 KB) base address in the bit-band region pSRAM2_BB_BASE = 0x2201C000UL // SRAM2(16 KB) base address in the bit-band region }; /** * Peripheral bit - bit-band accessed bit. * @param addr peripheral address * @param bit_mask mask of requested bit. Важно! в маске должен быть только ОДИН бит! */ template <uintptr_t addr, uint32_t bit_mask> struct PeriphBit { enum { BIT = mask2bit(bit_mask) }; enum { BB_ADDR = pPERIPH_BB_BASE + (addr - pPERIPH_BASE) * 32 }; uint32_t operator=(uint32_t value) { ((volatile uint32_t*)BB_ADDR)[BIT] = (bool)value; return value; } operator uint32_t() { return ((volatile uint32_t*)BB_ADDR)[BIT]; } }; Может, тоже подскажете, как доработать?..

Здравствуйте. Возникла проблема после апгрейда gcc 4.8 на последнюю (6-ю) версию. Есть у меня класс - драйвер таймера, в котором используемый таймер описан как static constexpr TIM_TypeDef * const SYSTIMER = TIM6; где TIM6 - стандартный дефайн ((TIM_TypeDef *) TIM6_BASE). Раньше всё было хорошо, компилировалось-работало, а теперь поломалось: начиная с какой-то версии gcc подкрутили, и в полном соответствии со стандартом reinterpret_cast стал неконстантным выражением. Народ на стековерфлоу предлагает удалить constexpr. Что-то мне эта идея не нравится - мне в основном надо просто прочитать значение этого таймера, и код этот раздувается вдвое. Что б тут сделать?.. Обратно #define не хочу...

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

Конкретику можно? Т.е. "в таких-то и таких-то чипах не работают такие-то вещи". Всё никак не доходят руки заняться 2640 (проект, бедный, уже больше года с низким приоритетом висит). Примеры работают. Написано всё это как-то... с избытком абстракций, но пока ничего совсем страшного обнаружено не было...