Как описать прерывание в блок-схеме?

[BARS_]

1 минуту назад, mvkarp сказал:

Коды растут, железа требуется все больше...

Ооооо, адроид их давно обогнал в этом плане

[Реклама]

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

[mvkarp]

11 минуту назад, BARS_ сказал:

В 2015-16, если правильно помню.

Более понятно направление мышления.
А скажите Ваше мнение - вот кто пишет всякие высокие уровни, они на что основываются? На такие же высокие уровни или все же на машинные коды? 
Так что-же первоначально - яйцо или курица? Коды или высокий уровень?

Загадка? В яйце и курице - да. В кодах - лично для меня  - нет. Я выбрал это направление, Вы другое. Только и всего. 
Но обозначать каждое направление за однозначно правильное - нет, нельзя.

@BARS_ , это больше вопрос начинающим. Мы с Вами в этом вопросе уже нашли решение ранее. 

[Реклама]

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

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

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

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

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

[BARS_]

6 минут назад, mvkarp сказал:

кто пишет всякие высокие уровни, они на что основываются? На такие же высокие уровни или все же на машинные коды? 

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

 

7 минут назад, mvkarp сказал:

Я выбрал это направление, Вы другое.

Я могу писать и на Си и на асме. Только вот с AVR я ушел на STM32, там уже с асмом не сильно попишешь, да и смысла нет. Занять даже 64Кб памяти еще постараться надо, а быстродействия итак в избытке. 8-битники на работе остались, в виде 8051 ядра, но там прошивки большие и на асме тоже особого смысла нет заморачиваться, долго слишком. Ну а на чем начинать, личное дело каждого, всегда можно выучить недостающее)

[Реклама]

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

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

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

[ruhi]

37 минут назад, BARS_ сказал:

Для начала переводить научитесь. Вот эта запись ARM® Cortex®-M7 как раз и подразумевает ядро. Компания, которая придумала ARM ядро не выпускаем МК, вообще никакие. Она продает права другим компаниям, которые выпускают МК на их основе. Хотя даже не совсем так, ARM - это архитектура ядра, а Cortex®-M7 как раз само ядро. Но ARM МК не бывает, т.к. ARM это пустой вычислитель без периферии. А вот периферию производители добавляют по своему усмотрению. При этом у каждого производителя, коих приличное количество, свое видение этого вопроса. Так же как и есть ядро 8051, но МК на этом ядре выпускаются весьма разные. Разберитесь уже, наконец, в строении МК, чтобы не писать такую фигню. В тех же телефонах, кстати, тоже ARM архитектура, только ядро А9/10 и т.д., при этом это уже не МК, а именно процессор.

Ладно, я вам тоже по секрету скажу, мне просто не нравится, чисто субъективно, название "контроллер", потому что !:)! мне нравится название "процессор", наверно потому что когда я в школе в 1989 г. начал заниматься программированием был только процессор и это была крутая штука :). И я совершенно это осознаю.

И, на самом деле, мне воЩе пофигу процессор он, контроллер или ядро внутри контроллера, лишь бы программа работала!

Но Вам спасибо за дискуссию! (Но денег нет как говорил тот который этот ...

И улыбайтесь господа :), не люблю напряженные лица!

Изменено 27 ноября, 2017 пользователем ruhi

[-=FISHER=-]

Такая горячая дискуссия у вас господа!  и мне со стороны как новичку, кажется что каждый из Вас прав по своему. А вообще как правильно заметил @ARV , наверное программирование оно на любом языке программирование, то есть способ умения раскладывать сложные действия на простые алгоритмы. И вот у меня, как у топикстартера, проблема именно в этом сейчас, разложить сложное действие на простой и понятный алгоритм, а уже потом я буду "переводить" на конкретный язык программирования.

[ARV]

Только что, mvkarp сказал:

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

Высокий уровень позволяет лишь писать побыстрее коды да продавать их. Пример тому  - Гейтс с его Майкрософт. Коды растут, железа требуется все больше... А смысл? Продажи, ёлы, деньги!

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

[ttt222]

17 минут назад, mvkarp сказал:

Так что-же первоначально - яйцо или курица? Коды или высокий уровень

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

[ARV]

