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

Petka

Свой
  • Постов

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

  • Посещение

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


  1. Хорошо хоть, что с этих мейкфайлов снято обвинение в «безграмотности», теперь они просто «старый код» :)

    А теперь представьте, что в следующей версии make введут новый ключик, и вам придётся править все свои мейкфайлы. Имхо, это неправильно. И сравнение с volatile здесь не совсем уместно - в случае make ничто не мешало авторам поставить между субцелями пресловутые «точки следования».

    ИМХО вывод сообщений неправильно организовывать как подцели какой-либо цели.

    По замыслу make, подцели необязательно вообще будут выполняться by design.

    Про определённый порядок выполнения зависимостей нигде никогда ничего не гарантировалось.

    Всё что вы просили выполнить в вашем makefile для цели all будет добросовестно выполнено. Вывод на экран сообщений был? Размер выводился? elf собирался? При любом ключе -j ?

    Проводя аналогии с компиляторами: сейчас уже никого не удивляет, что в ассемблерном листинге оптимизирующего компилятора фактический порядок "промежуточных" арифметических вычислений может отличатся от написанного в исходном тексте программы. Не говоря уже о выкидывании незадействованного кода. Если программист заложился на какие-то побочные свойства инструмента - это только ответственность программиста а не проблема инструмента.

  2. Ой ли? Сдаётся мне, что ключ -j появился далеко не сразу. И к этому времени было уже очень много таких вот "безграмотных" мейкфайлов.

    Это не причина НЕ исправлять такие makefile.

    Раньше и в компиляторах не было volatile. Но это не причина НЕ исправлять старый код.

  3. Да, наверняка всё так и есть. Но мне это не нравится.

    Часто вижу варианты типа:

    all: message_begin elf size message_end

    Получается, что все эти варианты тоже будут глючить от многопоточности. Имхо, надо было и в такой перечень целей вставить «точки следования».

    Банальная безграмотность создателей таких make файлов.

  4. На мой взгляд, тут всё же играют свойства присваивающего выражения, а не compound assignment.

    ....

    Я про оптимизацию этого куска кода:

    if (!(--rs->fifo.tx.cnt))

    В нем оптимизатор всё сделал правильно. Никаких "вольных" трактовок volatile.

  5. С примерчиком нет проблем, хоть и, возможно, слегка натянутым. Нужно просто придумывать на периферии, а не в ОЗУ.

    .....

    В той оптимизации ТОЧНО всё нормально.

    6.5.3.1 Prefix increment and decrement operators

    Constraints

    The operand of the prefix increment or decrement operator shall have qualified or

    unqualified real or pointer type and shall be a modifiable lvalue.

    Semantics

    The value of the operand of the prefix ++ operator is incremented. The result is the new

    value of the operand after incrementation. The expression ++E is equivalent to (E+=1).

    See the discussions of additive operators and compound assignment for information on

    constraints, types, side effects, and conversions and the effects of operations on pointers.

    The prefix -- operator is analogous to the prefix ++ operator, except that the value of the

    operand is decremented.

     

    Далее:

    6.5.16.2 Compound assignment

    Constraints

    For the operators += and -= only, either the left operand shall be a pointer to an object

    type and the right shall have integer type, or the left operand shall have qualified or

    unqualified arithmetic type and the right shall have arithmetic type.

    For the other operators, each operand shall have arithmetic type consistent with those

    allowed by the corresponding binary operator.

    Semantics

    A compound assignment of the form E1 op = E2 differs from the simple assignment

    expression E1 = E1 op (E2) only in that the lvalue E1 is evaluated only once.

  6. ...

    1 и 4 кпируют волатайл переменную в R16 и далее все операции идут с регистром, что экономит порядка 20 тактов.

    3 - для одноразовой операции нет разницы, используется указатель или индекс. Всё равно будет с нуля браться адрес и вычисляться смещение.

    Не суть.

    5 - ваш глюк.

    А что запретит прерывание по UART_RXC? Если прерывание не запрещены, то при следующем входном байте на UART будет снова вызван обработчик прерывания.

    вы так упорото не хотите понять, что индекс массива у вас никак не защищён от переполнения вниз.

    А про порчу памяти от прерывания вам уже всё сказали.

    так это или не так легко проверить: поставьте проверку на индекс массива

    if(ADC2_RxC_counter >= ADCBUFSISE){
        ERROR_LED_ON;
    }

  7. В общем, память однозначо перетирают прерывания от АЦП.

    volatile unsigned char laja; // TEST
    
    #pragma vector=(0x48*0x02)
    __interrupt void ADC3_RxC_isr(void) { // 
        unsigned char ADC3_temp; 
        
        ADC3_temp = ADC3_RxC_counter;
        ADC3_temp--;     
        laja = UDR1;
    //   Buf_ADC3[ADC3_temp] = UDR1;
    
        if(ADC3_temp) {
            UDR1 = ADC3_temp;    
        } else { 
            ADC3_CS_PASSIV;  
        }
        
        ADC3_RxC_counter = ADC3_temp;
         PORTA ^= ((1<<1));  
    }

     

    Полный бред.

    1) ADC3_temp = ADC3_RxC_counter;

    2) ADC3_temp--;

    3) Buf_ADC3[ADC3_temp] = UDR1;

    4) ADC3_RxC_counter = ADC3_temp;

    5) goto 1

    Разумеется после обнуления ADC3_temp команда из п.2 сделает ADC3_temp==0xFF и тогда п.3 сломает память.

  8. согласен с подобными оценками, но лишь частично, не могу поверить что там меньше процента кушается (хотя Linux известен тем что не кушает лишнего проца)

    Как раз на днях знакомился с подсистемой времени в Linux.

    Па факту аппаратный таймер вызывался только с частотой, заданной при сборке ядра (в моём случае 1000 HZ). Никаких других неучтённых срабатываний таймера не было. Т.е. по факту в "фоне" вызывался только планировщик ядра. Если планировать нечего (работает только одно ваше приложение), то планировщик сразу возвращает вашему приложению управление. Само-собой если вы используете сеть, то отдаётся процессорное время сетевой подсистеме и т.д. Но как я говорил ранее - это в любом случае будет пожирать ресурсы. С Линуксом камень или нет.

  9. Выкладываю обновлённую версию прошивок программатора.

    Изменения:

    1. Преобразование кода АЦП в вольты осуществляется более точно.

    2. Изменена строка идентификации программатора на "STK500_2".

     

    Программатор с новой прошивкой сможет работать в последних версиях AVRStudio.

    AvrUSB500_by_Petka_HEX_SRC_v8_uni.zip

  10. ...

    Кстати, а ембеддед линукс много процессорного времени использует на посторонние вещи? Как сильно мне придется отвыкать от того, что все такты тратятся на нужный мне алгоритм?

    Линукс ничего не делает "лишнего". Какие сервисы вы запустили на нём, те и будут работать. Не нужны никакие сервисы - отключайте их напрочь. Единственное что останется - 100 Раз в секунду будет вызываться планировщик. Если планировать нечего, то он никакого процессорного времени не сожрёт. Переключение контекста происходит достаточно быстро (десятки тактов). Итого мимо вашей программы пройдёт максимум 0,01%. Понятно, что драйвера периферии будут отжирать время. Но если без ОС, то всё-равно будут драйвера и будут жрать соизмеримое количество ресурсов.

  11. Удобнее выбрать более популярный дистрибутив, так как при возникновении вопросов легче будет найти ответы. Следовательно, убунту.

    Поддерживаю. Тем более убунту исторически вросла из дебиана. По этой причине они по большей части совместимы.

    P.S. Для человека сильно привыкшего к windows рекомендую попробовать Kubuntu (Ubuntu + KDE). Кубунту внешне очень похожа на Win. Первое время будет более привычно выглядеть.

  12. Простите за чайниковский вопрос, но к примеру если пользоваться линуксом, то компилировать программу так же в "Eclipse+CodeSourcery"?

    Почти так. CodeSourcery это всего-лишь сборка GCC. Для сборки программы к линуксу у вас будет аналогичный кросс-компилятор (тоже сборка GCC). Eclipse может работать с любым GCC.

  13. Тогда в случаи с next->prev=prev; prev->next=next; тоже нету явного указания компилятору, что prev может изменится. Ситуация аналогичная вроде? если next->prev == <cast...>&(prev->next) то это вероятно ошибка программиста.

    ...

    Ситуация далеко не аналогичная. Просто прямое обращение по адресу и обращение двойное обращение по адресу.

  14. Тоесть компилятор всегда перегружает переменную,если ранее была лябая запись в память?

     

    Хотя вот:

    char b[5];
    int f(long long *c){
        *c=1;
        b[2]=1;b[3]=2;
        return *c+b[3];
    }

    ......

    Тут компилятор волен оптимизировать. т.к. char b не обьявлен как volatile т.е. нет указания компилятору что содержимое b может измениться. Поэтому если с указывает на b, то это очевидная ошибка программиста.

  15. &(prev->next) Имеет тип tormoz**, а next->prev tormoz* . просто так оно не может быть присвоено.

    Это программистом в явном виде так присвоено не может быть. А через приведение типов может быть как угодно.

    Ну тогда уж и компилятор не должен ничего удалять в таком случаи:

    volatile int t;
    void f(char *v){
        *v=3;
        t=4;
        *v=5;
    }

    Вдруг v=&t , он же не может этого знать. тем не менее:

    Тут другой случай. v всегда указывает на одну и ту же ячейку памяти и запись в t ничего не может изменить. v может указывать куда угодно, хоть на t. Это ничего не меняет.

  16. Интересно с какой?

    Если будет next==prev всеравно поля next->prev,prev->prev и next->next,prev->next будут иметь разные адреса.

    Если next==prev==this тогда this->prev=this; this->next=this;

    Чет никак не могу придумать, как можно добится разного поведения от этих двух разных реализаций...

     

    апд. сории,в коде перепутал местами, но сути это не меняет,компилится так же.должно быть так

        next->prev=prev;
        prev->next=next;
    
    11a:    e9d0 1200     ldrd    r1, r2, [r0]
    11e:    604a          str    r2, [r1, #4]
    120:    e9d0 1000     ldrd    r1, r0, [r0]
    124:    6001          str    r1, [r0, #0]

     

    А если next->prev == &(prev->next) ? Компилятор не может знать что это в вашем случае это не так =)

  17. Ни один компилятор не смог нормально соптимизировать простые очевидные вещи..

    Очевидно же:

    После выполнения

        next->prev=next;

    Следующаяя строка кода может работать с совсем ДРУГОЙ памятью, нежели ДО выполнения предыдущей строчки. Оптимизатор просто не имеет права ничего удалять.

        prev->next=prev;

     

    В данном случае всё указано однозначно.

    void tormoz::remove(){
        tormoz *n=next,*p=prev;
        n->prev=p;
        p->next=n;
    }

     

     

  18. ....

    Не назовете какие чипы попали в эти 90%?

    Все процессоры с ядрами PowerPC, SPARC, MicroBlaze, Motorola 68000, M32R (Renesas), TMS320C6x.

    Это я ещё всякую экзотику не брал типа вымерших AVR32.

    Частью сам проверял, часть по чужим системам и слухам. Тут, конечно надо уточнить, что под ресурсами понимаем. Объемы памяти под образ и RAM? Если про производительность, то по каким критериям? Время реакции называл и это не предположения. Есть еще потребление, время загрузки и т.д..

    Вон на выставке своими глазами видел работающий linux на CortexM4 от Freescale. Время загрузки - около секунды. И крутится демка на QT. Памяти там тоже было совсем мало. WinCE так сможет?

    Ну и шарп еще. Тренд действительно туда, насколько это хорошо годится для глубоко встраиваемых систем у меня пока сомнения.

    Шарп - да.

    Однако отсутствие вменяемых инструментов для каких либо платформ кроме как от микрософт приводит к зависимости и опять таки к отсутствию выбора.

    ИМХО на шарп лучше не закладываться.

    Только у кого лучше?

    У Явы, QT, GTK лучше. HTML5 может стать одним из фаворитов в ближайшем будущем. (Посмотрим как всякие ChromeOS, FirefoxOS и WebOS поведут себя на рынке).

    На линоксе будет тот же QT, ну может быть чуть более родной, но не ставший от этого не легче, не резвее.

    На Линуксе можно запустить практически всё: QT, java, GTK. Даже .NET и GDI.

    QNX прикрутила флеш.

    Flash - тоже умирает. Адоб в скором времени перестанет его поддерживать развивать в угоду HTML5. Такие дела =)

    ...

    Повторюсь, что здесь надо вдолгую играть.

    ...

    Согласен, в эмбеддед приходится долго играть. Для этого надо иметь максимальную независимость от прихотей какой-либо одной компании.

    Свернёт МС эмбеддед - по миру идти?

    Свернул Атмел AVR32 - по миру идти?

    Свернёт Адоб свой Флеш - .... ?

  19. Не знаю насколько хорошо вы знакомы в WinCE, и стоит ли тут что-то обсуждать.

    Одно время рассматривал возможность запуска WinCE на своём изделии (тоже на XScale). Ознакомился с Platform Builder, собрал систему. На тот момент времени функционал получившейся системы оказался неконкурентоспособен.

    С драйверами и BSP проблема скорее не в их недостатке, а в их качестве.

    BSP для WinCE сейчас отсутствует для 90% чипов с MMU. А на чипах без MMU наверняка не работает вообще.

    С 2006 года никакого развития. Только в 2011 году выпустили новую версию. ИМХО последнюю.

    А скажите где с этим хорошо и задешево :rolleyes:?

    Линукс сейчас по этому критерию однозначно лидирует. Производители чипов хотят заполучить огромный рынок на Andriod.

    Ресурсов она ест сопоставимо с системами этого же класса, скорее даже поменьше.

    Есть ли какие-нибудь результаты тестирования? Или это предположение?

    ....

    С программистами с одно стороны проще. Для разработки приложений любой, кто пишет под Win32 на студии, почти не заметит разницы....

    Программисты под win32 тоже скоро станут редкими.

    Основной трэнд - ява. На этой платформе пишет огромное количество взаимозаменяемых программистов "высокого уровня". И не за дорого.

    Не знаю, что имелось в виду под устаревшим GUI. Исходно там все тот же Win32 GDI.

    Это и есть жуткое старьё. Делать на "этом" удобный пользовательский интерфейс долго без использования каких - либо тулкитов. А любой вменяемый тулкит может работать практически на любой платформе.

    ....

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

    ...

    По секрету скажу, что Микрософт решила похоронить сильверлайт как не оправдавший себя проект.

     

    P.S. Искренне удивлён, как вам удалось связываться сразу с несколькими, которые уже "уходят в мир иной":

    1. XScale - процессорное ядро на текущий момент поддерживаемое только интелом. Вытесняется по всем фронтам процессорами на базе ядер Cortex-A.

    2. WinCE - безнадёжно отставшая ОС. Микрософт прекратит её поддержку в пользу "Windows RT".

    3. Silverlight - "..компания Microsoft также фактически отказалась от разработки Silverlight в пользу технологий HTML5, которые будут использоваться в Windows 8. Silverlight 5 был выпущен в конце прошлого года и будет официально поддерживаться до 2021 года, но это будет последним значительным релизом платформы, развитие которой приостановлено. "

    4. Win32 API - "Only software written using the Windows Runtime (Metro-style apps) can be used on Windows RT. Developers will not be able to create applications to run on Windows RT using the Win32 APIs" (Надо перевести?)

  20. Из того, что мне близко - охранные системы, СКУД, видеонаблюдение, видеорегистраторы (я имею в виду железки, а не сервера сбора данных).

    Эти применения вообще можно делать на чём угодно. Никаких достоинств WinCE тут не даёт. Это всё более менее массовые продукты. ИМХО тут операционку с более низкой ценой лучше брать. И с бОльшей гибкостью.

    Из того, что не близко, но могу предположить - медицинская аппаратура, измерительное оборудование, всякие там осцилографы и энцефалографы, и проч.

    Тут ситуация другая - аппаратура малотиражная и более дорогая. Её просто исторически делали на Win. Переделывать получается дороже, чем обновить на что-то более удобное/дешёвое.

  21. ...

    Не то, что труп, но нишевый продукт. На мой вкус, для встроенных систем WinCE черезвычайно хороша, и уж всякие там андроиды ее никак не заменят.

    Зачем андроид? Можно и VxWorks, можно и встраиваемый Linux.

    Первый если хочется денег заплатить. Второй, если опыт есть и роялти не хочется платить и нужна очень большая гибкость.

     

    P.S. Кстати интересно узнать и какая же ниша у WinCE? Драйверов нету, ГУИ - устаревшее, даже подобия реального времени нету, ресурсов жрёт много, готового софта - почти нету, программистов под втраиваемую винду тоже всё меньше и меньше. Странная штука.

  22. .... Заметил, что когда проводишь пальцем по ножкам меги8, то это помогает иногда успешно связаться с таргетом.. Взял другой программатор на attiny2313/at90s2313 - avr910 - и программы avrosp2 и avrprog: эта mega128l при питании 3,3В c avr910 работает без проблем. Взял снова avrusb500 и аврстудию 4 и стал подключать к другим процам (у всех питание 5В) - результаты получше, но особо не обрадовал: ошибки выскакивают иногда. ....

    Что могло случиться с этим программатором?

    Скорее всего где-то не отмыт флюс. Прошло время, дорожки/контакты окислились и появились утечки. Промойте плату с мылом и щёткой, потом спиртом/бензином и остатки спирта/бензина протрите сухой ваткой.

    Так-же посмотрите под лупой все ли контакты пропаяны. Если при нажатии на микросхему работоспособность устройства меняется - один из признаков непропаянных контактов.

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

    Обратноходовую, прямоходовую, двухтактную, мостовую и т.д.

    ИМХО обратноходовые преобразователи гораздо проще строить на МК общего применеия, нежели чем мостовые.

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