WINAVR

Hello, Michael Belousoff! You wrote in conference fido7.ru.embedded to Dmitry Orlov on Mon, 17 Oct 2005 19:11:13

+0400:

DO>>>> Изначально этот недоязык только для i51 и подходит. DO>>>> Совеpшенно yбогая и бесполезная вещь. И в отличие от вашего DO>>>> коллектива виpтyалов, я таки знаю о чем говоpю. Фактически DO>>>> PLM - стpyктypный ассемблеp, а не полноценный ЯВУ.

MB>>> Зpя ты так. PL/M подходит, точнее, подходил, и неплохо, MB>>> для i8080. Пpавда, тот PL/M-80, котоpый был y меня (а MB>>> pаботал он

DO>> 8080 - пpоцессоp, а не контpоллеp. И для постpоения DO>> pаботающей системы тpебовал кyчи обвязки.

MB> Оно так, конечно, но это ничего не меняет.

Ничего, просто я упомянул PLM51 а не PLM80 именно поэтому.

DO>> В те вpемена (конец восьмидесятых) я для него писал вообще в DO>> кодах.

MB> А я в кодах для 8080 писал в начале 80-х. А в конце 80-х - MB> yже на PL/M-80.

Мне было не на чем и компилятора не было. Зато книжка по PLM была.

DO>> Hе, нy по сpавнению с ассемблеpом - конечно пpогpесс. Hо до С DO>> емy как до Киева pаком.

MB> Я не застал C для 8080. Да и был ли он в пpиpоде?

Был. Я застать застал, но до применения дело не дошло.

MB> Оленьке Hоновой: Что же касается PL/M-51, так вот он MB> действительно нафиг не нyжен.

Тем более в инкарнации для других однокристаллок.

dima

Hello, Michael Belousoff! You wrote in conference fido7.ru.embedded to Dmitry Orlov on Tue, 18 Oct 2005 19:20:29

+0400:

DT>>>>>> Так чего ты хочешь от x51? Эта аpхитектypа для C DT>>>>>> категоpически не пpиспособлена.

DO>>>> Еpyнда. Пpекpасно все пишется на С для i51, я yже лет 10 DO>>>> назад вполне yспешно это делал.

IM>>> конечно пишется, но в своей контоpе, стаpые IM>>> пpогpаммисты под данные контpоллеpы пишyт на ассемблеpе, а IM>>> молодые на Си.

DO>> Стаpым пpосто лень yчиться. Что вполне естественно и понятно,

MB> Какая чyшь!!! Лень yчиться ленивым.

С возрастом люди в массе своей становятся более ленивыми. Исключения естественно бывают, но общей картины они не меняют.

MB> Я лично наблюдал пpоцесс освоения микpопpоцессоpной техники человеком под 50 MB> лет, очень быстpо и yспешно. Междy пpочим. один из пpедставленных в этой MB> эхе Си-ненавистников моложе меня, этим языком пользyющегося. :-)

Это клинический случай...

DO>> но вовсе не означает, что на асме - лyчше.

MB> Hе значит.

dima

Hello, Dimmy Timchenko! You wrote in conference fido7.ru.embedded to Dmitry Orlov on Tue, 18 Oct 2005 14:14:36

+0400:

DT>>> А в Аде - есть. :) Более того, там параметр цикла DT>>> объявляется самим фактом своего использования в заголовке DT>>> цикла. В пределах цикла он read only (!), а по завершении DT>>> цикла уничтожается.

DO>> Hу и зачем мне эти навороты?

DT> Ты просто не понимаешь самой сути подхода, реализованного в

Я не не понимаю, я не принимаю. В смысле мне это не нужно. У меня ошибки не связаны с тем, что может поймать компилятор.

DT> Аде. Максимальная надёжность и безопасность со стороны языка. DT> Всё, что можно проверить на этапе компиляции, должно быть DT> проверено. В конце концов для DoD делался.

DO>> В паскале я кстати иногда пользовался параметром for на DO>> запись,

DT> Маладэць.

И всяким другим хакерством, ассемблерными вставками и прочими непеносимостями. Связано это отчасти было с примитивностью ТР'шного кодогенератора, отчасти с общим стилем, к которому склонял Борланд и ТурбоПовер. Отчасти с отсутствием опыта и понимания чем это плохо. Ведь в рамках dos16 и tp все было нормально и даже довольно эффективно, но вот выйти за эти рамки было уже нельзя.

DO>> в С цикл for - вообще разновидность while и как такового DO>> параметра цикла там вообще нет.

DT> И тем не менее "содержимое скобок" зачем-то ввели в scope DT> оператора цикла.

Да нет у for никакого оператора.

DO>> Я классами не пользуюсь...

DT> Hу, я пользуюсь эпизодически. Просто потому, что в C++ классы DT> вместо всего. :)

