Поиск качественной литературы по мк. КР580ВМ80А

[shonty]

Я б повесилась писать на асме ту же метеостаницию на атмега128.

писал метеостанцию с выводом графика (график только давление, проверка раз в 15 минут, график давления выводится за 3,3 суток (80 часов), весьма наглядно получается). m328, bme280. Не повесился хотя расчёты там интересные))
Хотя.. может у вас что-то покруче))

Добавлено after 11 minutes 24 seconds:

У меня в школе был бейсик, в ВУЗЕ - паскаль. Дальше вообще не проблема оказалась.

у меня в школе информатики ещё не было.. а вузов у меня вообще не было

Но есть люди, у которых аргумент для асма - не скорость, полный контроль над МК и т.д. - а простое незнание Си.

да, я не знаю си. Ни разу не стесняюсь этого..

Тем более мк я начал программировать в 2018-м.. и ещё перерыв у меня был примерно 3..4 года..
Так что я совсем новичёк пока)) и мне многих не догнать))

Добавлено after 15 minutes 42 seconds:
Дополню

Но есть люди, у которых аргумент для асма - не скорость, полный контроль над МК и т.д.

Но есть ещё один аргумент против ЯВУ, который вы не упомянули - это нежелание принимать чужие концепции..
У меня с этим всегда проблемы были..

[jcxz]

[uquote="shonty",url="/forum/viewtopic.php?p=4685215#p4685215"]да, я не знаю си. Ни разу не стесняюсь этого..[/uquote]Вообще не вижу проблемы изучить си, зная ассемблер. Имхо - сложнее изучать си, имея в багаже только что-то типа Бейсика или Питона (высокоуровневое). Сам в своё время изучил си самостоятельно. Основываясь на знании ассемблера. И было это насколько помню - легко. Так как - читаешь в учебнике про указатели, и сразу понимаешь как оно внутри работает (в ассемблере). Читаешь про локальные автоматические переменные (которые на стеке) и тоже - сразу понимаешь как это будет в асме. И т.д.
Даже если что-то непонятно, то нетрудно ведь запустить компиляцию и посмотреть результат в листинге. Если действительно знаешь асм - всё сразу должно стать понятно. Листинги - хороший способ разобраться в каких-то непонятках языка. Те, кто идёт в си с высокого уровня (или вообще - с 0), этого не умеют. И им сложнее.

Так что это - только вопрос желания.

[Starichok51]

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

[jcxz]

[uquote="Starichok51",url="/forum/viewtopic.php?p=4685228#p4685228"]Adrift, даже в своих самых больших программах я не рисовал блок-схемы. мне всегда хватало головы, чтобы составить и написать все нужные алгоритмы.[/uquote]Точно. Аналогично. Блок-схемы - это какая-то далёкая-далёкая архаика..... Когда программы писались на бумажке, так как нормальные персональные ПК были недоступной роскошью.

[AlexS4]

c C у меня иногда возникает парадокс, когда пытаешься заставить компилятор делать вточности то что тебе хочется,
приходится так много добавлять всяких static/register/inline/defie/... ,
что кот становится менее компактным и даже чуть менее читабельным чем masm
и главное такой код все равно трудно сделать понастоящему кроссплатформенным.
по опыту - проще сделать masm коды для всех нужных архитектур чем корячиться писать критичный к эффективности кот на С
c кучей компайлтаймовых веток #if/define.


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

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

[jcxz]

[uquote="AlexS4",url="/forum/viewtopic.php?p=4685234#p4685234"]c C у меня иногда возникает парадокс, когда пытаешься заставить компилятор делать вточности то что тебе хочется,
приходится так много добавлять всяких static/register/inline/defie/... ,
что кот становится менее компактным и даже чуть менее читабельным чем masm[/uquote]Это говорит только о вашем уровне владения си. Не более.

Некоторые вещи на си пишу так, что просто копирую их в проект на ARM (stand alone) и в проект на ПК (win; x86). Один-в-один, не меняя не буквы. И никаких проблем - собирается и работает. И это удобно. Например - когда пишешь парсер какого-то связного протокола. Объём работы уменьшается в 2 раза.
Попробуйте так сделать на асме.

[Adrift]

[uquote="Starichok51",url="/forum/viewtopic.php?p=4685228#p4685228"]Adrift, даже в своих самых больших программах я не рисовал блок-схемы. мне всегда хватало головы, чтобы составить и написать все нужные алгоритмы.[/uquote]
Так и я никогда не рисовал блок-схемы ) Просто для ЯВУ без них вполне можно обойтись, а на ассме очень редко пишутся настолько алгоритмически сложные программы. Ассм - это про минимализм, взять хоть ваш с shonty опрос кнопок. И рекурсивный спуск на ассме никто в здравом уме писать не будет тоже, хотя были времена когда другого выбора не оставалось.

[Starichok51]

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

[Adrift]

