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++

Добрый день. Ситуация следующая: есть данные ~ 20 байт. Им необходимо поставить в соответствие некоторый хеш-код. Естественно хочется чтобы он был как можно меньше. Какие есть формулы расчета, чтобы найти компромисс между размером хеша и вероятностью коллизий? Ну и если из опыта что-то подскажете (какой хеш использовали и для каких данных) тоже буду благодарен. P.S. полагаю CRC32 использовать для такого - слишком избыточно :)

Действительно, улетал в никуда при вызове 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), неужели тоже придется каждый раз прыгать за пределы бутлодера?

Здравствуйте. Использую 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 обстоит? надеюсь атмелы исправили ошибки.

Я во 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 большой скорости не получить: либо серьезно править стек, либо использовать UDP и прикручивать что-то сверху него. Сейчас разбираюсь с lwIP, посмотрим на что он способен.

Периодически на форуме появляются вопросы по этому стеку, их немного, поэтому просто предлагаю свалить все в кучу, возможно потом сделать FAQ. У меня возникла задача закачать на устройство несколько метров данных за возможно более короткое время. На ARM7 под FreeRTOS скорость получилась ~ 1.6 МБайта/сек ~ 10МБит. Но это после того как в системе оставил только одну задачу под стек и Main Loop стека сделал без задержек. На мой взгляд препятствием к дальнейшему увеличению скорости является отсутствие так называемого алгоритма Delayed Acknowledgement, когда ACK отправляется через один пакет, по крайней мере такое я наблюдал в винде при перекачке больших файлов. Соответственно вопрос: какую скорость обмена данными можно выжать из этого стека и как этого достичь?

