sergforce

Скажите, пожалуйста, а кто-то подключал CY7C68001 к AT91RM9100? (изначально идея такая http://electronix.ru/forum/index.php?showtopic=16589) Никто не подключал САБЖ к микроконтроллеру как внешнюю SRAM, никаких граблей при этом не было?

Есть предложени по добавлению узлов. =))) Может кому-то кроме меня интересно USB 2.0 HiSpeed (http://electronix.ru/forum/index.php?showtopic=16589 ) Собственно, предложение развести на отладочной плате, в следущей её ревизии, Cypress CY7C68001 ..

Я WinAVR использую года 2 и за это время сложилось достаточно положительное впечатление, но не без причуд. Похоже на уровне оптимизации WinAVR "не знает" что регистры 8 разрядные (разработчики портировали с другой архитектуры без существенной переработки, это моё личное мнение) Например возьмём убогий пример, и откоипилируем с опцией -O2, компилятор последний офиц WinAVR (а по сути здесь и не важно) uint8_t get_small_val() { return 0x8; } uint32_t test(uint32_t val) { uint8_t tmp = get_small_val(); val += (uint16_t)tmp << 8; return val; } то получим 00000284 <get_small_val>: 284: 88 e0 ldi r24, 0x08; 8 286: 90 e0 ldi r25, 0x00; 0 288: 08 95 ret 0000028a <test>: 28a: ef 92 push r14 28c: ff 92 push r15 28e: 0f 93 push r16 290: 1f 93 push r17 292: 7b 01 movw r14, r22 294: 8c 01 movw r16, r24 296: f6 df rcall .-20 ; 0x284 <get_small_val> 298: 99 27 eor r25, r25 29a: 98 2f mov r25, r24 29c: 88 27 eor r24, r24 29e: aa 27 eor r26, r26 2a0: bb 27 eor r27, r27 2a2: 8e 0d add r24, r14 2a4: 9f 1d adc r25, r15 2a6: a0 1f adc r26, r16 2a8: b1 1f adc r27, r17 2aa: bc 01 movw r22, r24 2ac: cd 01 movw r24, r26 2ae: 1f 91 pop r17 2b0: 0f 91 pop r16 2b2: ff 90 pop r15 2b4: ef 90 pop r14 2b6: 08 95 ret Во-первых функции которые возвращают uint8_t расширяются до int (строчка 286), причём как я смотрел совершенно не зависит от опций оптимизаций, конечно есть волшеьная опция -mint8 которая заставляет int принимать 8 бит, но при этом разработчики не гарантируют что все проекты откомпилируются с данной опцией. Во-вторых по согласованию распределения регистров с переменными, есть 3 типа, в стандартном, бедет всегда такая картина при передаче и возврашение 32 битного числа (292-294, 2aa-2ac). Причем если активно использовать 32 битные типы (да понимаю AVR не затачивался под 32) то таких констукций будет много. Причем нам явно младший байт после сдвига tmp прибавлять не надо, это очевидно. Но GCC этого "не прнимает". Причем если не написать (uint16_t) перед опеорацией сдвига, то компилятор расширит uint8_t до int, а int знаковое, и после сдвига явно сбросит 7 бит, чтобы расширение произошло "корректно". Есть ещё моного тонкостей на которые я наткнулся... Но вот если в проекте на так много 32битных вычисление то GCC может очень изащренно оптимизировать код, бывало когда я смотрел дамп аж сам биву давался как он налавкачел.. =) Ещё один огромнейший и неоспоримый плюс GCC это ассемблерные вставки. В них можно написать что-то типа макроса и компилятор будет сам выбирать какие регистры ему в конкретном случае лучше использовать (применительно к inline конструкциям) __asm__ __volatile__ ( "ldd %0, Z+14" "\r\n" "andi %0, 0x8C" "\r\n" "lsr %0" "\r\n" "mov __tmp_reg__, %0" "\r\n" "lsr %0" "\r\n" "swap __tmp_reg__" "\r\n" "or %0, __tmp_reg__" "\r\n" : "=r" (resp) : "z" (data) ); Вместо %0, в котором размещается resp, компилятор сам подставит необхолимые регистр, далее указываем компилятору чтобы в Z было data. Если бы в констукции использовался явно какой-то регистр (например после mul) то его нужно было бы включить в список экранируемых регистров ( : "r1" , после : "z" (data) ). При это генерируемы код, если правильно составить макрос булет 100% безопасным. Тема написания вставок вообще очень интересная, думаю общий обзор дал.. Я использую WinAVR на всех проектах с AVR, а где код сильно тормозил, использовую вставочку =)