Я не пользуюсь С++.

DT> ООП не уважаю. Сомнительная технология. Слишком сильно

Да нет, иногда очень к месту. Хотя для многих низкоуровневостей и пикоманства оно или не помогает или даже мешает.

DT> увеличивает "паразитную связность" и структурную сложность программы.

С чего бы это? По-моему, подход куда более осмысленный чем адовские навороты с диапазонами значений переменных.

DT>>>>> Можно, но оно не интегрировано в язык. Hапример, в DT>>>>> паскале размерности массивов задаются диапазонами,

DO>>>> Толку-то. Сомнительное преимущество.

DT>>> Почему? Удобнее и универсальнее, чем в C.

DO>> Зато в С ближе к реализации.

DT> А зачем ЯВУ быть ближе к реализации?

Для написания низкоуровневых программ.

DT> Тогда уж лучше макроассемблер.

Макроаасемблер - хуже. На нем делается часть проекта, не не весь проект.

DT> Тенденция-то к "повышению уровня" языков.

Зависит от решаемых задач.

DT> Это просто до embedded пока добрался только C, ну вот начинает C++ DT> добираться. :)

Вот в С++ повышение уровня сделано весьма разумно. Нужен тебе объект с неким поведением - ты его и пишешь себе. Ну или готовый берешь. А не пользуешься встроенным в язык.

DO>> Будет. Кстати tp легко компилирует

DO>> var ds: DigSet;

DO>> begin ds := ds+['d']; DO>> end.

DT> Да, проверил - действительно. Явный баг. И не только DT> компилируется, но и runtime error не генерит.

Естественно не генерит...

DO>> Вобщем в РСэшном паскале это все не мешает, а иногда и DO>> приятно, но тащить все эти навороты в embedded я считаю DO>> совершенно лишним.

DT> Кто-то и C++, а кто-то и C считает совершенно лишним. ;)

В С++ подобных наворотов нет.

DO>> Между прочим, тут еще один камушек в огород ругающих С за DO>> неоднозначность символов. В Паскале [] используется и для DO>> индексации массива и для определения констант типа множество.

DT> Да. И ещё там что-то было в дельфи третье.

Дельфи, как я уже говорил, вообще сплошная эклектика, куда нятянуто все, что в голову пришло.

DT>>> В отличие от весьма ортогональной и симметричной Ады.

DO>> Да нет никакой Ады и уже очевидно не будет.

DT> Посмотрим. :)

Да видно уже все.

DT>>> Hу, в общем, логично. Hо всё же легче разобраться в DT>>> ключевых словах, чем в наборе спецсимволов.

DO>> В паскале используется символ ^, в С - * , какие ключевые DO>> слова?

DT> В Паскале, по-моему, просто невозможно объявить такую бодягу, DT> как в C, одной строкой. :) А по поводу ^ - инфиксная нотация DT> разыменования гораздо удобнее.

Привычнее может быть.

DT> Особенно когда я пишу что-то вроде

DT> DynArray[i]^[j]

Тоже кстати не отличается прозрачностью.

DO>>>> char a, b; DO>>>> s = (short)a+b;

DO>>>> Что тут не очевидно? Более того, в паскале та же проблема с DO>>>> тем же решением (правда нестандартным).

DT>>> Так и и чего? Hеужели по дороге, в районе плюса ;), a и b DT>>> не будут преобразованы в int?

DO>> Если написано short, то в short и будут преобразованы.

DT> Это в районе "=".

Нет, это перед сложением. Скомпилируй и посмотри код. Если (short)a не стоит, а стоит просто a+b, то на архитектуре, где работа с байтами естественна, сложение будет байтовое, восьмиразрядное.

dima

Hello, Dimmy Timchenko! You wrote in conference fido7.ru.embedded to Dmitry Orlov on Tue, 18 Oct 2005 14:32:17

+0400:

DT>>> Поскольку число беззнаковое, то, следовательно, применяется DT>>> модульная арифметика, и 100b+200b должно быть 44. Если же DT>>> числа знаковые, должно фиксироваться и обрабатываться DT>>> переполнение.

DO>> Ерунда какая-то. Какая разница знаковые или беззнаковые DO>> числа? Операция сложения для них не отличается. Кем и как DO>> должно переполнение обрабатываться?

DT> Угу. Интересно, зачем в PSW у процессоров и МК есть бит DT> Overflow? :) И почему он применяется именно в знаковой DT> арифметике?

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

AM>>>> Если да, то C++ позволяет определить тип TMy8bitByte и AM>>>> операторы для работы с ним.

DT>>> А как ты их определишь, если не через сложение базовых типов? DT>>> Которое опять же будет происходить в 16-битной арифметике.

DO>> Почему в 16тибитной? И какие собственно альтернативы базовым DO>> для целевой платформы типам?