У меня тоже появился вопрос для знатоков uIP, сам недавно начал возиться с этим стеком. Баг заключается в том, что когда по истечению таймера выставляется UIP_POLL для приложения и оно формируетт пакет для отправки (uip_send), то в сниффере я этого пакета не вижу. Баг возникает очень редко, долгим дебагом я установил, что функция uip_arp_out() не может в ARP таблице найти MAC, поэтому не отсылает MAC заголовок, в результате следующая за ней lEMACSend() не отправляет сам пакет. У кого нибудь есть объяснение причины происходящего? void uip_arp_out(void) { struct arp_entry *tabptr; /* Find the destination IP address in the ARP table and construct the Ethernet header. If the destination IP addres isn't on the local network, we use the default router's IP address instead. If not ARP table entry is found, we overwrite the original IP packet with an ARP request for the IP address. */ /* Check if the destination address is on the local network. */ if((IPBUF->destipaddr[0] & uip_arp_netmask[0]) != (uip_hostaddr[0] & uip_arp_netmask[0]) || (IPBUF->destipaddr[1] & uip_arp_netmask[1]) != (uip_hostaddr[1] & uip_arp_netmask[1])) { /* Destination address was not on the local network, so we need to use the default router's IP address instead of the destination address when determining the MAC address. */ ipaddr[0] = uip_arp_draddr[0]; ipaddr[1] = uip_arp_draddr[1]; } else { /* Else, we use the destination IP address. */ ipaddr[0] = IPBUF->destipaddr[0]; ipaddr[1] = IPBUF->destipaddr[1]; } for(i = 0; i < UIP_ARPTAB_SIZE; ++i) { tabptr = &arp_table[i]; if(ipaddr[0] == tabptr->ipaddr[0] && ipaddr[1] == tabptr->ipaddr[1]) break; } if(i == UIP_ARPTAB_SIZE) { /* The destination address was not in our ARP table, so we overwrite the IP packet with an ARP request. */ memset(BUF->ethhdr.dest.addr, 0xff, 6); memset(BUF->dhwaddr.addr, 0x00, 6); memcpy(BUF->ethhdr.src.addr, uip_ethaddr.addr, 6); memcpy(BUF->shwaddr.addr, uip_ethaddr.addr, 6); BUF->dipaddr[0] = ipaddr[0]; BUF->dipaddr[1] = ipaddr[1]; BUF->sipaddr[0] = uip_hostaddr[0]; BUF->sipaddr[1] = uip_hostaddr[1]; BUF->opcode = HTONS(ARP_REQUEST); /* ARP request. */ BUF->hwtype = HTONS(ARP_HWTYPE_ETH); BUF->protocol = HTONS(UIP_ETHTYPE_IP); BUF->hwlen = 6; BUF->protolen = 4; BUF->ethhdr.type = HTONS(UIP_ETHTYPE_ARP); uip_appdata = &uip_buf[40 + UIP_LLH_LEN]; uip_len = sizeof(struct arp_hdr); return; } /* Build an ethernet header. */ memcpy(IPBUF->ethhdr.dest.addr, tabptr->ethaddr.addr, 6); memcpy(IPBUF->ethhdr.src.addr, uip_ethaddr.addr, 6); IPBUF->ethhdr.type = HTONS(UIP_ETHTYPE_IP); uip_len += sizeof(struct uip_eth_hdr); // все нормально - отправляем MAC }

Запрос от браузера, как я понимаю устанавливает TCP соединение, затем выполняет собственно HTTP запросы, в том числе и на получение страницы, и прочих файлов, после чего соединение закрывается. Если при установленном TCP соединении от клиента (браузера) перестают приходить пакеты, то через некоторый небольшой таймаут сервер сам рвет соединении. О том чтобы HTTP сервер сам коннектился к клиенту и впаривал ему страницу я не знаю. Вообще для FreeRTOS есть куча экзамплов с uIP и HTTP сервером, по крайней мере для ARM7.

aaarrr, действительно, проблема оказалась в неправильном ucPHYAddress. Я тупо начал перебирать их с 0 до 31, на адресе 16 EMAC завелся :yeah:

Столкнулся с проблемой в sam7_emac.c (проект IAR), юзаю интерфейс MII, в инициализации при чтении из PHY (vReadPHY) все время читается 0xFFFF здесь ... #if USE_RMII_INTERFACE != 1 { unsigned portLONG ulControl; /* PHY has internal pull down : disable MII isolate. */ vReadPHY( AT91C_PHY_ADDR, MII_BMCR, &ulControl ); vReadPHY( AT91C_PHY_ADDR, MII_BMCR, &ulControl ); ulControl &= ~BMCR_ISOLATE; vWritePHY( AT91C_PHY_ADDR, MII_BMCR, ulControl ); } №endif ... и здесь static portBASE_TYPE prvProbePHY( void ) { unsigned portLONG ulPHYId1=0, ulPHYId2=0, ulStatus; portBASE_TYPE xReturn = pdPASS; unsigned portCHAR ucAddr1 = MII_PHYSID1, ucAddr2 = MII_PHYSID2; /* Code supplied by Atmel (reformatted) -----------------*/ /* Enable management port */ AT91C_BASE_EMAC->EMAC_NCR |= AT91C_EMAC_MPE; AT91C_BASE_EMAC->EMAC_NCFGR |= ( 2 ) << 10; /* Read the PHY ID. */ vReadPHY( AT91C_PHY_ADDR, ucAddr1, &ulPHYId1 ); vReadPHY( AT91C_PHY_ADDR, ucAddr2, &ulPHYId2 ); /*MII_DM9161_ID: PHY_ID1 = 0x0181 PHY_ID2 = 0xb8a0 */ if( ( ( ulPHYId1 << 16 ) | ( ulPHYId2 & 0xfff0 ) ) != MII_DM9161_ID ) { /* Did not expect this ID. */ xReturn = pdFAIL; } else { ulStatus = xGetLinkSpeed(); if( ulStatus != pdPASS ) { xReturn = pdFAIL; } } /* Disable management port */ AT91C_BASE_EMAC->EMAC_NCR &= ~AT91C_EMAC_MPE; return xReturn; } чтение из PHY: static void vReadPHY( unsigned portCHAR ucPHYAddress, unsigned portCHAR ucAddress, unsigned portLONG *pulValue ) { /* Code supplied by Atmel (reformatted) ----------------------*/ AT91C_BASE_EMAC->EMAC_MAN = (AT91C_EMAC_SOF & (0x01<<30)) | (2 << 16) | (2 << 28) | ((ucPHYAddress & 0x1f) << 23) | ((ucAddress & 0x1f) << 18); /* Wait until IDLE bit in Network Status register is cleared. */ while( !( AT91C_BASE_EMAC->EMAC_NSR & AT91C_EMAC_IDLE ) ) { __asm( "NOP" ); } *pulValue = ( AT91C_BASE_EMAC->EMAC_MAN & 0x0000ffff ); } В гугле нашел кое-чего про подобную проблему http://www.utasker.com/forum/index.php?topic=161.0 , но как-то яснее не стало

Плата AT91SAM7-P64 от OLIMEX, хочу прицепить оптрон на ножку PA3. Никак не получается воспользоваться примерами от aaarrr: __irq void pio_interrupt( void ) { AT91C_BASE_SYS->PIOA_ISR; AT91C_BASE_SYS->AIC_EOICR = 0; } 1й вариант int main( void ) { AT91C_BASE_RSTC->RSTC_RMR = AT91C_RSTC_URSTEN | (0x4<<8) | (unsigned int)(0xA5<<24); AT91F_PMC_EnablePeriphClock ( AT91C_BASE_PMC, 1 << AT91C_ID_PIOA ); AT91C_BASE_SYS->PIOA_ODR = AT91C_PIO_PA3; AT91C_BASE_SYS->PIOA_IFER = AT91C_PIO_PA3; AT91C_BASE_SYS->PIOA_PER = AT91C_PIO_PA3; AT91C_BASE_SYS->PIOA_IDR = 0xffffffff; AT91C_BASE_SYS->PIOA_IER = AT91C_PIO_PA3; AT91C_BASE_AIC->AIC_SVR[AT91C_ID_PIOA] = (unsigned int)pio_interrupt; AT91C_BASE_AIC->AIC_SMR[AT91C_ID_PIOA] = 0; AT91C_BASE_AIC->AIC_IECR = (0x01 << AT91C_ID_PIOA); AT91C_BASE_PMC->PMC_PCER = (0x01 << AT91C_ID_PIOA); for (;;) { delay(); } } 2й вариант int main( void ) { AT91C_BASE_RSTC->RSTC_RMR = AT91C_RSTC_URSTEN | (0x4<<8) | (unsigned int)(0xA5<<24); AT91F_PMC_EnablePeriphClock ( AT91C_BASE_PMC, 1 << AT91C_ID_PIOA ); AT91C_BASE_SYS->PIOA_ODR = AT91C_PIO_PA3; AT91C_BASE_SYS->PIOA_PPUDR = AT91C_PIO_PA3; AT91C_BASE_SYS->PIOA_IFER = AT91C_PIO_PA3; AT91C_BASE_SYS->PIOA_PER = AT91C_PIO_PA3; AT91C_BASE_PMC->PMC_PCER = (1UL << AT91C_ID_PIOA); AT91C_BASE_SYS->PIOA_IDR = ~0; AT91C_BASE_SYS->PIOA_IER = AT91C_PIO_PA3; AT91C_BASE_AIC->AIC_SMR[AT91C_ID_PIOA] = 0; AT91C_BASE_AIC->AIC_SVR[AT91C_ID_PIOA] = (unsigned int)pio_interrupt; AT91C_BASE_AIC->AIC_IECR = (1UL << AT91C_ID_PIOA); for (;;) { delay(); } } в прерывание не входит, постоянно крутится в delay().

Не поделится ли кто-нибудь IAR проектом с FreeRTOS на LPC2103 ?

Помогите начинающему! Решил начать работь с FreeRTOS на IAR 5, в наличии имеется AT91SAM7X-EK Скачал со страницы http://sam7-ex256.narod.ru/ пример http://sam7-ex256.narod.ru/SAM7_EX256_FreeRTOSV4.0.zip, к сожалению для 4го IAR. После открытия и конвертации проекта в 5ю версию возникают проблемы с Cstartup.s79, почти все строчки - bad instruction. В чем может быть проблема и как решается?

Мне надо поддерживать стабильность температуры регулируя положение клапана. Для этих целей я применил ПИ регулирование (пропорциональную и интегральную составляющие). Однако стабильности не получилось вследствии того, что я не могу получить точную информацию о положении клапана (определяется с ошибкой ~ 10%). Добавил дифференциальную составляющую, но делу не помогло. Вопрос: можно ли одним ПИД регулированием стабилизировать параметр, если в обратной связи ошибка? Если нет, то какие методы будут работать в такой ситуации? Эх, не туда запостил, в математику надо бы

У меня есть девайсина c RS-232(не модем, но очень похожа), общение с которой происходит "по протоколу v42 через интерфейс v24" - так указано в описании. Мне с ней надо наладить общение из под винды. С v42 всё понятно - программно реализовать можно - клади себе данные в COM порт. А вот что такое v24? Там написано, что вначале он устанавливает какое-то ошибкокорректирующее соединение, передаёт последовательности бит вроде 0 10001000 1 11111111 0 10001001 1 - очень неприятно будет с таким иметь дело. Вопрос - нужно ли мне заморачиваться по этому поводу - или v24 - это забота драйвера COM порта?