Вот мне и не хотелось использовать ARM+ внешний USB так как придётся через обычные GPIO устраивать обмен, то потерь будет много, а контроллер ещё что-то полезное должен делать кроме USB, или я не прав? А вот если взять, к примеру, AT91RM9200 и Cypress с его 16 битной шиной прицепить к ARM как SRAM, и обращаться к FIFO USB серез обычное считывание/запись в память? Кто-то что-то типа такого делал? (Так я видел Mega128 и RTL8019 соединяли) :bb-offtopic: Ой, зашёл я в раздел про трассировку, как почитал несколько тем про разводку BGA, распайку и стоимость плат в несколько k$, так до сих пор дрож в коленках не проходит...

Да спасибо, вот только, к сожалению, существует только в BGA :angry2: Нету ли ешё какого-нибудь в более юзабельном корпусе?

Существует ли ARM + USB 2.0 Hi-Speed в одном микроконтроллере, а то посмотрел всё линию AT91SAM там токо FullSpeed.. А то только в AVR32 видел HiSpeed...

Я сечас как раз этим занимаюсь.. полгода с PPP бодать уж слишком он у меня за 2 недели взлетел, стек TCP использую lwpp (http://savannah.nongnu.org/projects/lwip/) прикрутил дня за 4 вот только объем оперативной памяти для всего этого чуда нужно побольше, поэтому я отказался от AVR в пользу ARM. В некоторых ARM есть PDC что удобно. PS А на стек PPP от lwip я забил так как в GSM/GPRS вообще не нужна аутентификация. А также я забил на сжати Ван-Джакобсона и тд. В итогде сделал свой. PPS А вот с модудем ещё это дело не связал если нужно могу выложить свой PPP стек, только там пока много багов

Спасибо, вот только не подскажите где к нему полновесный PDF найти Проштудировал http://www.sim.com/ но там какие-то неправильный pdf ки, или я уже разучился искать..

Есть подозрение что простой джам искажает сигнал так как его тоже надо учитывать =) лучше мерить что-то типа while(1) { AT91F_PIO_ClearOutput( AT91C_BASE_PIOA, LED0 ) ; AT91F_PIO_SetOutput( AT91C_BASE_PIOA, LED0 ) ; AT91F_PIO_ClearOutput( AT91C_BASE_PIOA, LED0 ) ; AT91F_PIO_SetOutput( AT91C_BASE_PIOA, LED0 ) ; AT91F_PIO_ClearOutput( AT91C_BASE_PIOA, LED0 ) ; AT91F_PIO_SetOutput( AT91C_BASE_PIOA, LED0 ) ; AT91F_PIO_ClearOutput( AT91C_BASE_PIOA, LED0 ) ; AT91F_PIO_SetOutput( AT91C_BASE_PIOA, LED0 ) ; }

Да хоть и BasicGNU+GNUARM дает меньший объем проги (когда нет глобальных переменных =) Вобщем забил я на эту связку использую WinARM, этот без проблем генерит всё как надо.