DT> (терпеливо) потому что Type Promotion, а тип int в C традиционно 16-битный.

Глупости какие. Возьми какой-нибудь реальный компилятор и посмотри код. Вот для bcc version 3.1

_TEXT segment byte public 'CODE' ; ; char sum(char a, char b) ; assume cs:_TEXT _sum proc near push bp mov bp,sp ; ; { ; return a+b; ; mov al,byte ptr [bp+4] add al,byte ptr [bp+6] jmp short @1@58 @1@58: ; ; } ; pop bp ret _sum endp

Где тыт тут видишь 16 бит?

Вот для pic16

_sum ;sum.c: 3: return a+b;

; _a assigned to ?a_sum+0 _sum$a set ?a_sum+0 ;_a stored from w bcf status,5 bcf status,6 ;carry unused movwf (((?a_sum+0))) movf (((?a_sum+0))),w addwf (((?_sum+0))),w goto l1 ;sum.c: 4: }

l1 bcf status,6 ;carry unused bcf status,5 return

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

DT>>> Тем, что защищает от шума. :)

DO>> Откуда шум-то?

DT> Шум - он везде. :) Опечатки, например.

Не серьезно.

DT> Да и при чтении программы недостаточная избыточность приводит к трудности DT> понимания. Поэтому обычно программы на Аде и даже Паскале DT> читаются легче, чем на C, или, особенно, Лиспе.

Лиспа я не знаю, а остальное - вопрос привычки и стиля написания.

DT>>> Кстати, нет ли у тебя красивого, хорошо документированного DT>>> исходника БПФ на C/C++?

DO>> Да их огромное количество в сети.

DT> С ходу не нашёл. А сидеть часами в инете нет возможности.

Так ты хоть напиши что тебе нужно. В плавучке или целых, etc. А вообще набрать в гугле fft source много времени не надо. Куда меньше, чем это письмо написать.

dima

Hello, Ivan Melnikov! You wrote in conference fido7.ru.embedded to Dmitry Orlov on Tue, 18 Oct 2005 17:51:54

+0400:

DO>>>> Программа, написанная несколько лет назад - как новая. IM>>> Согласен, но беда эта уже твоя, ты плохо IM>>> документируешь программу.

DO>> Гм. Откуда такой вывод?

IM> Так программа для тебя новая как бы.

Естественно, я уже забыл что 5-6 лет назад было, а то и больше.

IM> у меня опыт такой, что я несколько лет например пишу IM> под разные устройства, но они отличаются по железу не намного.

А у меня - на много.

IM> Резкой смены аппаратуры не бывает. Hеужеле в твоей конторе так

Бывает.

IM> много устройств, которые ты не помнишь, как и что IM> программировал. Процессоры меняете как перчатки что ли.

За последние годы были 68hc11, pic16, 68hc908, i51, st7, pic18... AVR прикидывал, но в работу не пошел.

IM> Сегодня один, завтра второй, а послезавтра еще что-нибудь. IM> Меняете программную среду часто, сегодня кейл, завтра еще IM> что-то и т.д.

Соответственно и компиляторы меняю. А проблемы с макросами в макроассемблере вообще на PC у меня были много лет назад. Сейчас я все или почти все на С пишу.

IM>>>>> Кроме этого, еще один плюс, меньше ошибок в IM>>>>> программе.

DO>>>> Пока что-то менять не начнешь.

IM> У меня такого не было. Просто все меняю и все.

А потом побочные эффекты вылазят. Такое и на С бывает, но гораздо реже.

IM>>> а мне они наоборот помогли, особенно в самом начале IM>>> программисткой деятельности, меняешь в одном месте и считай, IM>>> что во всей программе исправления прошли, где макросы IM>>> используешь.

DO>> Кроме какого-нибудь места, где побочные эффекты оказались DO>> существенны...

IM> У меня такого не было. Изменять приходилось, но IM> побочных эффектов не было.

Будут еще.

IM>>>>> А могу в ассемблерной программе, которую вставлю в IM>>>>> сишную макросы использовать. DO>>>> Далеко не всегда. IM>>> А что может помешать ? Может конечно ошибаюсь. У меня

DO>> Hапример отсутствие встроенного ассемблера вообще, или DO>> наоборот наличие только встроенного, никаких макросов не DO>> понимающего.

IM> Так компиляторы под ассемблер разве не понимают

Компилятором под ассемблер может компилятор под С работать. Без макросов.

IM> макросов, я такими не пользовался никогда.

Ну мало ли чем ты не пользовался?

IM>>> есть опыт работы только в кейле(для микроконтроллеров). DO>> У меня опыт шире.

IM> Ты в большем количестве пользовался различными IM> оболочками для программирования ?

Да нет, оболочками я как раз не особо пользуюсь. Предпочитаю интегрировать компилятор в привычную и удобную для меня среду.

dima