Petka

ИМХО вывод сообщений неправильно организовывать как подцели какой-либо цели. По замыслу make, подцели необязательно вообще будут выполняться by design. Про определённый порядок выполнения зависимостей нигде никогда ничего не гарантировалось. Всё что вы просили выполнить в вашем makefile для цели all будет добросовестно выполнено. Вывод на экран сообщений был? Размер выводился? elf собирался? При любом ключе -j ? Проводя аналогии с компиляторами: сейчас уже никого не удивляет, что в ассемблерном листинге оптимизирующего компилятора фактический порядок "промежуточных" арифметических вычислений может отличатся от написанного в исходном тексте программы. Не говоря уже о выкидывании незадействованного кода. Если программист заложился на какие-то побочные свойства инструмента - это только ответственность программиста а не проблема инструмента.

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

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

Я про оптимизацию этого куска кода: if (!(--rs->fifo.tx.cnt)) В нем оптимизатор всё сделал правильно. Никаких "вольных" трактовок volatile.

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

Не суть. А что запретит прерывание по UART_RXC? Если прерывание не запрещены, то при следующем входном байте на UART будет снова вызван обработчик прерывания. вы так упорото не хотите понять, что индекс массива у вас никак не защищён от переполнения вниз. так это или не так легко проверить: поставьте проверку на индекс массива if(ADC2_RxC_counter >= ADCBUFSISE){ ERROR_LED_ON; }

Полный бред. 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 сломает память.

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

Выкладываю обновлённую версию прошивок программатора. Изменения: 1. Преобразование кода АЦП в вольты осуществляется более точно. 2. Изменена строка идентификации программатора на "STK500_2". Программатор с новой прошивкой сможет работать в последних версиях AVRStudio. AvrUSB500_by_Petka_HEX_SRC_v8_uni.zip

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

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

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

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

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

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

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

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

Все процессоры с ядрами 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 - по миру идти? Свернёт Адоб свой Флеш - .... ?

Одно время рассматривал возможность запуска 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" (Надо перевести?)

Версия 7 экспериментальная. Попробуйте проверенную временем версию 6.

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

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

Разве Винда под АРМ не труп?

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

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