Oberon space
General Category => Общий раздел => Тема начата: valexey от Июль 03, 2012, 12:51:26 pm
-
На хабре появилась статейка о проблемах при программировании AVR'ок: http://habrahabr.ru/post/147025/
По нашему опыту могу скзать что примерно то же самое (хотя и не столь масштабно) касается и любых других микроконтроллеров (msp430, 8051 и так далее) - средства разработки там отстают от десктопных/серверных систем примерно лет на 20-30-40. Там не соблюдаются стандарты, там у каждой среды разработки свой диалект языка (например диалект Си), там не работает отладчик (а логи естественно вести нельзя, ибо некуда), точнее часто работает не так (показывает например что переменная как была нулем, так и осталась, но при этом на самом деле переменная поменялась). Да, и средства разработки там стоят каких-то жутких денег (за такое то убожество). Какой-нибудь IAR стоит больше тысячи баксов в не самой богатой комплектации (при этом он вполне глючный, требующий хардверного ключа для запуска и конфликтующий с другими официально купленными версиями этого же IAR'a (например для другого микроконтроллера)). Код естественно пишется не переносимый.
-
И какие оргвыводы?
-
И какие оргвыводы?
Орг выводы следующие: если кто-то предложит решение этих (или части) проблем, то он зохавает львиную долю рынка. Как например случилось с turbo pascal и c delphi в свое время. И как случилось сейчас с Arduino, хотя оно и не позволяет полноценно программировать микроконтроллеры (если нужно полноценно, то выкидываем ардуинов недоСи с гламурной средой разработкой, ставим суровый AVR Studio, берем человеческий дебагер (дивайс такой) и имеем тот же секс, что и с любой другой платой на AVR (ибо ардуина она на 8ми битном AVR сделано).
PS. AVR'ки славятся во-первых своей дороговизной (8 битка стоит дороже чем какой-нибудь микроконтроллер с ядром арма (32 бита)) а также тем, что оно не фоннеймовское (впрочем, как и PIC какой-нибудь). Ну и AVR закрыты по своей архитектуре по самое немогу. Их производит ровно одна контора.
-
Да, и средства разработки там стоят каких-то жутких денег (за такое то убожество). Какой-нибудь IAR стоит больше тысячи баксов в не самой богатой комплектации (при этом он вполне глючный, требующий хардверного ключа для запуска и конфликтующий с другими официально купленными версиями этого же IAR'a (например для другого микроконтроллера)). Код естественно пишется не переносимый.
Так есть же и бесплатные компиляторы.
А среда -- зачем она? Простой редактор типа того же Сублиме для микроконтроллеров уже оверкилл...
-
Да, и средства разработки там стоят каких-то жутких денег (за такое то убожество). Какой-нибудь IAR стоит больше тысячи баксов в не самой богатой комплектации (при этом он вполне глючный, требующий хардверного ключа для запуска и конфликтующий с другими официально купленными версиями этого же IAR'a (например для другого микроконтроллера)). Код естественно пишется не переносимый.
Так есть же и бесплатные компиляторы.
А среда -- зачем она? Простой редактор типа того же Сублиме для микроконтроллеров уже оверкилл...
А где есть качественные бесплатные компиляторы скажем под msp430? gcc не предлагать.
Редактор кода во всех этих средах и так простой - не то что автокомплита, там подсветки синтаксиса нет :-) Но вот средства отладки жизненно важны (вне зависимости от того насколько аккуратно ты пишешь код).
Кроме отладчика и компилятора в этих средах есть например прошивальщик, и до кучи "компоновщик", что тоже не тривиальная штука. Также обязательно нужно иметь дизасм. Просмотрщик прошивки по адресам и так далее.
-
Компиляторы под микрокотроллеры реально убоги. Приходится полностью отключать оптимизацию компилятора, иначе в некоторых случаях лезут невнятные ошибки, в которых разобраться решительно не возможно.
-
А вот такой замечательный баг в IAR имеется (недавно обнародован):
EW22876 - 16-bit equal operations could fail if the low byte had value zero.
-
Поздравляю с приехавшими няшками. Они на msp430?
Для этих контроллерв вообще есть какие-нить эмуляторы? А то с железкой лень возиться )))
-
(про приехавшие няшки отвечу как только будет время на внятный пост)
Продолжаю тему: народ пишущий под микроконтроллеры очень часто не является профессиональными программистами. То есть по сути это специалисты в плане схем и радиотехники, но не супер-спецы в CS и промышленной разработки софта. Есть также те, кто до этого не программировал вообще. Также есть люди которые знают ассемблер, а языки высокого уровня не знают, и для них это слишком сложно.
Часто для написания алгоритмов используют всякие вспомогательные тулзы которые помогают не лезть в странные Cи. Например есть Алгоритм Билдер (http://algrom.net/russian.html), который позволяет реализовать алгоритм в графическом виде. И этот билдер пользуется определенным спросом.
Поэтому похоже что действительно там мог бы прижиться Оберон (если получится решить в нем ряд проблем, доопределить его для данного применения), ибо Си слишком сложен и провоцрует на невнятный низкоуровневый код, а С++ еще более сложен, и для того чтобы написать на нем эффективный код нужно его хорошо знать, а они его не знают (C++ там применим в случае если человек под МК пишет имея хороший опыт разработки на больших системах, типа десктопа/смартфона/сервера). Ну и какой-нибудь Дракон.
PS. Просьба к Владу Жаринову: если хочется порассуждать по теме (достаточно пространно), то лучше завести тему отдельную для этого, тут я стараюсь просто выложить свои наблюдения, в сконцентрированном, так сказать, виде. Если же есть вопрос по теме, который можно сформулировать кратко - то можно задать здесь.
-
Valexey, а вас-то какая проблема волнует?
1. Самому нужен эффективный инструмент.
2. Хочу осчастливить тех, кто ни х... людей которые знают ассемблер, а языки высокого уровня не знают, и для них это слишком сложно.
3. Хочу использовать Оберон, независимо ни от чего.
4. Недостающее добавить.
-
Valexey, а вас-то какая проблема волнует?
1. Самому нужен эффективный инструмент.
2. Хочу осчастливить тех, кто ни х... людей которые знают ассемблер, а языки высокого уровня не знают, и для них это слишком сложно.
3. Хочу использовать Оберон, независимо ни от чего.
4. Недостающее добавить.
4 с примесью остальных.
Во-первых я вижу что такое программирование под микроконтроллеры, у нас в проекте же это используется, хотя этим занимаюсь и не я. Собственно я вижу что там проблем возникает больше не в последнюю очередь из за инструментария и того как там привыкли писать. Так что я в общем то заинтересован в окультуривании подхода к программированию под МК.
Во-вторых я хорошо понимаю, что даже если у меня (точнее у нас) прямо вот сейчас появится ах какой инструмент, погоды это не сделает - программирование штука все же коллективная и чужой код используется даже тут. Поэтому если хочется осчастливить себя, то нужно осчастливить и сообщество. (кроме того мне любопытно как оное сообщество отреагирует на такое).
На Обероне я не прям таки горю желанием писать, но это самый разумный выбор с чего начать (под него проще построить инструмент, народ его быстрее освоит).
Ну, и пожалуй главная причина: мне интересно :-) Программирование под МК дает то, чего мы лишились когда ушел DOS - возможность контролировать до мелких частностей систему целиком. Понимать полностью как оно устроено. Никаких фреймворков, никих операционок. Нет там этих наслоений исторических. Это хороший шанс понять и прочувствовать всю близкую к железу часть, весь фундамент на котором оси строятся. Также мне интересно попробовать построить инструментарий. Кроме того, я вижу в этом большой потенциал для обучения. Это ж просто здорово когда вся память помещается на одном экране компьютера. Можно наглядно показать что куда и как.
Поэтому я себе заказал домой на поиграться набор от Texas Instruments (за 4.3$ с доставкой) и вот потихоньку ковыряю на досуге:
https://plus.google.com/114633421665967893098/posts/KkWSVhgKBai
https://plus.google.com/114633421665967893098/posts/WacSbHE4kes
https://plus.google.com/114633421665967893098/posts/8WYRig57Ca4
https://plus.google.com/114633421665967893098/posts/QXrRKQNpM4F
https://plus.google.com/114633421665967893098/posts/EMiZhnMheMn
https://plus.google.com/114633421665967893098/posts/dU7JaPxMJqE
https://plus.google.com/114633421665967893098/posts/5BGhvsfuaAK
-
...
PS. Просьба к Владу Жаринову: если хочется порассуждать по теме (достаточно пространно), то лучше завести тему отдельную для этого, тут я стараюсь просто выложить свои наблюдения, в сконцентрированном, так сказать, виде. Если же есть вопрос по теме, который можно сформулировать кратко - то можно задать здесь.
Да не вопрос... :) Есть концентрированно насчёт этого:
...
Поэтому похоже что действительно там мог бы прижиться Оберон (если получится решить в нем ряд проблем, доопределить его для данного применения), ибо Си слишком сложен и провоцрует на невнятный низкоуровневый код, а С++ еще более сложен, и для того чтобы написать на нем эффективный код нужно его хорошо знать, а они его не знают (C++ там применим в случае если человек под МК пишет имея хороший опыт разработки на больших системах, типа десктопа/смартфона/сервера). Ну и какой-нибудь Дракон.
...
- не вопрос даже, а подтверждение - эта среда (http://forum.easyelectronics.ru/viewtopic.php?f=13&t=11437&sid=04def9da8a5520940ef0e1e080ba7059), где как раз реализованы Паскалевские языки с шампур-блок-схемным представлением. Про саму среду, наверное, тут знают - но на этом форуме прослеживается интерес к таким решениям... и как бы критика Оберона как текстового языка разработки отсутствует... так что почему бы ему и не прижиться?.. :)
Насчёт вопроса даже и не знаю... разве что - как Вы или ещё кто-то оценит среду и предложенные там направления развития?.. В смысле темы, конечно - т.е., как я понимаю, продвижения Оберона в программирование для МК? Kori тут молодец, что постарался и описать, что ему надо от среды, как разработчику, и обрисовать (на макете СИВУХА-ГУЯ :) )...
Кстати, Дмитрий_ВБ пришёл к этому тоже от Алгоритм Бидера... наглядность схем в котором ему не понравилась (он не развивал - но есть определённое понимание, почему)... но это уже тема для другой ветки... и не знаю, будет ли интересно...
-
На Обероне я не прям таки горю желанием писать, но это самый разумный выбор с чего начать (под него проще построить инструмент, народ его быстрее освоит).
У меня есть основания полагать, что Оберон вызовет отторжение.
Поясню на примере. Люди, пишущие на ассемблере никогда не будут обнулять область памяти так:
i:=0;
WHILE i <> Len DO
M[i] := 0;
i:=i+1;
END;
Они всегда будут делать это в таком стиле:
i:=Len;
P:=&M;
WHILE i-- <> 0 DO
*P++ := 0;
END;
Поэтому, если вы будете писать первое, имея в виду второе, то всегда будете врать. И кончится это плохо.
Здесь нужен только Си-образный язык.
-
На Обероне я не прям таки горю желанием писать, но это самый разумный выбор с чего начать (под него проще построить инструмент, народ его быстрее освоит).
У меня есть основания полагать, что Оберон вызовет отторжение.
Поясню на примере. Люди, пишущие на ассемблере никогда не будут обнулять область памяти так:
...
Здесь нужен только Си-образный язык.
Неубедительно. Не вижу причин для ассемблерщика подняться над уровнем сей.
Оберон сомнителен по другой причине -- есть же паскаль, который на два порядка более известен, чем оберон. Так зачем нужен оберон, если по факту реальных преимуществ у него нет?
-
Поэтому, если вы будете писать первое, имея в виду второе, то всегда будете врать. И кончится это плохо.
Вообще я не вижу принципиальной разницы между этими двумя вариантами. Почему от первого варианта могут быть проблемы, а от второго нет? Скорее уж наоборот -- первый вариант безопаснее из-за отсутствия ненужной в данном случае адресной арифметики.
так что первый вариант для меня предпочтительнее, и плевать, какой из этих вариантов ближе к ассемблеру.
-
"Для меня предпочтительнее" - не показатель. Вы с ассемблерными людЯми пообщайтесь.
-
А что говорить с этими пещерными людьми? Их учить современным языкам надо, а не подстраиваться под их корявые привычки...
-
На Обероне я не прям таки горю желанием писать, но это самый разумный выбор с чего начать (под него проще построить инструмент, народ его быстрее освоит).
У меня есть основания полагать, что Оберон вызовет отторжение.
Поясню на примере. Люди, пишущие на ассемблере никогда не будут обнулять область памяти так:
i:=0;
WHILE i <> Len DO
M[i] := 0;
i:=i+1;
END;
Они всегда будут делать это в таком стиле:
i:=Len;
P:=&M;
WHILE i-- <> 0 DO
*P++ := 0;
END;
И будут не правы :-) Второй вариант будет работать так же, либо медленней на рассматриваемом типе процессоров. Если кто-то знает и умеет программировать на асме под x86 это еще не значит что он умеет программировать под msp430.
А вот
int sum;
int array[256];
for (int i=0; i<len; i++) sum = sum+array[i];
Будет работаеть действительно медленней чем:
int* p = array;
for (int i=0; i<len; i++) sum = sum + *(p++);
Но, повторюсь, конкретно на msp430. И грамотный ассемблерист/микроконтроллерщик это понимает. Поэтому если ему понадобится обнулить область памяти он не будет писать циклы, он напишет memset.
Либо, если компилятор оптимизирующий, то он распознает паттерн и в обоих случаях будет сгенерирован один и тот же код (для любых архитектур будет сгенерирован код оптимальный в обоих случаях).
Здесь нужен только Си-образный язык.
Если использовать Си-образный язык то это тоже кончится плохо (если компилятор не оптимизирующий) :-)
-
А что говорить с этими пещерными людьми? Их учить современным языкам надо, а не подстраиваться под их корявые привычки...
Ты все же зря так. Знание асма/машкодов при программировании МК как минимум очень полезно. Кроме того, иногда только на асме и можно что-то сделать, либо просто это получится сделать быстрее. Есть и такие задачи.
-
Ты все же зря так. Знание асма/машкодов при программировании МК как минимум очень полезно. Кроме того, иногда только на асме и можно что-то сделать, либо просто это получится сделать быстрее. Есть и такие задачи.
Так я же и не говорю, что надо выбить из них знание ассемблера. Просто не надо подстраиваться под них, если есть более правильные пути.
А так я до сих пор помню, как в одной моей мелкоконтроллерной проге не хватало полмикросекунды (1 машинный цикл у 51 процессора) -- пришлось обработчик прерывания с сей на ассемблер переписывать...
-
Вот тут: http://habrahabr.ru/post/151587/ народ сравнивает качество сгенерированного кода разными компиляторами под AVR.
Самое смешное что автор статьи называет Wiring компилятором :-) Также он похоже не в курсе, что в Wiring по умолчанию gcc зовется с опцией -Os, то есть оно пытается сгенерить как можно более компактный код, пусть даже в ущерб производительности, отсюда и фрагментация тел функций (подозреваю что автор статьи не подозревает вообще о наличии у компиляторов опций).
То есть относительно десктопно-серверных программистов микроконтроллерщики довольно слабо таки ориентируются в современных ЯВУ и инструментарии. Они ближе к предметникам-непрограммистам (аля физики-химики) нежели к программистам-профессионалам.
PS. BASCOM-AVR - это Basic для микроконтроллеров. Весьма, как видим, эффективен. Вот тут про него была еще статья: http://habrahabr.ru/post/151544/
-
Не стал заводить новую тему.
Никлаус Вирт: искусство преподавания http://www.osp.ru/os/2012/06/13017106/