Испытал я данную констукцию у себя для интереса, компилятор WinARM, на кварце 18.432 (MSK 73.9232) при компиляции без оптимизации (-O0) даёт приетно 0.5 Мгц при компиляции с оптимизацией (-O2) скважность сигнала уже не 0.5 да и форма на моем домашнем осцилографе сильно непрямоугольная F > 2-4 mhz (больше он у меня не берёт)

У меня резистор тоже намертво запаян, и примеры с FreeRTOS: ARM7_AT91SAM7S64_IAR, с WinARM: at91sam7s64_basicusb идут без проблем...

Доброго времени суток! Кто какими GSM модулями с GPRS пользовался? Меня в принципе интересует самый дешёвый из доступных, главное чтобы GPRS поддерживал. (стек TCP/IP хочу через внешний MK пустить)

Я заказал 35 штук SCDA1A0801 (производства ALPS) в http://derikon.ru/ должны предти к концу мая. А до этого похожим способом покупал дохлые кард ридеры в ультре, они там дешевле по $2,8 были.. Ещё когда был на выставке Експоэлектроника российский дестрибьютор Molex просто божился что они есть на складе в Воскве PS Я тоже хочу отладочную плату (когда будуте заказывать свяжитесь со мной =)

прикрепил архив тестового проекта gnu_test.rar

