Перейти к содержанию
    

swampman

Участник
  • Постов

    26
  • Зарегистрирован

  • Посещение

Репутация

0 Обычный

Информация о swampman

  • Звание
    Участник
    Участник
  1. Перенос проекта из 5.5 в 6.5

    В проекте для 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++
  2. Добрый день. Ситуация следующая: есть данные ~ 20 байт. Им необходимо поставить в соответствие некоторый хеш-код. Естественно хочется чтобы он был как можно меньше. Какие есть формулы расчета, чтобы найти компромисс между размером хеша и вероятностью коллизий? Ну и если из опыта что-то подскажете (какой хеш использовали и для каких данных) тоже буду благодарен. P.S. полагаю CRC32 использовать для такого - слишком избыточно :)
  3. Действительно, улетал в никуда при вызове 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), неужели тоже придется каждый раз прыгать за пределы бутлодера?
  4. BootLoader для FreeRTOS

    Здравствуйте. Использую 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, помогите разобраться где подправить. Заранее благодарен.
  5. BootLoader для sam7x

    Благодарю за ответы. В третьем варианте есть опасность, что однажды при старте проца бутлодер может не обнаружить в носителе валидного FirmWare, и тогда придется физически добираться до платы. Но конечно подкупает своей простотой, в общем пока размышляю.
  6. BootLoader для sam7x

    Здравствуйте. Собственно необходимо реализовать обновление основной программы по Ethernet для проца at91sam7x. Порывшись в форуме я нашел следующие варианты: 1) В основной программе обновление происходит через ramfunc, но меня несколько смущает необходимость реализовывать TCP/IP стек в ramfunc. 2) BootLoader располагается в начале флэш-памяти и проц всегда стартует с него, основная программа располагается также во флэш. При обновлении FirmWare бутлодер работает с Ethernet и переписывает основную программу и после верификации передает управление на неё. 3) При обновлении основная программа закачивает новое FirmWare во внешний носитель (например DataFlash), затем выходит в бутлодер, который просто переписывает FirmWare из внешнего носителя во внутреннюю флэш. Какой из вариантов является наиболее приемлемым, или предложите свой. Заранее благодарен.
  7. Verify error

    Проблема решилась правкой MAC файла. На sam9xe-ek стоит две SDRAM с 16 разрядной шиной, соответственно Data Bus Width устанавливается в 32 бита, а на моей плате SDRAM одна, поэтому надо ставить 16 бит.
  8. Verify error

    Флэш проект тоже не прошивался, по причине того, что лоадер не мог загрузиться в SDRAM, перекомпилил его на SRAM (спасибо Alex Kuznetsov за совет) теперь нормально. С помощью SAM-BA заливаю файл в SDRAM, сравнение не проходит, в Memory Displey показывает, что старшие байты слов FF. Удивительно, что Линух, поставленный вместе с платой грузился нормально (из DataFlash я полагаю), попробую залить его обратно, посмотрим, как сейчас заработает.
  9. Verify error

    плата от starterkit, проц sam9xe. Беру экзампл для кита sam9xe-ek, как наиболее близкий, SRAM проект загружается исполняется/нормально, при загрузке SDRAM проекта возникают варнинги: Verify error at address 0x20000002, target byte: 0xFF, byte in file: 0x9F и.т.п при старте в стартапе: LDR pc, =label улетает в адрес 0x302dec, где и висит каковы могут быть причины всего и возможные пути решения? я предполагаю пока, что загрузка в SDRAM не проходит?
  10. Twi в SAM7s128

    А в SAM9 которые ARM926 - там как дело с TWI обстоит? надеюсь атмелы исправили ошибки.
  11. Я во FreeRTOS делал отдельно поток для Ethernet (uIP), для UART, и один поток для PIO - светодиоды, зуммер. При проектировании я считаю надо вначале на бумаге выделить модули программы, если между ними возможно синхронное взаимодействие - то в один процесс, если проще асинхронное - тогда в разные.
  12. Еще вопрос по целостности данных в случае SDRAM + FLASH: проверять их порчу в RAM я полагаю не имеет смысла, а во FLASH можно ли самому организовать простейший механизм проверки типа CRC32, или же лучше прикручивать FS ?
  13. Ок, спасибо. А такого зверя как SDRAM на SPI я полагаю в природе не существует?
  14. Здравствуйте, опытных разработчиков прошу дать совет. Имеется устройство на Atmel (SAM7X 256), требуется на нем держать информацию объемом ~ 1 Мбайт (локальная БД), которая изменяется достаточно часто ( несколько раз в минуту). При этом при перезагрузке данные должны сохраняться. Навскидку есть 2 решения: 1) использовать для БД микросхемы FRAM(64 Кбайта), на которых уже работают наши девайсы, но тогда придется ставить их штук 15, что не есть хорошо. 2) использовать SDRAM, и при выключении питания бэкапить во FLASH, но у этого ARMа нет EBI по которому работает SDRAM. Ethernet + EBI есть у каких то камней от NPX, либо у ARM9, но переходить на другой проц сейчас нет времени и ресурсов. Какие еще возможны решения?
  15. В общем я прихожу к выводу, что одними средствами uIP большой скорости не получить: либо серьезно править стек, либо использовать UDP и прикручивать что-то сверху него. Сейчас разбираюсь с lwIP, посмотрим на что он способен.
×
×
  • Создать...