Evgeny_CD, Архитектор (13.06.2008 23:20, просмотров: 273) ответил Evgeny_CD на Из обсуждения на Электрониксе ->-> продолжение http://electronix.ru/forum/index.php?s=&showtopic=49082&view=findpost&p=425651
(zltigo @ Jun 13 2008, 22:42) { . Быстро-же Вы меняете прадигмы программирования в угоду самоcотворенным кумирам . Не понял, о чем Вы? } Все происходит постепенно. Когда-то давно я освоил АSM. Помнится, даже на листочке бумаги ассеблер в коды переводил. И ничего, работало! Потом я начал осваивать С. И достаточно долго не мог понять всего, что стоит за ОСями и многопоточным программрованием. Т.е. я что-то чувствовал, но толком не понимал. В какой-то момент в голове что-то замкнуло, и я осознал классическую парадигму многопоточного программирования. Параллельно с этим я осознал много всего по синтетическим портам и виртуальной разработке. Сейчас я совершенно четко представляю, как вести разработку в родной мне коммуникационной области, полностью отвязанную от специфики конкретного железа. Причем если когда-то это было на уровне функций-ориентированного HAL (все обращение к железу только через вызовы функций драйвера), то теперь я понимаю, как такую же виртуальную разработку делать уже с асмовой эффективностью! http://electronix. …ex.php?showtopic=48931 Понятно, что за громкими словами об осознании истины стоят, в общем-то, простые вещи - но все embeded программирование состоит из очень простых вещей. Просто их ОЧЕНЬ много Теперь, вооружившись этими знаниями, я решил посмотреть назад, и понять, а как изящество многопоточного программирования втиснуть в ограниченные ресурсы. Про protothreads, switch технологию и пр. я слашал давно. И даже что-то пытался понять. Но не вышло. Не понимал я, зачем оно нужно, когда есть uCOS Зачем нам что-то там экономить, когда у нас целых 64К ОЗУ на кристалле Теперь вдруг я понял, что в этом что-то есть. И дело не только в пямяти. Но и в быстродействии. На основании всего своего опыта, я очень хорошо понимаю, что можно выжать из ATxmega256. Но толко при одном условии - что ресурсы кристалла будут расходоваться эффектвино. В решении сложной задачи есть две крайности: * поставить цель все сделать на асме и здохнуть в таком проекте * портировать какую-нибудь вирутальную машину на контроллер (Lua|Java|Pyhon|...), и целевой код написать на очень высоком уровне. Но я чувствую, что можно пройти по лезвию ножа. Сделать некую надстойку над С, которая позволяет: * быстро визуализировать "смысл кода" * композитный код Визулизировать смысл - это в графической форме представить все сущности кода * функции * блоки кода {} * машины состояний * потоки и взаимосвязь между ними. После долгих размышлений и изучения моря всяких проектов, я понял, что это не сложно, и потихоньку двигаюсь к написанию ТЗ на такой визуализатор. Что касается композитного кода - это некое обобщение С++ и идеологии обобщенного программирования. Когда код разбивается на составные части, все интерефейсы между ними четко специфицируются, а для этих составных частей пишутся разные варианты для разныз реализаций. Идею с кодогенератором для драйверов уже описал, точно также можно сделать кодогенератор для работы с ОСью (и тогда будет в значительной степени безразлично, под какую ОСь писать). Теперь осталось эффектвино научиться работать с КА - и новая высота будет взята. А ATxmega - это не кумир. Честное слово, мне безразлично, для какой платформы писать. Просто по факту xmega - хорошая плаформа для батарейных вещей.
(zltigo @ Jun 13 2008, 22:42) { . Быстро-же Вы меняете прадигмы программирования в угоду самоcотворенным кумирам . Не понял, о чем Вы? } Все происходит постепенно. Когда-то давно я освоил АSM. Помнится, даже на листочке бумаги ассеблер в коды переводил. И ничего, работало! Потом я начал осваивать С. И достаточно долго не мог понять всего, что стоит за ОСями и многопоточным программрованием. Т.е. я что-то чувствовал, но толком не понимал. В какой-то момент в голове что-то замкнуло, и я осознал классическую парадигму многопоточного программирования. Параллельно с этим я осознал много всего по синтетическим портам и виртуальной разработке. Сейчас я совершенно четко представляю, как вести разработку в родной мне коммуникационной области, полностью отвязанную от специфики конкретного железа. Причем если когда-то это было на уровне функций-ориентированного HAL (все обращение к железу только через вызовы функций драйвера), то теперь я понимаю, как такую же виртуальную разработку делать уже с асмовой эффективностью! http://electronix. …ex.php?showtopic=48931 Понятно, что за громкими словами об осознании истины стоят, в общем-то, простые вещи - но все embeded программирование состоит из очень простых вещей. Просто их ОЧЕНЬ много Теперь, вооружившись этими знаниями, я решил посмотреть назад, и понять, а как изящество многопоточного программирования втиснуть в ограниченные ресурсы. Про protothreads, switch технологию и пр. я слашал давно. И даже что-то пытался понять. Но не вышло. Не понимал я, зачем оно нужно, когда есть uCOS Зачем нам что-то там экономить, когда у нас целых 64К ОЗУ на кристалле Теперь вдруг я понял, что в этом что-то есть. И дело не только в пямяти. Но и в быстродействии. На основании всего своего опыта, я очень хорошо понимаю, что можно выжать из ATxmega256. Но толко при одном условии - что ресурсы кристалла будут расходоваться эффектвино. В решении сложной задачи есть две крайности: * поставить цель все сделать на асме и здохнуть в таком проекте * портировать какую-нибудь вирутальную машину на контроллер (Lua|Java|Pyhon|...), и целевой код написать на очень высоком уровне. Но я чувствую, что можно пройти по лезвию ножа. Сделать некую надстойку над С, которая позволяет: * быстро визуализировать "смысл кода" * композитный код Визулизировать смысл - это в графической форме представить все сущности кода * функции * блоки кода {} * машины состояний * потоки и взаимосвязь между ними. После долгих размышлений и изучения моря всяких проектов, я понял, что это не сложно, и потихоньку двигаюсь к написанию ТЗ на такой визуализатор. Что касается композитного кода - это некое обобщение С++ и идеологии обобщенного программирования. Когда код разбивается на составные части, все интерефейсы между ними четко специфицируются, а для этих составных частей пишутся разные варианты для разныз реализаций. Идею с кодогенератором для драйверов уже описал, точно также можно сделать кодогенератор для работы с ОСью (и тогда будет в значительной степени безразлично, под какую ОСь писать). Теперь осталось эффектвино научиться работать с КА - и новая высота будет взята. А ATxmega - это не кумир. Честное слово, мне безразлично, для какой платформы писать. Просто по факту xmega - хорошая плаформа для батарейных вещей.