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

Petka

Свой
  • Постов

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

  • Посещение

Сообщения, опубликованные Petka


  1. пересмотрел схемы,моя отличается только с 2 с 3 по 18 рф и с 9 с 10 18 рф это с сайта Радиокот http://www.radiokot.ru/lab/controller/45/ ,для с 2 с 3 в продаже только 24 и 30 рф какие лучше , а с9 и с10 можно оставить или нужно одного номинала все ставить

    С2,С3,С9,С10 ставьте 24пФ

     

  2. И при чем здесь ARM?

    Интел умеет читать по не выравненному адресу, зачем читать по байтам?

    Может, но не обязан. (См. eFlags, бит 18)

     

    И при чем здесь ARM?

    Да, проверил на ARM. Действительно читает по-байтно.

     

    P.S. Вот бы ещё ссылку на стандарт какой.

  3. Ну вам не помогают, а мне помогают

    ....

    По листингу все читается по байтам, так что все ок!

    Все таки надо использовать typedef и при присваивании преобразовывать указатели, что бы не плодить warningи, на которые стоит обращать внимание!

    Давайте разбираться:

    Собрал ваш код 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.

     

    KRS все уже объяснил, почему делать так, как Вы сделали, неразумно.

    Только что проверил.

         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. Зато можно сделать typedef с опцией packed, тогда все будет ок! и код будет понятный.

    1) И чем это поможет?

    2) Всяческие атрибуты выходят за стандарт Си. Когда однажды потом откомпилируете свой код с подобными атрибутами другим компилятором (или под другую архитектуру). Или даже если в рамках одной архитектуры и компилятора будет изменена endianness, то результат будет непредсказуемым.

     

  7. struct blabla {
        char ch;
        int that;
    } blabla_t

    При обращении к that и происходит, собсно, невыровненный доступ к памяти.

    Не верю!

    либо вы делаете примерно так:

    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 */
    }

     

    как-то так =)

  8. Спасибо за разъяснение. Хоть понял для чего нужен Cygwin :rolleyes:

     

    Итак, если хочется под виндами собирать под линукс, без cygwin'а не обойтись? А какой собственно кросс-компилятор посоветуете?

    1. А какая причина использовать для сборки линукса виндоуз?

    2. Компилятор для линукса сейчас практически один - gcc.

    3. Рекомендую обратить внимание на проект "buildroot". Это набор скриптов, с помощью которого автоматизированно собирается нужный вам кросс-компилятор (из исходных кодов gcc), ядро линукса, загрузчик, файловая система, на которой будет запускаться ядро и минимальный набор утилит, которым все привыкли пользоваться в линуксе.

  9. А если взять виндовый кросс-компилятор под ARM (бинарники), а хедеры и либы перетянуть из родного SDK? Будет работать?

    Обычно для систем сборки линукса и его окружения нужна НОРМАЛЬНАЯ файловая система, поддерживающая: атрибуты "файл запускаем", симлинки, для скриптов configure нужен нормальный, человеческий шелл, утилиты (make, patch, tar и прочие). Cygwin пытается дать такое окружение.

    Если даже всё это вам и удастся обеспечить под виндой, то работать это будет ооооочень медленно. Субъективно сборка одного и того-же проекта одной и той-же версией компилятора под виндой раз 5 осуществляется дольше.

  10. ...

    Есть некая железяка с ARM + Embedded Linux, есть родной SDK (включая тулчейн), который естественно под линукс, есть даже хост-машина где все это развернуто под Debian'ом и работает :biggrin:

    Есть другая машина под виндами, с эклипсом и CDT. Хотелось бы собирать все то же самое на ней. Какие телодвижения нужны для этого? :rolleyes:

    Гуглите "cygwin". Но лучше используйте нативный линукс.

  11. Ещё такой вопрос. Какой последней версией avr studio вы советуете пользоваться для работы с AvrUsb500 by Petka.

    Я AVRStudio не использую. Программирую через avrdude. Если удобная вам версия AVRStudio поддерживает программаторы stk500, то смело используйте её.

  12. А можно по-подробне: что именно подводит, насколько часто и на каких ЖКИ от МЭЛТ ?

    А то у меня были планы их массово использовать.

    Часто попадаются битые пиксели, строки. Не разбирал, но такое ощущение что пакет с ЖКИ расслаивается. Некоторые дисплеи совсем нерабочие.

    Подсветка иногда бывает СОВСЕМ неравномерная. Использовали знакосинтезирующие 24*2. Болимин, Винстар и дешевле и качественнее. По крайней мере процент брака на порядок меньше. Кстати по поводу глюков знакосинтезирующих чипов. Как-то попались знакосинтезирующие вакуумно-люминесцентные дисплеи. Так в них со временем проявлялся вертикальный сдвиг знакогенератора. Связались с производителем. В новой ревизии исправили.

  13. делал но постоянно выскакивает ошибка 24 я её игнорирую но она всё равно есть

    "С начала рекомендуется перед записью прочитать контроллер, это позволит лишний раз убедиться в том, что он определяется, что программа правильно настроена и все остальное работает как нужно.

    Сообщение об ошибке Device missing or unknown device (-24) (Устройство неизвестно или повреждено) - говорит о том что Понипрог не может прочитать микросхему и нужно еще раз проверить правильность подключения, подается ли питание на программируемый контроллер и настройки самой программы"

  14. Добрый день!

    Добрый. Давайте по порядку:

    .. собрал программатор заработал сразу, программировал в PonyProg , установил как писали СОМ 1 запрограммировал с папки AVRUSB500_by_Petka_HEX 8.НЕХ но забыл установить фьюзы,програмировался 15 мин при проверке выдал ошибку 24

    Для начала перезалейте с помощью Pony ещё раз прошивку (не забудьте перед прошивкой стереть чип). Добейтесь что бы верификация прошивки была успешной.

    ...при проверке чипа 16 ау на чистоту пишет устройство отсутствует или неисправно куда рыть? ....

    После того как у вас будет гарантия, что прошивка программатора верифицирована. Идём дальше.

    Если при подключении программируемого устройства к программатору светодиод на программаторе не будет гореть непрерывно, то значит софт тоже не будет выдеть программируемый чип.

  15. А в пятой студии сей девайс и не должен работать, так как он определяется как AVR ISP а не STK-500, новая студия AVR ISP не поддерживает.

    Спасибо Атмелу.

    Как вариант программируйте внешней программой программатором. avrdude, например. Давно с ней работаю - полёт нормальный. Поддержку железных программаторов не уменьшают, а только расширяют.

  16. сам Eclipse вроде бы "portable", да вот только с Java у него какие-то особые отношения...

    сведения противоречивые: одни говорят, что достаточно установить JRE последней версии.

    так и есть.

    запускаю эклипс из батника так:

    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 - путь к каталогу на флэшке.

×
×
  • Создать...