Школа Молодого Бойца

[wowa]

Давайте больше небудем об этом.. Эту религию выясняйте в ПМ. Позже тему почищю... Результат такой: НАДО ИЗУЧИТЬ СНАЧАЛА АСЕМБЛЕР ДЛЯ ДЕТАЛЬНОГО ПОНЯТИЯ ВНУТРЕННОСТЕЙ КАМНЯ И РАБОТЫ С НИМ. А когда начнёт напрягать писание в АСМ - ИЗУЧИТЬ С.

[Реклама]

Реклама: ООО ТД Промэлектроника, ИНН: 6659197470, Тел: 8 (800) 1000-321

[Goodefine]

...Результат такой: НАДО ИЗУЧИТЬ СНАЧАЛА АСЕМБЛЕР ДЛЯ...

Это откуда такой результат?...

[Реклама]

20% скидка на весь каталог электронных компонентов в ТМ Электроникс!

Акция "Лето ближе - цены ниже", успей сделать выгодные покупки!

Плюс весь апрель действует скидка 10% по промокоду APREL24 + 15% кэшбэк и бесплатная доставка!

Перейти на страницу акции

Реклама: ООО ТМ ЭЛЕКТРОНИКС, ИНН: 7806548420, info@tmelectronics.ru, +7(812)4094849

[wowa]

Элементарно - в даташите все примеры на АСМ. Хотя в новых уже есть и на С. И вообще - пусть лучше изучают АСМ. На С сами перейдут. Если не перейдут - то заставят. Покрайней мере будут иметь понятие о внутреностях МК и о работе с ними.

[Реклама]

Выбираем схему BMS для корректной работы литий-железофосфатных (LiFePO4) аккумуляторов

 Обязательным условием долгой и стабильной работы Li-FePO4-аккумуляторов, в том числе и производства EVE Energy, является применение специализированных BMS-микросхем. Литий-железофосфатные АКБ отличаются такими характеристиками, как высокая многократность циклов заряда-разряда, безопасность, возможность быстрой зарядки, устойчивость к буферному режиму работы и приемлемая стоимость. Но для этих АКБ, также как и для других, очень важен контроль процесса заряда и разряда, а специализированных микросхем для этого вида аккумуляторов не так много. Инженеры КОМПЭЛ подготовили список имеющихся микросхем и возможных решений от разных производителей. Подробнее>>

Реклама: АО КОМПЭЛ, ИНН: 7713005406, ОГРН: 1027700032161

[mazzi]

Тема переросла в религиозную перепалку.

Скажу от себя. Писал я раньше на ассемблере. При этом мне не нравился очень большой текст программы, и много проблемм со сложными алгоритмами. Когда перешёл на Си, производительность выросла в десятки раз, отладка упростилась. Сейчас в ассемблер ныряю изредка и только в сложных случаях во время отладки программы. За последние 10 лет на ассемблере писал не более 5-раз, это были те редкие случаи, когда ресурсов для Сишной программы не хватало, а поменять платформу не было возможности.

Рассматривая свои теперешние программы более 10000 строк на Си, я думаю, что на ассемблере такое написать и отладить, к тому же уложиться в жёсткие сроки разработки просто невозможно.

Знание ассемблера безусловно нужно, но писать нужно на Си.

Ратующие за использование только ассемблера напоминают мне известных мультяшных персонажей которые отрицали преимущество крыльев перед ногами.

[Alexeyslav]

10000 строк кода не назовешь маленьким проэктом, да и жесткие сроки ставят нелегкие рамки выбора языка.

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

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

[Геннадий]

Никто не ратует за использование только ассемблера. Тема не та. Есть рекомендации начать изучение с ассемблера, который поможет изучить сам МК, получить навык работы с камнем на низком уровне и научиться управлять периферией. В этом мнении мы с wowa сошлись. Именно ассемблер поможет научиться держать в уме сложные алгоритмы и при этом не путаться в них. Не сразу конечно, опыт приходит со временем, при определенных умственных упражнениях. А как же без них?

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