[uquote="Just_Fluffy",url="/forum/viewtopic.php?p=4685209#p4685209"]ООП - да, тут несколько уже сложнее, но он в 90% случаев не нужен для МК.[/uquote]
C++ на мк - это классы, преимущественно шаблонные, практически для всего, следовательно абстракция и инкапсуляция будут везде, наследования не так много, как на ПК, полиморфизма еще меньше. Ну и там целый вагон всевозможных улучшений никак не связанный ни с ООП, ни с шаблонами и главное перейти на C++ можно легчайше просто заменив компилятор и сделав небольшие правки, дальше можно добавлять новые фичи по мере изучения. По сравнению с этим переход с AVR на ARM - целое дело )

[uquote="Starichok51",url="/forum/viewtopic.php?p=4685251#p4685251"]рекурсивный спуск - это кого и куда спускают рекурсивно?[/uquote]
В простом случае это может быть разбор математических выражений. У разных операторов разные приоритеты и ассоциативность, помимо этого могут быть скобки, вызовы функций с разным числом аргументов которые могут быть вызовами других функций, даже тернарные операторы.

[shonty]

рекурсивный спуск

тернарные операторы

нее.. спасибо.. мы уж как-нибудь при помощи блок-схем, отвёртки и пассатижей

[Just_Fluffy]

shonty, Вы не услышали посыл. Вы можеьте написать на М328 станцию. Но скорость разработки на асме у вас будет ниже, читабельность ниже. Переносимость вообще никакая.
Я метеостанции не делала, не нужно было, термометры всякие с часами - было дело.
Здесь на коте есть в статьях две метеостанции на 128 меге. Я не уверена, что я бы захотела писать их на асме (хотя там половина флеша - картинки).
Вот реально, попробуйте изучить си. После асма он станет вам легкий, ибо это наиболее низкоуровневый ЯВУ.

Для больших программ нужно уже выделять все в отдельные блоки, принимать какие то соглашения по регистрам, вызовам, передаче параметров... Т.е. оптимизация всего кругом для экономии байт уже не всегда получается в том объеме, как на маленьких проектиках в 2-4-6 кб. И получится, что следование соглашениям и разбиение кода на блоки - это то, что делает компилятор ЯВУ.

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

Adrift, как я вас понимаю про рекурсивный спуск. Я тут принимала небольшое участие в проекте компилятора бейсика в байт-код на СТМке... И потом выполнятор этого кода.... Мой большой кусок - менеджер ОЗУ с уборкой мусора. Не хотелось бы это писать на асме...

[BOB51]

Ассемблер имеет такие же (а часто и значительно большие) возможности, что и ЯВУ.
Да и "большие программы" там вполне можно создавать.
Понятно, что заметно муторнее стыковка с тем, что на ЯВУ сделано - надо в "правила стыковки" того ЯВУ вписываться (а их порой весьма трудно раскопать). Да и минимум БИОС ПК знать под несколько вариантов операционок ....
Но пока речь о изделиях на МК - тут во многих случаях ассемблер вполне достаточен.
Не пишут на нем больше из лени и времени на изучение матчасти (документации самих МК и "вумной периферии").
Сам такую тенденцию замечаю - ленивый до ужастиков стал.

[Adrift]

[uquote="Just_Fluffy",url="/forum/viewtopic.php?p=4685273#p4685273"]Я тут принимала небольшое участие в проекте компилятора бейсика в байт-код на СТМке... И потом выполнятор этого кода.... Мой большой кусок - менеджер ОЗУ с уборкой мусора. Не хотелось бы это писать на асме...[/uquote]
Видел, только мне показалось там компилятор в байт-код для ПК, а STM32 его только выполняет. Я последний компилятор на C# писал, а сейчас для Pico у меня вместо внешней утилиты pioasm.exe используется транслятор работающий во время компиляции C++ кода. Кусочек оттуда:

Спойлер

Код: Выделить всё

// JMP (cond) target
// cond: always, !x, x--, !y, y--, x != y, pin, !osre
// target: instruction address to jump to.
consteval bool processJmp()
{
    uint16_t instr = 0x0000;

    if (check("!")) // !x, !y, !osre
    {
        if      (check("x"))    instr |= 1 << 5;    // !x
        else if (check("y"))    instr |= 3 << 5;    // !y
        else if (check("osre")) instr |= 7 << 5;    // !osre
        else return Error("unexpected identifier ...");
        check(",");
    }
    else if (check("x"))
    {
        if (check("--"))
        {
            instr |= 2 << 5;    // x--
        }
        else if (check("!="))
        {
            if (check("y")) instr |= 5 << 5;    // x != y
            else return Error("expect 'x != y'");
        }
        else return Error("expect 'x--'");
        check(",");
    }
    else if (check("y"))
    {
        if (check("--")) instr |= 4 << 5;   // y--
        else return Error("expect 'y--'");
        check(",");
    }
    else if (check("pin"))
    {
        instr |= 6 << 5;    // pin
        check(",");
    }

    auto tok = getToken();
    if (tok.isText())
    {   // Label
        auto* label = findLabel(tok);
        if (label)
            instr |= label->addr;
        else
            jmpPatch.push({ tok.str, (int)code.size, line });
    }
    else if (tok.isNumber())
    {
        instr |= tok.value;
        if (tok.value > maxJmpValue)
        {
            maxJmpValue = tok.value;
            maxJmpLine  = line;
        }
    }
    else return Error("expect label or number.");

    return processSideDelay(instr);
}