Только что, ttt222 сказал:

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

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

Это я к тому, что историческая перспектива развития языков программирования - это не аргумент при выборе языка для обучения.

[ruhi]

16 минут назад, -=FISHER=- сказал:

Такая горячая дискуссия у вас господа!  и мне со стороны как новичку, кажется что каждый из Вас прав по своему. А вообще как правильно заметил @ARV , наверное программирование оно на любом языке программирование, то есть способ умения раскладывать сложные действия на простые алгоритмы. И вот у меня, как у топикстартера, проблема именно в этом сейчас, разложить сложное действие на простой и понятный алгоритм, а уже потом я буду "переводить" на конкретный язык программирования.

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

[-=FISHER=-]

Только что, ruhi сказал:

Если ты пытаешься сам с нуля что то изобрести , то это зря. Надо найти решение подобной задачи и с ним разбираться! 

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

[ttt222]

2 минуты назад, ARV сказал:

Это я к тому, что историческая перспектива развития языков программирования - это не аргумент при выборе языка для обучения.

ну именно в этом ключе я этого и не утверждал.

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

а то как то даже и смешно, Attiny2313 и СИ

[ruhi]

1 минуту назад, -=FISHER=- сказал:

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

Ну вывали тут свой функционал, а то сваришься в собственном соку :)!

[ARV]

Только что, ttt222 сказал:

а то как то даже и смешно, Attiny2313 и СИ

А что именно вас смешит?

А что скажете про Си и attiny13? Не смешно вам? Мне - нет, неплохие проекты писал...

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

[ttt222]

3 минуты назад, ARV сказал:

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

на это я могу так же ответить что это не аргумент в выборе языка при изучении МК

 

[ARV]

Только что, ttt222 сказал:

на это я могу так же ответить что это не аргумент в выборе языка при изучении МК

Так цель не изучить МК, а научиться программировать... МК изучить можно по даташиту без всяких языков (кроме английского )

[ttt222]

1 минуту назад, ARV сказал:

научиться программировать...

научиться программировать под МК как я понимаю? ) а не просто программировать

программисты 1С тоже считают себя программистами

[BARS_]

1 минуту назад, ttt222 сказал:

научиться программировать под МК как я понимаю? )

Т.е. на основании ваших слов, я не умею программировать МК, т.к. начинал не с асма и сейчас тоже пишу на Си? Интересно, интересно, продолжайте...

[ARV]

Только что, ttt222 сказал:

научиться программировать под МК как я понимаю?

Да МК всего лишь набор ограничений! В 1С ограничения одни, на компьютере - другие, в 8-битном МК третьи, а в 32-битном - четвертые... На сам процесс программирования это влияет слабо. Ранее я писал, что в моём представлении есть программирование. И "программирование под МК" - это всего лишь небольшая рябь на поверхности озера с названием Программирование

[ttt222]

я считаю так, что в любом деле люди делятся на специалистов, - профессионалов, и тех кто любители или мимикрируют под профессионалов

одну категорию от другой отличает уровень  знание предмета.

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

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

нужны ли глубокие знания архитектуры МК профессионалу в области программирования МК? я считаю нужны, иначе какой он профессионал? писать код он может на чем угодно, но он должен прекрасно разбираться в том с чем он работает

и думаю ни один настоящий профессионал не скажет что не нужно знать ассемблер, что эти знания лишние и достаточно только Си

 

п.с. я не профессионал в программировании МК

[BARS_]

Только что, ttt222 сказал:

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

Нужны, для этого читается даташит.

1 минуту назад, ttt222 сказал:

и думаю ни один настоящий профессионал не скажет что не нужно знать ассемблер, что эти знания лишние и достаточно только Си

Знать может и нужно (правда, на те же 32-битные МК он в принципе не нужен), но знать и писать - разные вещи. Класс МК, для которых был актуален асм постепенно уходит в прошлое. У новых МК те фишки ускорения работы, ради которых применялся асм, реализованы аппаратно, а памяти хоть запишись. Так что применение асма теряет смысл.Особенно если учесть тот факт, что даже на Си программа может занимать тысяч 50 строк.

[Alexeyslav]

11 час назад, -=FISHER=- сказал:

как же описать внешние прерывания и прерывания по переполнению от таймера-счётчика в блок-схеме?

Очень просто - на ОТДЕЛЬНОЙ блок схеме. У вас в прерывании есть точка входа и выхода - не это ли определение отдельной блок-схемы? Полностью независимый кусочек алгоритма. Только подписать откуда он и где выполняется(прерывание, таймер, можно записать условие...) Точно так же как и все остальные подпрограммы... вход-выход и это есть отдельный кусочек блок-схема. Только не забыват подписывать их, чтобы не запутаться - что это за кусочек, обработчик прерывания, отдельная процедура, функция или вообще концепт UI(User Interface) который не имеет конкретного воплощения в коде - например структура меню настроек и т.д. которые задаются в виде псевдокода в виде отдельных ресурсов.

[Alexeyslav]

Цитата

мне просто не нравится, чисто субъективно, название "контроллер", потому что !:)! мне нравится название "процессор"

Вы наверно уже не застали те времена когда "процессор" был вполне делимой единицей и представлял собой целый ящик с транзиторами и проводочками весом под 70кг. Тогда это был процессор! Да и в 90-е годы было полно процессоров в однокристальном исполнении. Но процессор сам по себе НИЧЕГО НЕ УМЕЕТ, ему даже неоткуда программу исполнять! Когда к процессору подключили оперативную память, постоянную память, схемы тактирования, сброса и УВВ то это уже стал полноценный контроллерный блок. А вот когда это всё упаковали в один единственный кристалл это уже начали называть микроконтроллер(и то не сразу!). Как ни удивительно, до недавнего времени эти кристаллы развивались и ещё на основе того старого ядра... досихпор ещё можно встретить эти ядра в виде контроллеров флешек, SD-карт, USB-хабов...

[mvkarp]

В 27.11.2017 в 15:26, ttt222 сказал:

иначе как по Вашему стало возможно появление всевозможных конструкций и функций? 

 Это Вы у меня спрашиваете? 

В 27.11.2017 в 23:42, Alexeyslav сказал:

Тогда это был процессор!

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

[COKPOWEHEU]

В 27.11.2017 в 16:29, BARS_ сказал:

Знать может и нужно (правда, на те же 32-битные МК он в принципе не нужен), но знать и писать - разные вещи.

Он даже на 64-битных процессорах нужен. Правда, для прикладного программиста скорее умение не пугаться виду дизассемблерного кода и способность найти какая последовательность команд за что отвечает. Чтобы определить узкое место, определить атомарна ли операция и т.п.

[Microchip]

Вот ведь развели холивар. Нет чтоб просто на вопрос ответить человеку.

В 27.11.2017 в 14:45, -=FISHER=- сказал:

...как же описать внешние прерывания и прерывания по переполнению от таймера-счётчика в блок-схеме?

Очень просто. Как отдельную блок-схему. 
блок-схема 
Здесь "Индикация" вынесена в отдельную функцию в виде отдельной блок-схемы. Остальные - прерывания. Слева основной цикл. 
Только вход/выход рисуется полукруглым прямоугольничком как тут. Ввод/вывод оформляется в параллелограмме. Остальные фичи навряд ли в большинстве случаев понадобятся. элементы блок-схем  и  еще

В 27.11.2017 в 14:45, -=FISHER=- сказал:

P.S. Правильно ли я принял решение рисовать блок-схему вообще?

Конечно. Хотя бы потому, что такие вопросы задаете. Блок-схема это графическое, а значит очень наглядное представление алгоритма. И если она вызывает затруднение в составлении, значит данное решение чертовски правильное.

Цитата

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

На листочке можно по-чиркать, подумкать, по-исправлять быстренько то что там задумал. А если алгоритм писать сразу в коде то:
во-первых, не наглядно. Что для не обладающих скиллом 80-го уровня в программировании может быть проблеммно;
во-вторых, быстренько по-удалять и по-надписывать новые абзацы в коде может быть нее совсем быстрее чем сделать пару черточек и надписей в блок-схеме.
Ну если только есть скилл 400 символов в минуту в десятипальцевом методе печати то да, действительно блок-схема пустая трата времени. 

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

Изменено 25 декабря, 2017 пользователем Microchip
ошибки