Jump to content

    

Petka

Свой
  • Content Count

    1438
  • Joined

  • Last visited

Everything posted by Petka


  1. Make

    Цитата(AHTOXA @ Aug 24 2012, 00:40) Пока не появился ключик -j - вполне себе гарантировалось После этого утверждения была бы уместна ссылка на документацию какой-то определённой версии make. С подтверждением этого смелого утверждения. ЦитатаНет. В моём примере (build: clean all) - как раз-таки ничего не собиралось. Ибо сначала выполнялась цель all, а потом - clean. В результате после выполнения make build - никакого elf-а не было. ... В этом примере для цели build необходимо удовлетворение двух взаимоисключающих подцелей. Вы так построили сценарий для make. При чём тут инструмент? Мне вся эта ситуация напоминает появление процессоров с "Hyper-threading". Тогда программисты не были готовы к настоящему параллельному выполнению потоков и отсутствие всяких "spin_lock" приводило к непредсказуемым результатам.
  2. Make

    Цитата(AHTOXA @ Aug 23 2012, 21:33) Хорошо хоть, что с этих мейкфайлов снято обвинение в «безграмотности», теперь они просто «старый код» А теперь представьте, что в следующей версии make введут новый ключик, и вам придётся править все свои мейкфайлы. Имхо, это неправильно. И сравнение с volatile здесь не совсем уместно - в случае make ничто не мешало авторам поставить между субцелями пресловутые «точки следования». ИМХО вывод сообщений неправильно организовывать как подцели какой-либо цели. По замыслу make, подцели необязательно вообще будут выполняться by design. Про определённый порядок выполнения зависимостей нигде никогда ничего не гарантировалось. Всё что вы просили выполнить в вашем makefile для цели all будет добросовестно выполнено. Вывод на экран сообщений был? Размер выводился? elf собирался? При любом ключе -j ? Проводя аналогии с компиляторами: сейчас уже никого не удивляет, что в ассемблерном листинге оптимизирующего компилятора фактический порядок "промежуточных" арифметических вычислений может отличатся от написанного в исходном тексте программы. Не говоря уже о выкидывании незадействованного кода. Если программист заложился на какие-то побочные свойства инструмента - это только ответственность программиста а не проблема инструмента.
  3. Make

    Цитата(AHTOXA @ Aug 23 2012, 14:28) Ой ли? Сдаётся мне, что ключ -j появился далеко не сразу. И к этому времени было уже очень много таких вот "безграмотных" мейкфайлов. Это не причина НЕ исправлять такие makefile. Раньше и в компиляторах не было volatile. Но это не причина НЕ исправлять старый код.
  4. Make

    Цитата(AHTOXA @ Aug 23 2012, 11:53) Да, наверняка всё так и есть. Но мне это не нравится. Часто вижу варианты типа: Кодall: message_begin elf size message_end Получается, что все эти варианты тоже будут глючить от многопоточности. Имхо, надо было и в такой перечень целей вставить «точки следования». Банальная безграмотность создателей таких make файлов.
  5. Цитата(ReAl @ Aug 16 2012, 18:55) На мой взгляд, тут всё же играют свойства присваивающего выражения, а не compound assignment. .... Я про оптимизацию этого куска кода: Кодif (!(--rs->fifo.tx.cnt)) В нем оптимизатор всё сделал правильно. Никаких "вольных" трактовок volatile.
  6. Цитата(ReAl @ Aug 16 2012, 16:48) С примерчиком нет проблем, хоть и, возможно, слегка натянутым. Нужно просто придумывать на периферии, а не в ОЗУ. ..... В той оптимизации ТОЧНО всё нормально. Цитата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.
  7. Одноразовый UART в AVR

    Цитата(Dikoy @ Aug 7 2012, 00:18) ... 1 и 4 кпируют волатайл переменную в R16 и далее все операции идут с регистром, что экономит порядка 20 тактов. 3 - для одноразовой операции нет разницы, используется указатель или индекс. Всё равно будет с нуля браться адрес и вычисляться смещение. Не суть. Цитата5 - ваш глюк. А что запретит прерывание по UART_RXC? Если прерывание не запрещены, то при следующем входном байте на UART будет снова вызван обработчик прерывания. вы так упорото не хотите понять, что индекс массива у вас никак не защищён от переполнения вниз. ЦитатаА про порчу памяти от прерывания вам уже всё сказали. так это или не так легко проверить: поставьте проверку на индекс массива Кодif(ADC2_RxC_counter >= ADCBUFSISE){     ERROR_LED_ON; }
  8. Одноразовый UART в AVR

    Цитата(Dikoy @ Aug 6 2012, 03:54) В общем, память однозначо перетирают прерывания от АЦП. Код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 сломает память.
  9. Цитата(AVR @ Jul 19 2012, 01:37) согласен с подобными оценками, но лишь частично, не могу поверить что там меньше процента кушается (хотя Linux известен тем что не кушает лишнего проца) Как раз на днях знакомился с подсистемой времени в Linux. Па факту аппаратный таймер вызывался только с частотой, заданной при сборке ядра (в моём случае 1000 HZ). Никаких других неучтённых срабатываний таймера не было. Т.е. по факту в "фоне" вызывался только планировщик ядра. Если планировать нечего (работает только одно ваше приложение), то планировщик сразу возвращает вашему приложению управление. Само-собой если вы используете сеть, то отдаётся процессорное время сетевой подсистеме и т.д. Но как я говорил ранее - это в любом случае будет пожирать ресурсы. С Линуксом камень или нет.
  10. AvrUsb500 by Petka. продолжение

    Выкладываю обновлённую версию прошивок программатора. Изменения: 1. Преобразование кода АЦП в вольты осуществляется более точно. 2. Изменена строка идентификации программатора на "STK500_2". Программатор с новой прошивкой сможет работать в последних версиях AVRStudio.
  11. Цитата(greenie @ Jul 17 2012, 21:00) ... Кстати, а ембеддед линукс много процессорного времени использует на посторонние вещи? Как сильно мне придется отвыкать от того, что все такты тратятся на нужный мне алгоритм? Линукс ничего не делает "лишнего". Какие сервисы вы запустили на нём, те и будут работать. Не нужны никакие сервисы - отключайте их напрочь. Единственное что останется - 100 Раз в секунду будет вызываться планировщик. Если планировать нечего, то он никакого процессорного времени не сожрёт. Переключение контекста происходит достаточно быстро (десятки тактов). Итого мимо вашей программы пройдёт максимум 0,01%. Понятно, что драйвера периферии будут отжирать время. Но если без ОС, то всё-равно будут драйвера и будут жрать соизмеримое количество ресурсов.
  12. Цитата(scifi @ Jul 7 2012, 10:29) Удобнее выбрать более популярный дистрибутив, так как при возникновении вопросов легче будет найти ответы. Следовательно, убунту. Поддерживаю. Тем более убунту исторически вросла из дебиана. По этой причине они по большей части совместимы. P.S. Для человека сильно привыкшего к windows рекомендую попробовать Kubuntu (Ubuntu + KDE). Кубунту внешне очень похожа на Win. Первое время будет более привычно выглядеть.
  13. Цитата(greenie @ Jul 6 2012, 19:58) Простите за чайниковский вопрос, но к примеру если пользоваться линуксом, то компилировать программу так же в "Eclipse+CodeSourcery"? Почти так. CodeSourcery это всего-лишь сборка GCC. Для сборки программы к линуксу у вас будет аналогичный кросс-компилятор (тоже сборка GCC). Eclipse может работать с любым GCC.
  14. ARM7 сравнение компиляторов

    Цитата(brag @ Jul 6 2012, 14:21) Тогда в случаи с next->prev=prev; prev->next=next; тоже нету явного указания компилятору, что prev может изменится. Ситуация аналогичная вроде? если next->prev == <cast...>&(prev->next) то это вероятно ошибка программиста. ... Ситуация далеко не аналогичная. Просто прямое обращение по адресу и обращение двойное обращение по адресу.
  15. ARM7 сравнение компиляторов

    Цитата(brag @ Jul 6 2012, 12:52) Тоесть компилятор всегда перегружает переменную,если ранее была лябая запись в память? Хотя вот: Код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, то это очевидная ошибка программиста.
  16. ARM7 сравнение компиляторов

    Цитата(brag @ Jul 6 2012, 11:54) &(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. Это ничего не меняет.
  17. ARM7 сравнение компиляторов

    Цитата(brag @ Jul 6 2012, 11:18) Интересно с какой? Если будет 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) ? Компилятор не может знать что это в вашем случае это не так =)
  18. ARM7 сравнение компиляторов

    Цитата(brag @ Jul 6 2012, 09:57) Ни один компилятор не смог нормально соптимизировать простые очевидные вещи.. Очевидно же: После выполнения Код    next->prev=next; Следующаяя строка кода может работать с совсем ДРУГОЙ памятью, нежели ДО выполнения предыдущей строчки. Оптимизатор просто не имеет права ничего удалять. Код    prev->next=prev; В данном случае всё указано однозначно. Кодvoid tormoz::remove(){     tormoz *n=next,*p=prev;     n->prev=p;     p->next=n; }
  19. Компилятор XScale

    Цитата(SBE @ Jul 4 2012, 11:01) .... Не назовете какие чипы попали в эти 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 - по миру идти? Свернёт Адоб свой Флеш - .... ?
  20. Компилятор XScale

    Цитата(SBE @ Jul 3 2012, 19:24) Не знаю насколько хорошо вы знакомы в WinCE, и стоит ли тут что-то обсуждать. Одно время рассматривал возможность запуска WinCE на своём изделии (тоже на XScale). Ознакомился с Platform Builder, собрал систему. На тот момент времени функционал получившейся системы оказался неконкурентоспособен. ЦитатаС драйверами и BSP проблема скорее не в их недостатке, а в их качестве. BSP для WinCE сейчас отсутствует для 90% чипов с MMU. А на чипах без MMU наверняка не работает вообще. С 2006 года никакого развития. Только в 2011 году выпустили новую версию. ИМХО последнюю. ЦитатаА скажите где с этим хорошо и задешево ? Линукс сейчас по этому критерию однозначно лидирует. Производители чипов хотят заполучить огромный рынок на 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" (Надо перевести?)
  21. AvrUsb500 by Petka. продолжение

    Цитата(bkost @ Jul 3 2012, 01:42) .... Прошил v7 из папки 14745600. .... . Подскажите, плз, где грабли? Версия 7 экспериментальная. Попробуйте проверенную временем версию 6.
  22. Компилятор XScale

    Цитата(sz36 @ Jul 2 2012, 22:39) Из того, что мне близко - охранные системы, СКУД, видеонаблюдение, видеорегистраторы (я имею в виду железки, а не сервера сбора данных). Эти применения вообще можно делать на чём угодно. Никаких достоинств WinCE тут не даёт. Это всё более менее массовые продукты. ИМХО тут операционку с более низкой ценой лучше брать. И с бОльшей гибкостью. ЦитатаИз того, что не близко, но могу предположить - медицинская аппаратура, измерительное оборудование, всякие там осцилографы и энцефалографы, и проч. Тут ситуация другая - аппаратура малотиражная и более дорогая. Её просто исторически делали на Win. Переделывать получается дороже, чем обновить на что-то более удобное/дешёвое.
  23. Компилятор XScale

    Цитата(sz36 @ Jul 2 2012, 18:48) ... Не то, что труп, но нишевый продукт. На мой вкус, для встроенных систем WinCE черезвычайно хороша, и уж всякие там андроиды ее никак не заменят. Зачем андроид? Можно и VxWorks, можно и встраиваемый Linux. Первый если хочется денег заплатить. Второй, если опыт есть и роялти не хочется платить и нужна очень большая гибкость. P.S. Кстати интересно узнать и какая же ниша у WinCE? Драйверов нету, ГУИ - устаревшее, даже подобия реального времени нету, ресурсов жрёт много, готового софта - почти нету, программистов под втраиваемую винду тоже всё меньше и меньше. Странная штука.
  24. Компилятор XScale

    Цитата(sz36 @ Jul 1 2012, 20:12) ... В общем, совершенно непонятно на чем теперь народ под ARMы под Винду пишет. ... Разве Винда под АРМ не труп?
  25. AvrUsb500 by Petka. продолжение

    Цитата(XWoo @ Jun 29 2012, 22:54) .... Заметил, что когда проводишь пальцем по ножкам меги8, то это помогает иногда успешно связаться с таргетом.. Взял другой программатор на attiny2313/at90s2313 - avr910 - и программы avrosp2 и avrprog: эта mega128l при питании 3,3В c avr910 работает без проблем. Взял снова avrusb500 и аврстудию 4 и стал подключать к другим процам (у всех питание 5В) - результаты получше, но особо не обрадовал: ошибки выскакивают иногда. .... Что могло случиться с этим программатором? Скорее всего где-то не отмыт флюс. Прошло время, дорожки/контакты окислились и появились утечки. Промойте плату с мылом и щёткой, потом спиртом/бензином и остатки спирта/бензина протрите сухой ваткой. Так-же посмотрите под лупой все ли контакты пропаяны. Если при нажатии на микросхему работоспособность устройства меняется - один из признаков непропаянных контактов.