[Tesla]

Господа! Почему-то никто до сих пор не обратил внимание (UPD: а, нет, прошу прощения - обратили) на то, что программирование микроконтроллеров - занятие довольно специфическое, и предполагает две вещи. Первая - хорошее знание программирования вообще (умение писать (и читать!) сложные алгоритмы), и вторая - хорошее знание железа микроконтроллера. Научиться первой вещи, программируя только на ассемблере, невозможно - думаю, никто с этим спорить не будет. Очень желательно, чтобы у человека, впервые сталкивающегося с микроконтроллерами, этот опыт уже был. А со второй трудновато освоится, как раз не пользуясь ассемблером.

Язык си - это определённый уровень абстракции. Он пытается скрыть, чтобы не засорять внимание программиста, многие "несущественные" вещи. Однако, эти вещи в некоторых ситуациях могут стать как раз очень существенными. Например, совсем не очевидно то, что для AVR строка PORTD |= 0x08 сгенерит одну инструкцию ассемблера, а PORTD |= 0x07 - три (строго говоря, это ещё зависит от уровня оптимизации). Или то, что при записи в 16-разрядный регистр сначала пишется старший байт. Иногда надёжность программы зависит от осведомлённости программиста о подобных вещах. Очень часто в подобных местах приходится запускать симулятор, и в пошаговом режиме смотреть, всё ли происходит так, как планировалось.

Так что я считаю, что холивар здесь не уместен. Программист микроконтроллеров обязательно должен знать и си (алгоритмы), и ассемблер (железо). Вопрос только в том, с чего начинать.

Изменено 16 октября, 2009 пользователем Tesla

[Alexeyslav]

Увы, деление на алгоритмы и железо при помощи языков - не катит. алгоритмы всегда выше языков, а железо - само по себе.

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

Составить алгоритм можно где угодно - хоть на листочке бумажки, нельзя ведь более менее сложные системы писать сходу на каком бы то ни-было языке. И даже на Си быстро запутаешься если нет общего плана, общего алгоритма.

Для маленьких проектиков - он вполне умещается в бошке программиста.

[Tesla]

Написание алгоритма для микроконтроллера это нечто большее, чем написание алгоритма прикладной программы. Логика работы может кардинально меняться в зависимости от наличия того или иного аппаратного интерфейса или, например, таймера. В прикладном программировании то, с чем работает программист (API), написано другим программистом, мыслящим так же абстрактно. В микроконтроллере программист имеет дело с холодным железом. Он должен отдавать себе отчёт в том, что register++ означает иногда не "увеличение переменной register на 1", а "выдача на адресную шину адреса register, формирование строба /RD, чтение с шины данных, инкремент полученного значения, выдача данных, формирование строба /WR", и, в зависимости о того, что подключено на выход дешифратора адреса, результат может сильно отличаться от первого очевидного варианта. А си просто не обладает средствами для того, что хоть как-то визуально представить этот процесс, нам остаётся только всецело доверять компилятору. Или такой случай, когда в стандартное ядро процессора добавлены пользовательские команды (на место зарезервированных опкодов), например, сброс watchdog-таймера - си тут помочь уже не сможет. Пусть не в основной программе, пусть в далеко запрятанной библиотечке, да будет в этом случае стоять директива "asm".

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

[dkdent]

Мне все понятно, кроме одного. Знание или незнание ассемблера НЕ МЕШАЕТ изучить и использовать все аппаратные возможности микропроцессора. Это вопрос скорее к программисту.

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

но чуть медленнее, чем если бы это было написано на асме.

Ну и к тому же основной аргумент ассемблерщиков это оптимизация. Уже не актуален. Мега168 16К флеш, стоит полдоллара. Хоть оптимизируй, хоть нет, места валом,

можно левой ногой писать и все равно уместится. Тоже самое касается и скорости. Не тянет микропроцессор, ставим камень постарше. И сразу все 150 МГц, хватит на все.