// (side k) ([k])
consteval bool processSideDelay(uint16_t instr)
{
    bool hasSide = check("side");

    if (!sideSetOptional && sideSet && !hasSide) return Error("instruction requires 'side' to specify side set value.");
    
    if (hasSide)
    {
        int value = matchNumber(0, powf(2, sideSet) - 1, "side set value is out of range.");
        if (error) return false;
        instr |= value << (8 + 5 - sideSet - sideSetOptional) | (sideSetOptional << 12);
    }

    if (!check("["))
    {
        code.push(instr);
        return true;
    }

    int value = matchNumber(0, powf(2, 5 - sideSet - sideSetOptional) - 1, "instruction delay is out of range.");
    if (error) return false;
    code.push(instr | uint16_t(value << 8));

    if (!match("]", "expect ']'.")) return false;

    return true;
}

Просто для понимания того насколько C++ далеко ушел от C, компилятор с нулевым потребление ресурсов помимо места во флеше где окажутся PIO инструкции. Хотя если взять свежайшую книгу по C23, то может получиться как с новыми AVR, которые уже не AVR )

[Just_Fluffy]

Adrift, Не, я в кресты не лезу, ибо знаю, что мне до них далеко.
Я на ПК по старинке, на делфи. Хотя пробовала С++ Билдер , но как то не сильно срастается... На ПК проще на дельфях, хотя многие паскалевские приколы синтаксиса бесят после Си.
Правда, приколы PLSQL на работе бесят тоже ))))

А про компилятор - там была задумка у автора той приблуды - программа на бейсике пишется на флешку, СТМка ее внутре компилирует и потом выполняет. А для ПК есть эмулятор и отладчик бейсик-программы. Но изначально, в СТМке есть и компилятор, и "выполнятор", но нет редактора и отладчика.

[shonty]

по теме, про литературу
https://rutracker.org/forum/viewtopic.php?t=3829379
подборка DI Halt "AVR Учебный курс" 2008, всё в одной раздаче, с примерами.

[Just_Fluffy]

shonty, ну нет... по теме - это про КР580ВМ80А. тему ж модератор не поменял.... И выносить весь флуд в отдельный топик ему тоже влом.

[Adrift]

[uquote="Just_Fluffy",url="/forum/viewtopic.php?p=4685288#p4685288"]Не, я в кресты не лезу, ибо знаю, что мне до них далеко.[/uquote]
Как тогда ардуинщики справляются? Многие из них и не подозревают, что пишут на C++, но даже это не является проблемой )

[BOB51]

Мы немножко забываем, что I8080 это только функционал ядра современного МК.
А все "вокруг" есть периферия.
Только вот ПК так по большей мере и остаются с внешней периферией, а вот МК уже практически все во внутрь затащили, превратившись в "систему на кристалле".
Посему стоит разделение и в классификацию уровня МКвнести, согласно сложности внутренней начинки.
По старому такой раздел был по линии наличия внешней шины для памяти программ/данных
Т. Е. Микропроцессоры и микроконтроллеры с внешней совмещенной памятью программ/данных как бы одна группа.
А вот то, что со встроенное памятью программ - то "чистый МК".
Правда сейчас и гибриды с исполнением программ из встроенного ОЗУ вроде появляться стали.

Насчет адуринки и ++...
Там в основном " уровень приплюснутого пользователя"

[Just_Fluffy]

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

гибриды с исполнением программ из встроенного ОЗУ вроде появляться стали

Да никакие это не гибриды, обычный Фон Нейман.
У современных мМикрочипных АВР вроде как ОЗУ и флеш тоже проецируются в общее адресное пространство..... Т.е. никто не мешает накидать в ОЗУ кусок кода и передать туда управление.
А у СТМок такое "из коробки" - единое 4-гиговое адресное пространство, где флеш, ОЗУ и периферия. Еще и ассемблер с относительной адресацией, позволяющий код передвинуть в памяти на другие адреса и он без перекомпиляции там выполняется.

[BOB51]

Нет.
Не путайте общее адресное пространство с режимом совмещенной памяти программ/данных!
Это не одно и то же!

Там просто чуток модифицированный вариант адресации, но степень разделения по правилам доступа осталась прежней.
А вот в АРМах где то уже попадалось реальное исполнение команд из ОЗУ.