Jump to content

    

Petka

Свой
  • Content Count

    1438
  • Joined

  • Last visited

Everything posted by Petka


  1. ИМХО вывод сообщений неправильно организовывать как подцели какой-либо цели. По замыслу make, подцели необязательно вообще будут выполняться by design. Про определённый порядок выполнения зависимостей нигде никогда ничего не гарантировалось. Всё что вы просили выполнить в вашем makefile для цели all будет добросовестно выполнено. Вывод на экран сообщений был? Размер выводился? elf собирался? При любом ключе -j ? Проводя аналогии с компиляторами: сейчас уже никого не удивляет, что в ассемблерном листинге оптимизирующего компилятора фактический порядок "промежуточных" арифметических вычислений может отличатся от написанного в исходном тексте программы. Не говоря уже о выкидывании незадействованного кода. Если программист заложился на какие-то побочные свойства инструмента - это только ответственность программиста а не проблема инструмента.
  2. Это не причина НЕ исправлять такие makefile. Раньше и в компиляторах не было volatile. Но это не причина НЕ исправлять старый код.
  3. Банальная безграмотность создателей таких make файлов.
  4. Я про оптимизацию этого куска кода: if (!(--rs->fifo.tx.cnt)) В нем оптимизатор всё сделал правильно. Никаких "вольных" трактовок volatile.
  5. В той оптимизации ТОЧНО всё нормально. Далее:
  6. Не суть. А что запретит прерывание по UART_RXC? Если прерывание не запрещены, то при следующем входном байте на UART будет снова вызван обработчик прерывания. вы так упорото не хотите понять, что индекс массива у вас никак не защищён от переполнения вниз. так это или не так легко проверить: поставьте проверку на индекс массива if(ADC2_RxC_counter >= ADCBUFSISE){ ERROR_LED_ON; }
  7. Полный бред. 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. Па факту аппаратный таймер вызывался только с частотой, заданной при сборке ядра (в моём случае 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. Почти так. CodeSourcery это всего-лишь сборка GCC. Для сборки программы к линуксу у вас будет аналогичный кросс-компилятор (тоже сборка GCC). Eclipse может работать с любым GCC.
  13. Ситуация далеко не аналогичная. Просто прямое обращение по адресу и обращение двойное обращение по адресу.
  14. Тут компилятор волен оптимизировать. т.к. char b не обьявлен как volatile т.е. нет указания компилятору что содержимое b может измениться. Поэтому если с указывает на b, то это очевидная ошибка программиста.
  15. Это программистом в явном виде так присвоено не может быть. А через приведение типов может быть как угодно. Тут другой случай. v всегда указывает на одну и ту же ячейку памяти и запись в t ничего не может изменить. v может указывать куда угодно, хоть на t. Это ничего не меняет.
  16. А если 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. Компилятор XScale

    Все процессоры с ядрами PowerPC, SPARC, MicroBlaze, Motorola 68000, M32R (Renesas), TMS320C6x. Это я ещё всякую экзотику не брал типа вымерших AVR32. Вон на выставке своими глазами видел работающий linux на CortexM4 от Freescale. Время загрузки - около секунды. И крутится демка на QT. Памяти там тоже было совсем мало. WinCE так сможет? Шарп - да. Однако отсутствие вменяемых инструментов для каких либо платформ кроме как от микрософт приводит к зависимости и опять таки к отсутствию выбора. ИМХО на шарп лучше не закладываться. У Явы, QT, GTK лучше. HTML5 может стать одним из фаворитов в ближайшем будущем. (Посмотрим как всякие ChromeOS, FirefoxOS и WebOS поведут себя на рынке). На Линуксе можно запустить практически всё: QT, java, GTK. Даже .NET и GDI. Flash - тоже умирает. Адоб в скором времени перестанет его поддерживать развивать в угоду HTML5. Такие дела =) Согласен, в эмбеддед приходится долго играть. Для этого надо иметь максимальную независимость от прихотей какой-либо одной компании. Свернёт МС эмбеддед - по миру идти? Свернул Атмел AVR32 - по миру идти? Свернёт Адоб свой Флеш - .... ?
  19. Компилятор XScale

    Одно время рассматривал возможность запуска WinCE на своём изделии (тоже на XScale). Ознакомился с Platform Builder, собрал систему. На тот момент времени функционал получившейся системы оказался неконкурентоспособен. BSP для WinCE сейчас отсутствует для 90% чипов с MMU. А на чипах без MMU наверняка не работает вообще. С 2006 года никакого развития. Только в 2011 году выпустили новую версию. ИМХО последнюю. Линукс сейчас по этому критерию однозначно лидирует. Производители чипов хотят заполучить огромный рынок на Andriod. Есть ли какие-нибудь результаты тестирования? Или это предположение? Программисты под win32 тоже скоро станут редкими. Основной трэнд - ява. На этой платформе пишет огромное количество взаимозаменяемых программистов "высокого уровня". И не за дорого. Это и есть жуткое старьё. Делать на "этом" удобный пользовательский интерфейс долго без использования каких - либо тулкитов. А любой вменяемый тулкит может работать практически на любой платформе. По секрету скажу, что Микрософт решила похоронить сильверлайт как не оправдавший себя проект. 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. Версия 7 экспериментальная. Попробуйте проверенную временем версию 6.
  21. Компилятор XScale

    Эти применения вообще можно делать на чём угодно. Никаких достоинств WinCE тут не даёт. Это всё более менее массовые продукты. ИМХО тут операционку с более низкой ценой лучше брать. И с бОльшей гибкостью. Тут ситуация другая - аппаратура малотиражная и более дорогая. Её просто исторически делали на Win. Переделывать получается дороже, чем обновить на что-то более удобное/дешёвое.
  22. Компилятор XScale

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

    Разве Винда под АРМ не труп?
  24. Скорее всего где-то не отмыт флюс. Прошло время, дорожки/контакты окислились и появились утечки. Промойте плату с мылом и щёткой, потом спиртом/бензином и остатки спирта/бензина протрите сухой ваткой. Так-же посмотрите под лупой все ли контакты пропаяны. Если при нажатии на микросхему работоспособность устройства меняется - один из признаков непропаянных контактов.
  25. Интересно что ни один из участников и "авторитетов", отметившихся в этой теме не уточнил какую из основных топологий построения источников питания тут обсуждают. Обратноходовую, прямоходовую, двухтактную, мостовую и т.д. ИМХО обратноходовые преобразователи гораздо проще строить на МК общего применеия, нежели чем мостовые.