Все они сейчас стоят копейки, до 5 долларов за чип.

Нет смысла упираться рогом в оптимизацию, а да, я забыл про контроллер бельевой прищепки, который должен стоить 1 рубль на объемах 10 миллионов в месяц.

И что вот это то, к чему стоит стремиться, вершина профессиональной деятельности? Для кого то может и да. Но мое личное мнение, можно потратить время с большей пользой.

И по моему ассемблер по настоящему нужен именно в таких вот изделиях, когда нужно упаковать максимум функций в изделие за 5 рублей. И продавать на объемах. Вот только

сразу скажу программисту от этих объемах ничего и никогда не светит. Почему? А зайдите в любой магазин продуктов первой необходимости спички, соль, сахар, масло, сыр.

Это продукты которые брали, берут и будут брать на объемах везде и всегда. Сколько у Вас лично шансов пристроиться в этот бизнес? Ни одного. Там на страже армии стоят,

легальные и не очень, но реальные и грозные. Отстрелят все и сразу только сунься. Точно также будет и с серийным изделием. Кааак только изделие выходит на объемы

программисту в лучше случае дают бонус и говорят отойди. В худшем просто отбирают прошивку. Или нанимают еще одного на реверс инжиниринг. Какое то время покупают

у разработчика его чипы, пока делается реверс. А по завершении у производителя коробочек исходники. Все. Производитель посылает всех нафиг и клепает объемы.

Вот из за этого конфликта интересов и существует в данном случае религиозная война. Программисты видят, что при оптимизации можно сделать большие деньги, только никто и

никогда их не видел. Они всегда "где то".

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

То есть такой, за который сразу и один раз отвалят больше денег.

За оптимизацию, которая требует очень много сил и ресурсов от разработчика, всегда и везде платили копейки. Никто и никогда не платит за "будущие объемы". Работодателя

невозможно убедить, что коробочка размером с коробку спичек и процессором Tiny может потребовать два месяца упорной работы и 50 тыс рублей на оптимизацию программы.

Даже если он потом заработает на ней миллионы, платить вот эти 50 фиг его заставишь.

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

форумах держать корпоративную оборону. И давать все таки денежные направления приложения усилий, а не зарывать неокрепшие умы в грязь нищеты и безысходности.

Пускай пишут хоть на Дельфи для микропроцессоров. Но чтобы программы были сложные и главное ДОРОГИЕ.

Конечно это уже вроде как оффтоп. Но вопросы программирования на языках разного уровня сразу упираются в оптимизацию. А оптимизация это всегда финансы и только финансы,

поэтому пришлось здесь уйти немного в сторону.

В конце концов за редким исключением, мы тут все работаем для того чтобы отдыхать на югах, а не для того чтобы работать еще больше.

Изменено 17 октября, 2009 пользователем dkdent

[Tesla]

"Тяжело в учении, легко в бою!" Покажите мне хоть одного человека, который, прочитав свой первый даташит, сразу же рвётся выполнять коммерческие заказы. Обычно начинают с каких-то простых поделок для себя. Вот тут и есть время освоить ассемблер. Я ещё раз повторюсь - я тоже против того, чтобы писать на ассемблере те вещи, которые можно с лёгкостью написать на си. Но я считаю, что знание ассемблера нужно держать в голове - это, в конечном итоге, экономит время на отладке программы на си и помогает сделать работу более быстро и качественно.

По крайней мере, я так считаю. Вообще, нужно ли это заказчику - сложный вопрос. Я думаю, что в конечном счёте нужно. Просто у него нет гарантий, что тот разработчик, который затребует в два раза больше сроков и денег, действительно сделает работу более качественно, а не просто обнаглевший, поэтому он и вынужден в итоге выбирать того, кто предложит наиболее выгодные финансовые условия. Соответственно, и зарабатывать больше будет тот, кто делает откровенную халтуру, зато по 10 заказов в месяц. Что же, для кого-то вершина профессиональной деятельности - именно это.

