swampman
Участник-
Постов
26 -
Зарегистрирован
-
Посещение
Репутация
0 ОбычныйИнформация о swampman
-
Звание
Участник
-
В проекте для at91sam7x на версии IAR 5.5 расположение стеков в RAM задавалось вручную в ICF-файле: place in RAM_region { readwrite, block CSTACK, block SVC_STACK, block IRQ_STACK, block FIQ_STACK, block UND_STACK, block ABT_STACK, block HEAP, block SYS_STACK }; соответственно в MAP-файле я видел: "P4", part 1 of 3: 0x1510 CSTACK 0x00200000 0x1000 <Block> CSTACK uninit 0x00200000 0x1000 <Block tail> .iar.dynexit 0x00201000 0x210 <Block> .iar.dynexit uninit 0x00201000 0xc cppinit.o [3] .iar.dynexit uninit 0x0020100c 0x204 <Block tail> SVC_STACK 0x00201210 0x200 <Block> SVC_STACK uninit 0x00201210 0x200 <Block tail> IRQ_STACK 0x00201410 0x100 <Block> IRQ_STACK uninit 0x00201410 0x100 <Block tail> FIQ_STACK 0x00201510 0x0 <Block> UND_STACK 0x00201510 0x0 <Block> ABT_STACK 0x00201510 0x0 <Block> HEAP 0x00201510 0x0 <Block> - 0x00201510 0x1510 После переноса проекта на версию IAR 6.5 линкер правильно читает все что касается ROM, но все стеки пихает в конец "P4", part 3 of 3: 0x1300 CSTACK 0x002138b0 0x1000 <Block> CSTACK uninit 0x002138b0 0x1000 <Block tail> SVC_STACK 0x002148b0 0x200 <Block> SVC_STACK uninit 0x002148b0 0x200 <Block tail> IRQ_STACK 0x00214ab0 0x100 <Block> IRQ_STACK uninit 0x00214ab0 0x100 <Block tail> FIQ_STACK 0x00214bb0 0x0 <Block> UND_STACK 0x00214bb0 0x0 <Block> ABT_STACK 0x00214bb0 0x0 <Block> HEAP 0x00214bb0 0x0 <Block> - 0x00214bb0 0x1300 Как это лечить? P.S. в проекте некоторые файлы компилируются C++
-
Хеш-функция для БД
swampman опубликовал тема в Математика и Физика
Добрый день. Ситуация следующая: есть данные ~ 20 байт. Им необходимо поставить в соответствие некоторый хеш-код. Естественно хочется чтобы он был как можно меньше. Какие есть формулы расчета, чтобы найти компромисс между размером хеша и вероятностью коллизий? Ну и если из опыта что-то подскажете (какой хеш использовали и для каких данных) тоже буду благодарен. P.S. полагаю CRC32 использовать для такого - слишком избыточно :) -
BootLoader для FreeRTOS
swampman ответил swampman тема в ARM, 32bit
Действительно, улетал в никуда при вызове asm( "SWI 0" ). Правильно ли я понимаю, что при возникновении SWI процессор принудительно переходит на абсолютный адрес 0x8, вне зависимости от того, было ли в icf файле смещение DROMSTART или нет? Теперь пробую лечить это по первому варианту. В основной программе при переходе на вектор по адресу 0x08, в PC загружался адрес обработчика из ячейки со смещением +24. Соответственно в бутлодере пытаюсь прыгнуть на 0x2000 вперед (в сумме получается 8192+24 = 8216), написал для SWI: SWI_Handler_Entry: ldr pc , [pc, #+8216] после этого не компилится бутлодер, т.к выходит за пределы DROMEND А как обстоят дела с другими обработчиками (Reset, IRQ, FIQ), неужели тоже придется каждый раз прыгать за пределы бутлодера? -
BootLoader для FreeRTOS
swampman опубликовал тема в ARM, 32bit
Здравствуйте. Использую FreeRTOS v6.0.4, проект uIP_Demo, среда IAR. При обычных настройках icf файла проект само собой работает. Бутлодер располагается в начале флешки, основная программа (на базе FreeRTOS) - со смещением 0x2000. В файле at91SAM7X256_FLASH.icf меняю: define symbol __ICFEDIT_intvec_start__ = 0x00100000; define symbol __ICFEDIT_region_ROM_start__ = 0x00100040; на define symbol __ICFEDIT_intvec_start__ = 0x00102000; define symbol __ICFEDIT_region_ROM_start__ = 0x00102040; после запуска шедуллера программа сваливается. Подозреваю что нужно подправить Cstartup.s, помогите разобраться где подправить. Заранее благодарен. -
Благодарю за ответы. В третьем варианте есть опасность, что однажды при старте проца бутлодер может не обнаружить в носителе валидного FirmWare, и тогда придется физически добираться до платы. Но конечно подкупает своей простотой, в общем пока размышляю.
-
Здравствуйте. Собственно необходимо реализовать обновление основной программы по Ethernet для проца at91sam7x. Порывшись в форуме я нашел следующие варианты: 1) В основной программе обновление происходит через ramfunc, но меня несколько смущает необходимость реализовывать TCP/IP стек в ramfunc. 2) BootLoader располагается в начале флэш-памяти и проц всегда стартует с него, основная программа располагается также во флэш. При обновлении FirmWare бутлодер работает с Ethernet и переписывает основную программу и после верификации передает управление на неё. 3) При обновлении основная программа закачивает новое FirmWare во внешний носитель (например DataFlash), затем выходит в бутлодер, который просто переписывает FirmWare из внешнего носителя во внутреннюю флэш. Какой из вариантов является наиболее приемлемым, или предложите свой. Заранее благодарен.
-
Проблема решилась правкой MAC файла. На sam9xe-ek стоит две SDRAM с 16 разрядной шиной, соответственно Data Bus Width устанавливается в 32 бита, а на моей плате SDRAM одна, поэтому надо ставить 16 бит.
-
Флэш проект тоже не прошивался, по причине того, что лоадер не мог загрузиться в SDRAM, перекомпилил его на SRAM (спасибо Alex Kuznetsov за совет) теперь нормально. С помощью SAM-BA заливаю файл в SDRAM, сравнение не проходит, в Memory Displey показывает, что старшие байты слов FF. Удивительно, что Линух, поставленный вместе с платой грузился нормально (из DataFlash я полагаю), попробую залить его обратно, посмотрим, как сейчас заработает.
-
плата от starterkit, проц sam9xe. Беру экзампл для кита sam9xe-ek, как наиболее близкий, SRAM проект загружается исполняется/нормально, при загрузке SDRAM проекта возникают варнинги: Verify error at address 0x20000002, target byte: 0xFF, byte in file: 0x9F и.т.п при старте в стартапе: LDR pc, =label улетает в адрес 0x302dec, где и висит каковы могут быть причины всего и возможные пути решения? я предполагаю пока, что загрузка в SDRAM не проходит?
-
А в SAM9 которые ARM926 - там как дело с TWI обстоит? надеюсь атмелы исправили ошибки.
-
Разбиение задачи на процессы
swampman ответил Harvester тема в Операционные системы
Я во FreeRTOS делал отдельно поток для Ethernet (uIP), для UART, и один поток для PIO - светодиоды, зуммер. При проектировании я считаю надо вначале на бумаге выделить модули программы, если между ними возможно синхронное взаимодействие - то в один процесс, если проще асинхронное - тогда в разные. -
Еще вопрос по целостности данных в случае SDRAM + FLASH: проверять их порчу в RAM я полагаю не имеет смысла, а во FLASH можно ли самому организовать простейший механизм проверки типа CRC32, или же лучше прикручивать FS ?
-
Ок, спасибо. А такого зверя как SDRAM на SPI я полагаю в природе не существует?
-
Здравствуйте, опытных разработчиков прошу дать совет. Имеется устройство на Atmel (SAM7X 256), требуется на нем держать информацию объемом ~ 1 Мбайт (локальная БД), которая изменяется достаточно часто ( несколько раз в минуту). При этом при перезагрузке данные должны сохраняться. Навскидку есть 2 решения: 1) использовать для БД микросхемы FRAM(64 Кбайта), на которых уже работают наши девайсы, но тогда придется ставить их штук 15, что не есть хорошо. 2) использовать SDRAM, и при выключении питания бэкапить во FLASH, но у этого ARMа нет EBI по которому работает SDRAM. Ethernet + EBI есть у каких то камней от NPX, либо у ARM9, но переходить на другой проц сейчас нет времени и ресурсов. Какие еще возможны решения?
-
Стек uIP
swampman ответил swampman тема в Операционные системы
В общем я прихожу к выводу, что одними средствами uIP большой скорости не получить: либо серьезно править стек, либо использовать UDP и прикручивать что-то сверху него. Сейчас разбираюсь с lwIP, посмотрим на что он способен.