Jump to content

    

Petka

Свой
  • Content Count

    1438
  • Joined

  • Last visited

Everything posted by Petka


  1. С2,С3,С9,С10 ставьте 24пФ
  2. Может, но не обязан. (См. eFlags, бит 18) Да, проверил на ARM. Действительно читает по-байтно. P.S. Вот бы ещё ссылку на стандарт какой.
  3. Давайте разбираться: Собрал ваш код gcc (4.5.2, "-O0"). Ошибка доступа ЕСТЬ! objdump -d -S ./a.out Вывод: 080483e3 <test2>: uint8_t msg[] __attribute__ ((aligned (16))) = { 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0A }; void test2(void) { 80483e3: 55 push %ebp 80483e4: 89 e5 mov %esp,%ebp 80483e6: 83 ec 28 sub $0x28,%esp blabla_t *bla; int a; bla= (blabla_t *)&msg[3]; 80483e9: b8 20 a0 04 08 mov $0x804a020,%eax 80483ee: 83 c0 03 add $0x3,%eax 80483f1: 89 45 f4 mov %eax,-0xc(%ebp) a = bla->that; 80483f4: 8b 45 f4 mov -0xc(%ebp),%eax 80483f7: 8b 40 01 mov 0x1(%eax),%eax 80483fa: 89 45 f0 mov %eax,-0x10(%ebp) printf("a = 0x%08X\n", a); 80483fd: b8 20 85 04 08 mov $0x8048520,%eax 8048402: 8b 55 f0 mov -0x10(%ebp),%edx 8048405: 89 54 24 04 mov %edx,0x4(%esp) 8048409: 89 04 24 mov %eax,(%esp) 804840c: e8 e3 fe ff ff call 80482f4 <printf@plt> bla=(blabla_t *)&msg[0]; 8048411: c7 45 f4 20 a0 04 08 movl $0x804a020,-0xc(%ebp) a = bla->that; 8048418: 8b 45 f4 mov -0xc(%ebp),%eax 804841b: 8b 40 01 mov 0x1(%eax),%eax 804841e: 89 45 f0 mov %eax,-0x10(%ebp) printf("a = 0x%08X\n", a); 8048421: b8 20 85 04 08 mov $0x8048520,%eax 8048426: 8b 55 f0 mov -0x10(%ebp),%edx 8048429: 89 54 24 04 mov %edx,0x4(%esp) 804842d: 89 04 24 mov %eax,(%esp) 8048430: e8 bf fe ff ff call 80482f4 <printf@plt> } 8048435: c9 leave 8048436: c3 ret И где тут по-байтное обращение?
  4. Прошу в студию код, как "правильно" объявить структуру blabla у ТС для gcc. Только что проверил. uint8_t msg[] __attribute__ ((aligned (16))) = { 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0A }; struct blabla_t { char ch; int that __attribute__((packed)); } __attribute__((packed)); struct blabla_t *bla; int a; bla=&msg[3]; a = bla->that; printf("a = 0x%08X\n", a); bla=&msg[0]; a = bla->that; printf("a = 0x%08X\n", a); результат: a = 0x08070605 Ошибка шины Итог: никакие "#pragma packed" вам не помогут! Вот теперь понятно? P.S. Я включил в системе контроль alignment. "Ошибка шины" это "SIGBUS" - и есть ошибка невыровненного доступа.
  5. Что в них "дикого"? Если смысл непонятен, поясню: Если информационный пакет пришёл по "сети" или из другого источника, когда не гарантируется что данные будут располагаться в памяти выровнено или когда Endianness отсылающей стороны может не совпасть с получателем. Тогда есть только одна возможность считывать поля структуры из памяти - побайтно, а потом собирать байты в слова. Описанный выше механизм позволяет из произвольно расположенной структуры в памяти вычитывать последовательно с гарантированно одинаковым результатом независимо от архитектуры, компиляторов и всяческих выравниваний. Разумеется, когда структура заполняется и пересылается в рамках одного вычислителя, то этот метод избыточен. Так понятней?
  6. 1) И чем это поможет? 2) Всяческие атрибуты выходят за стандарт Си. Когда однажды потом откомпилируете свой код с подобными атрибутами другим компилятором (или под другую архитектуру). Или даже если в рамках одной архитектуры и компилятора будет изменена endianness, то результат будет непредсказуемым.
  7. Посмотреть на библиотеку "CMSIS". upd: смотреть на функции: __get_PRIMASK __set_PRIMASK
  8. Не верю! либо вы делаете примерно так: char *incomming_message; ..... struct blabla *b; b = (struct blabla *) incomming_message; /* Так делать нельзя, т.к. компилятор не может ничего узнать будет ли то, куда указывает incomming_message выровнено в памяти! */ b->that = 100500; /* Если incomming_message не было выровнено, то и на доступ внутри структуры тоже будет ошибка выравнивания */ Один из вариантов решения (ИМХО не лучший): char *incomming_message; ..... struct blabla b; memcpy(&b, incomming_message); /* Таким образом мы создаём копию данных, которые гарантированно выровнены в памяти */ b.that = 100500; /* В этом месте компилятор обязан сгенерировать код без невыровненных обращений */ ИМХО более надёжный путь декодировать данные, приходящие с внешних каналов, не наступая на грабли (aligned/BigEndian): int read_u8(uint8_t **message, size_t *len, uint8_t *retval){ if (*len >= sizeof(uint8_t) ){ *retval = **message; *message += sizeof(uint8_t); *len -= sizeof(uint8_t); return 0; /* Ok */ } return (-1); /* Fail */ } int read_u16_LE(uint8_t **message, size_t *len, uint16_t *retval){ uint8_t msb; uint8_t lsb; if(read_u8(message, len, &lsb) < 0){ return (-1); /* Fail */ } if(read_u8(message, len, &msb) < 0){ return (-1); /* Fail */ } *retval = (msb << 8) | lsb; return (0); /* Ok */ } int read_u16_BE(uint8_t **message, size_t *len, uint16_t *retval){ uint8_t msb; uint8_t lsb; if(read_u8(message, len, &msb) < 0){ return (-1); /* Fail */ } if(read_u8(message, len, &lsb) < 0){ return (-1); /* Fail */ } *retval = (msb << 8) | lsb; return (0); /* Ok */ } как-то так =)
  9. Тогда цигвина может быть достаточно.
  10. 1. А какая причина использовать для сборки линукса виндоуз? 2. Компилятор для линукса сейчас практически один - gcc. 3. Рекомендую обратить внимание на проект "buildroot". Это набор скриптов, с помощью которого автоматизированно собирается нужный вам кросс-компилятор (из исходных кодов gcc), ядро линукса, загрузчик, файловая система, на которой будет запускаться ядро и минимальный набор утилит, которым все привыкли пользоваться в линуксе.
  11. Обычно для систем сборки линукса и его окружения нужна НОРМАЛЬНАЯ файловая система, поддерживающая: атрибуты "файл запускаем", симлинки, для скриптов configure нужен нормальный, человеческий шелл, утилиты (make, patch, tar и прочие). Cygwin пытается дать такое окружение. Если даже всё это вам и удастся обеспечить под виндой, то работать это будет ооооочень медленно. Субъективно сборка одного и того-же проекта одной и той-же версией компилятора под виндой раз 5 осуществляется дольше.
  12. Гуглите "cygwin". Но лучше используйте нативный линукс.
  13. Я AVRStudio не использую. Программирую через avrdude. Если удобная вам версия AVRStudio поддерживает программаторы stk500, то смело используйте её.
  14. Дроссель можно безболезненно заменить. 27 Ом рекомендует FTDI. 30 Ом тоже будет работать.
  15. Часто попадаются битые пиксели, строки. Не разбирал, но такое ощущение что пакет с ЖКИ расслаивается. Некоторые дисплеи совсем нерабочие. Подсветка иногда бывает СОВСЕМ неравномерная. Использовали знакосинтезирующие 24*2. Болимин, Винстар и дешевле и качественнее. По крайней мере процент брака на порядок меньше. Кстати по поводу глюков знакосинтезирующих чипов. Как-то попались знакосинтезирующие вакуумно-люминесцентные дисплеи. Так в них со временем проявлялся вертикальный сдвиг знакогенератора. Связались с производителем. В новой ревизии исправили.
  16. Ещё бы процент брака у них был низкий - были бы совсем молодцы. =(
  17. "С начала рекомендуется перед записью прочитать контроллер, это позволит лишний раз убедиться в том, что он определяется, что программа правильно настроена и все остальное работает как нужно. Сообщение об ошибке Device missing or unknown device (-24) (Устройство неизвестно или повреждено) - говорит о том что Понипрог не может прочитать микросхему и нужно еще раз проверить правильность подключения, подается ли питание на программируемый контроллер и настройки самой программы"
  18. В понипроге есть иконка на которой изображена стирательная резинка и полустёртый чип. Это и есть функция "стереть чип".
  19. Добрый. Давайте по порядку: Для начала перезалейте с помощью Pony ещё раз прошивку (не забудьте перед прошивкой стереть чип). Добейтесь что бы верификация прошивки была успешной. После того как у вас будет гарантия, что прошивка программатора верифицирована. Идём дальше. Если при подключении программируемого устройства к программатору светодиод на программаторе не будет гореть непрерывно, то значит софт тоже не будет выдеть программируемый чип.
  20. Спасибо Атмелу. Как вариант программируйте внешней программой программатором. avrdude, например. Давно с ней работаю - полёт нормальный. Поддержку железных программаторов не уменьшают, а только расширяют.
  21. Дело не в железе. Это точно. Проблемы со студией - обращайтесь в саппорт атмела.
  22. Это медианка вылазит так.
  23. так и есть. запускаю эклипс из батника так: set JRE_ROOT=%DEVEL_ROOT%/jre/jre-6u12 set WORKSPACE_ROOT=%DEVEL_ROOT%/workspace set ECLIPSE_ROOT=%DEVEL_ROOT%/eclipse/eclipse-cpp-ganymede-SR2-win32/eclipse "%ECLIPSE_ROOT%/eclipse.exe" -vm "%JRE_ROOT%/bin/javaw" -os win32 -arch x86 -data "%WORKSPACE_ROOT%" -vmargs -Xms512m -Xmx1024m Где DEVEL_ROOT - путь к каталогу на флэшке.