[Alexeyslav]

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

Если проект настолько велик что требует огромных ресурсов, стоит его писать на языках высокого уровня - это сократит время на разработку. Но для маленьких проектов использование языка высокого уровня под вопросом и выбор на чем писать зависит лишь от предпочтений программиста(может он ассемблер как страшный сон вспоминает, а всю жизнь только на Си писал).

Лично мне, очень не хочется изучать Си только лишь для того чтобы писать программы для микроконтроллера - это будет такая каша в голове, лишний язык, лишние определения ... Поскольку, я уже заю несколько языков было бы логичней писать именно на них но к сожалению, из них пока доступен только ассемблер. Или может уже можно с паскаля компилировать программы для контроллеров? Было бы здорово...

[Tesla]

Или может уже можно с паскаля компилировать программы для контроллеров? Было бы здорово...

http://turbo51.com/

http://www.mikroe.com/en/compilers/mikropascal/avr/

Изменено 17 октября, 2009 пользователем Tesla

[Alexeyslav]

8051 микроконтроллерами не увлекаюсь, все-таки они старички уже. хоть и работают, достать их можно не везде.

[Tesla]

Не скажите. AVR - это, по большому счёту, линейка конкретных чипов от конкретной фирмы. 8051 - это не только классический AT89C51, это тысячи (если не сотни тысяч) различных устройств различного назначения от различных производителей. Например, я однажды из любопытства глянул, что за процессор стоит в моём телевизоре - оказалось, специализированный микроконтроллер с масочным ПЗУ, аппаратным декодером сигналов телетекста, несколькими PWM и ядром 8051 Или, например, CY7C68013A - универсальный микроконтроллер для высокоскоростных USB-устройств - IDE-USB боксов, сканеров и даже тв-тюнеров - опять же, на ядре 8051.

Изменено 17 октября, 2009 пользователем Tesla

[Goodefine]

...В конце концов за редким исключением, мы тут все работаем для того чтобы отдыхать на югах, а не для того чтобы работать еще больше.

Именно так. Выше я писал, что есть более приятные занятия, чем работать арифмометром...

.... Или может уже можно с паскаля компилировать программы для контроллеров? Было бы здорово...

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

[Tesla]

Насчёт мигания гирляндой 150-мегагерцовым 32-разрядным процессором - это, конечно, перебор. Тем не менее, есть целый класс сетевых устройств (ADSL-модемы, роутеры, WiFi-точки доступа), для которых в качестве прошивки используется полноценная операционная система (обычно Linux или VxWorks), и я, как потребитель, доволен тем, что могу купить такое устройство за одну-две тысячи рублей, а не за цену в 10 большую, как было бы, если прошивку писали с нуля на си, или, не дай бог, на ассемблере) За это приходится мириться с тем, что сама операционка пожирает половину ресурсов устройства.

[GROMIT]

Ппц, сколько оффтопа и опять об одном да об одном, что лучше Си или асм...На робофоруме, например, создали отдельную тему для этого, может и здесь так сделать?

[Alexeyslav]

Для серийного производства может и хороши контроллеры типа CY7C68013A но для личных разработок предпочтение отдается менее производительным контроллерам. И пока контроллер поддерживает малое количество команд - использование ассемблера еще оправдано. Но в случаях таких сложных систем как USB-IDE переходники а уж темболее ТВ тюнеров без языков высокого уровня не обойтись. Черезчур уж сложно держать в голове тысячи "стандартных" приемов, и сотни различных команд и при этом помнить особенности каждой. Именно это и заставляет переходить на языки высокого уровня. когда одно и то же можно сделать различными способами при большем разнообразии команд и способов реализации высокоуровневые языки в купе с оптимизатором в конечном итоге выигрывают.

Взять к примеру контроллер AT90S2313 или PIC16F84 - сомневаюсь в целесообразности применения к ним языков высокого уровня.