В BasicGNU такой скрипт OUTPUT_ARCH(ARM) /* specify the AT91SAM7S64 memory areas */ MEMORY { flash : ORIGIN = 0x00000000, LENGTH = 64K /* free FLASH area */ ram : ORIGIN = 0x00200000, LENGTH = 16K /* free RAM area */ } /* define a global symbol _stack_end <=> End of SRAM */ _stack_end = 0x00210000; SECTIONS { /* Code and data are mapped at the bottom of the internal FLASH */ .text : { _text = .; /* define a global symbol marking the start of the .text section */ *(.startup) /* define the entry point */ *(.text) /* all .text sections (code) */ _etext = .; /* define a global symbol marking the end of the .text section */ } > flash .rodata : { _srodata = .; /* define a global symbol marking the start of the .rodata section */ *(.rodata) /* all .rodata .rodata* sections (constants, strings, etc.) */ *(.rodata*) /* all .rodata* sections (constants, strings, etc.) */ *(.glue_7) /* all .glue_7 sections (mandatory before gcc 4.0.0) */ *(.glue_7t) /* all .glue_7t sections (mandatory before gcc 4.0.0) */ _erodata = .; /* define a global symbol marking the end of the .rodata section */ } > flash .data : { _sdata = .; /* define a global symbol marking the start of the .data section */ *(.data) /* all .data sections */ _edata = .; /* define a global symbol marking the end of the .data section */ } > ram .bss : { __bss_start = .; /* define a global symbol marking the start of the .bss section */ *(.bss) /* all .bss sections */ *(COMMON) __bss_end = .; /* define a global symbol marking the end of the .bss section */ } > ram _end = .; /* define a global symbol marking the end of application */ end = .; } Причем если глобальная переменная неинициализирована (или 0) то она попадает в .bss и всё ОК Но если её инициализировать глобально то она попадает в .data и при генерации бинарника происходит глюк. Я не силен в ldscript =( но может у кого-то есть какие-то домыслы как исправить ситуацию. Вот посмотрел на секции в IAR: SEGMENTS IN THE MODULE ====================== DATA_I Relative segment, address: 00200000 - 00200003 (0x4 bytes), align: 2 Segment part 2. Intra module refs: Segment part 9 ENTRY ADDRESS REF BY ===== ======= ====== LedSpeed 00200000 ....... DATA_ID Relative segment, address: 000002A4 - 000002A7 (0x4 bytes), align: 2 Segment part 3. Intra module refs: LedSpeed ------------------------------------------------------------------------- INITTAB Relative segment, address: 00000298 - 000002A3 (0xc bytes), align: 2 Segment part 13. ROOT. ENTRY ADDRESS REF BY ===== ======= ====== ?init?tab?DATA_I 00000298 Тоесть IAR инициализированные переменные хранит во флеше, и добавляет код инициализации секции инициализированных данных, как заставить GNUARM делать такое же?

Скачал я набор компилятора GCC 4.1 с проекта GNUARM (http://www.gnuarm.com/) Базовые файлы нашёл на at91.com: http://www.at91.com/www/phpBB2_mirror/download.php4?id=211 И скомпилил протенький приерчик (мигает свтодиодом, под 91SAM7S128) ... инклуды и всё такое #define SPEED (MCKKHz/10) unsigned int LedSpeed = SPEED *50; void wait ( void ) { unsigned int waiting_time ; change_speed () ; for(waiting_time = 0; waiting_time < LedSpeed; waiting_time++) ; } int main() { AT91F_PMC_EnablePeriphClock ( AT91C_BASE_PMC, 1 << AT91C_ID_PIOA ) ; AT91F_PIO_CfgOutput( AT91C_BASE_PIOA, LED2 ) ; AT91F_PIO_SetOutput( AT91C_BASE_PIOA, LED2 ) ; for (;;) { AT91F_PIO_ClearOutput( AT91C_BASE_PIOA, LED2) ; wait(); AT91F_PIO_SetOutput( AT91C_BASE_PIOA, LED2 ) ; wait(); wait(); } } всё прошло хорошо на на этапе генерации бинарника arm-elf-objcopy --output-target=binary a.out BasicGNU.bin он из a.out (71кб) сгенерил бинарник на 2mb + 4bytes!!! открыв в hex редакторе увидил что первые ~900 байт ненулевые далее идут 0 и по смечению 2mb записано чило, очень похожее на SPEED *50. Объявив эту переменную просто глобально, без инициализации, и проделав инициализацую в mian бинарник стал 924байта, успешно залился и на платке мигает диод.. На IAR первоначальный код генерирует нормальный бинарник. Может кто-то работал с GNUARM и знает в чём дело? (даже если кто-то и не работа, всё равно интересно мнения =)

Номиналы те, которые указал ув. DASM. Если нужна схема -- можете посмотреть здесь: http://www.olimex.com/dev/images/sam7-h64-sch.gif Наконец-таки удалось!!! Всем СПАСИБО!!! Перепаял я эту цепочку, номиналами DASM. Всё взлетело.. что-то вчера я сильно стормознул (и сегодня всё утро =)...

Проделал указанную последовательность -- не помогло. Прооверя ещё раз железо только пин PLLRC наводит на смутные сомнения.. каких номиналов R, C туда нужно напаять

Поле подтянутой TST и манипуляцией с RESET в винде появилось USB Device Not Recognized..

USB D+ у меня поддтянуто 1,5кОм Заперел напряжение при воткнутом USB проводе на D- ~0 на D+ 310мВ Поробовал на 10 сек замкнуть TST но результата что-то не дало А вот цепочку PLL я упустил из виду.. Позник вопрос но у по PLL там очень абстрактно сказано как выбирать R C1 C2.. (осталось запустить MatLab и поплясать с передаточной функцией) Можете посоветовать значения чтоб уж точно их выбор не влиял на неправильную работу?

Доброго всем времени суток! Вот решил освоить ARM. В качестве жертвы был выбран AT91SAM7s128. К нему подпаял USB разъем, через MAX3232 DEBU, кварц на 18.432 VCORE взял с внутреннего стабилизатра. Я почитал DataSheet и вроде там указывалось что уже на голом чипе есть программа начальной загрузки. (она кстати активна по дефолту или надо какие-то шаманские пляски предварительно провести???) Подключаю через USB, ноль эффекта никаких событий не происходит.. Ну ладно пробую через COM тоже ничего. Схему проверил, пока ничего особенного не нашёл, на VDDIO 3.3v со стабилизатора 1.9. В каком направление посоветуете копать?