Как-то захотел сделать переключатель гирлянд, взял PIC16F84 и через 2 дня программа была готова. На языке высокого уровня, думаю не меньше времени ушло бы. Если использовать такую программу как Algorithm Builder написание программ ан ассемблере становится еще легче. Но почему-то программа не прижилась - чего-то в ней не хватает хотя идея несомненно хорошая.

Насчёт мигания гирляндой 150-мегагерцовым 32-разрядным процессором - это, конечно, перебор.

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

Изменено 17 октября, 2009 пользователем Alexeyslav

[Tesla]

Мигалка для гирлянды на AT90S2313. Время реализации: ~15 минут (включая тестировние)

#include <avr/io.h>
#include <avr/pgmspace.h>
#include <util/delay.h>

unsigned char PROGMEM pattern[] = {

0x01, 0x02, 0x04, 0x08, 0x10, 0x20, 0x40, 0x80

};


int main() {

int i = 0;

DDRB = 0xFF;

while(1) {

	PORTB = pgm_read_byte(pattern+i);

	i++;

	if(i >= sizeof(pattern)) i = 0;

	_delay_ms(500);
}

}

// компиляция: avr-gcc program.c -mmcu=at90s2313 -DF_CPU=8000000 -Os

[Alexeyslav]

Это слишком просто и банально. Гирлянда на 4 светодиода, каждый из которых горит одним из 16 уровней яркости. данные берутся с EEPROMa, и в целях экономии шагов (там всего 64 ячейки) на все светодиоды выводится одна и та же программа но с разным смещением.

[Goodefine]

...Гирлянда на 4 светодиода, каждый из которых горит одним из 16 уровней яркости. данные берутся с EEPROMa, и в целях экономии шагов (там всего 64 ячейки) на все светодиоды выводится одна и та же программа но с разным смещением.

Тогда, навскидку, я бы увеличил время написания с 15мин (что явно много для предшествующего кода) до 30-40мин. Если подумать над реализацией, чтоб дописывать/модифицировать было легко - то час максимум. Чего там два дня писать на Си, я даже не представляю...

[Tesla]

Это я для примера) Из этих 15 минут я 10 вспоминал, как пользоваться pgmspace, и почему pgm_read_byte(pattern) не катит Я тоже на си для atmega8 писал диммер на 6 каналов с таблицей компенсации нелинейности яркости свечения ламп от фазы включения. А слишком просто и банально было бы так: PORTB = 1; while(1) PORTB = (PORTB << 1) | (PORTB >> 7);

А вообще, и правда - развели мы тут оффтопа... У всех по разному мозг работает. Кого-то мутит от фигурных скобочек си, а кого-то - от однообразности ассемблерного кода (лично меня - ни от того, ни от другого). Понятие "правильный подход" применимо только тогда, когда есть конкретная задача. А гирлянды себе домой кто как хочет, тот так и делает) Кто-то, например, в свободное время процессор на реле собирает - готов ли его кто нибудь упрекнуть в том, что он фигнёй страдает?

Изменено 17 октября, 2009 пользователем Tesla

[Alexeyslav]

Так я до этого практически программы не писал, это может быть была 2-я или 3-я ... два дня это не означает двое суток, это означает 2 вечера. И то пока нашел где инклудник взять для 16F84...

И еще заметил паталогическую склонность усложнять задачу по ходу, если получается все слишком просто. Сначала хотел сделать просто мигалку, но показалось слишком просто ...

[Юрец]

Тема "Авто + Бортовой Миникомпьютер" несколько функций, а Юрец уже с Мега8 на Мега16 собрался переходить.

приятно слышать и критику.

при разработке девайсов и их функц. способностей на первом месте у меня - чтобы это РАБОТАЛО. да, программу пишу не по правилам, не так, как сделал-бы это такой гуру как GOODEFINE, отсюда большой размер кода, не помещающийся порою в камень. бывает и 3-х таймеров нехватает... а может у меня так мозги повернуты