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

[Just_Fluffy]

BOB51, в АРМах реально прогу можно закинуть в ОЗУ и отуда выполнить. Насчет новых АВРок - я их не щупала, только читала описание, что там озу и флеш в общем адресном пространстве.
И если адресное пространство общее, то разве это не совмещение памяти программ и данных? Просто часть этого пространства - флеш.

[AlexS4]

[uquote="jcxz",url="/forum/viewtopic.php?p=4685243#p4685243"]Это говорит только о вашем уровне владения си. Не более.

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

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

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

и я не экстремист, пишу всякое на очень разном ...<removed> ... и вообще разные вещщи как и разные подходы хороши для разного, имхо надо просто стараться быть обьективным и не позволять своим эмоциям и порокам делать странный выбор

[BOB51]

Just_Fluffy
У энхансед средне младших пиков это всего лишь ещё один вариант адресации периферии.
По новым сериям АВР даташитов не изучал, но вряд ли микрощип будет применять столь радикальные меры в отношении микроконтроллеров (в таком случае придется кардинально менять систему команд, а этого пока не наблюдалось ). Собственно суть прикладных МК в защите критических ресурсов от "несанкционированного доступа" при случайных сбоях программ. А РСФ как часть общего адресного пространства без защиты весьма уязвимы.
У МП для того разделение областей на память программ/данных и область адресов "устройств ввода/вывода".

[Adrift]

[uquote="BOB51",url="/forum/viewtopic.php?p=4685326#p4685326"]По новым сериям АВР даташитов не изучал, но вряд ли микрощип будет применять столь радикальные меры в отношении микроконтроллеров (в таком случае придется кардинально менять систему команд, а этого пока не наблюдалось ).[/uquote]
У старых avr адреса флеша с 0 начинались, I/O c 0x20, а SRAM c 0x100, в итоге флеш с ними пересекался и для него требовались дополнительные инструкции. У новых AVR I/O начинается с 0, SRAM c 0x4000, флеш с 0x8000 и ничего не пересекается, можно использовать LD для чтения флеша точно так же как раньше можно было использовать LD для чтения I/O. Однако при таком подходе 64К флеша в адресное пространство не влезет, потому LPM тоже осталась и для нее флеш начинается с 0.

[Just_Fluffy]

Adrift, глупый вопрос - а JMP на область ОЗУ может работать?

[AlexS4]

Собственно суть прикладных МК в защите критических ресурсов от "несанкционированного доступа" при случайных сбоях программ. А РСФ как часть общего адресного пространства без защиты весьма уязвимы.

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

[BOB51]

Adrift
Именно чтение/запись данных, но не запись кода команд и запуск их на последующее исполнение.
Кстати... Счётчик команд там откуда запускается? ( какое начальное значение счётчика программ по сигналу reset?). И какую ячейку реального адресного пространства в данном случае МК считает 0х0000 в отношении памяти программ?

Как то вспоминаются ухищрения прошлых лет - аппаратное перемещение стартового адресата в АОНах на Z80 , да сегментный фокус у I8086/8088.

[Adrift]

[uquote="Just_Fluffy",url="/forum/viewtopic.php?p=4685337#p4685337"]а JMP на область ОЗУ может работать?[/uquote]
Наверняка нет, там ведь шина 8-ми битная.

[jcxz]

[uquote="AlexS4",url="/forum/viewtopic.php?p=4685314#p4685314"]речь о коде, который должен выполняться максимально эффективно (ну чтоб ни лишнего такта не тратилось на 100500 стековых операций когда без них легко обойтись)
то что у когото нет такой задачи[/uquote]Не бывает такого, чтобы прям весь код требовалось выполнять "чтоб без лишнего такта". Как правило - такое нужно только на каких-то конкретных, узких участках кода. И на таких участках да - вполне оправдан ассемблер. И не надо угадывать какие у меня задачи. У меня тоже есть тяжёлые задачи. Где приходится вылизывать каждый такт. (И может вам даже и не снилась тяжесть моих задач ).
Но тяжёлые - только конкретными участками кода. И эти участки я тоже пишу на ассемблере. В то время как основной массив кода == си++.

PS: И чтобы вам не было одиноко меряться познаниями в языках, скажу, что и я кроме си и асма, пишу и на Питоне и на Яве. Но - всему своё место.

[Starichok51]

Хотя пробовала С++ Билдер , но как то не сильно срастается... На ПК проще на дельфях, хотя многие паскалевские приколы синтаксиса бесят после Си

для компа я шишу на С++ в микрософтской вижл студио, и там у меня нет никаких проблем и приколов.

Не, я в кресты не лезу, ибо знаю, что мне до них далеко.

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

[Adrift]

[uquote="Starichok51",url="/forum/viewtopic.php?p=4685386#p4685386"]но и визуальное программирование у Борланда очень сильно отличается от визуального программирования в Микрософте, даже на только в Паскале, но и именно в С++.[/uquote]
Для визуального программирования на C++ в VS нужен С++/CLI, большинству он не нужен, есть мейнстримный C# для таких целей.

[Starichok51]

я ничего не знаю про CLI. я поставил вижл студио и горя не знаю. ничего отдельно ставить не пришлось.

[Adrift]

Starichok51, если у вас проекты на .Net, то там С++/CLI, если классические MFC-ые, то это сложно назвать визуальным программированием.

[AlexS4]

кстати а еще же был С-- , по сути это такой макроассемблер 8080/86/386 с синтаксисом С. там прямо связь переменных с регистрами была типовым сценарием.

давно не смотрел что с ним сталось

ааа!!! забили на него, жаль
git clone https://github.com/jossk/c--sphinx/
сделал себе навсяк


русская дока
https://www.c--sphinx.narod.ru/c--doc.htm (https серт просрочен, непугаемся)

[Вячеслав М.]

Чё то про новые AVR ничего не знаю, как то на XMega сделал попытку перейти, но после прочтения errata сразу желание отпало, оказалось оно не 33Mgz а старые добрые 20,просто фуфел в рекламке. А вы утверждаете что там в AVR какое то новое адресное пространство ОЗУ и ещё исполняемое?

Добавлено after 3 minutes 13 seconds:
Visual Studio шикарная среда, согласен с теми кто пишет что там нет проблем. Только я её под Python использую.

[Starichok51]

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

[jcxz]

[uquote="Starichok51",url="/forum/viewtopic.php?p=4685386#p4685386"]С++ Билдер - это Борланд. а винда написана на микрософтской вижл студио, поэтому под винду лучше писать на микрософтской вижл студио. Борланд может не знать всех тонкостей, чтобы сделать полноценное приложение. но это я так думаю, могу быть и не прав.[/uquote]Раньше я под win писал на Борланде. Но ~15 лет назад перешёл на VS. Имхо - VS не то чтобы "знает больше тонкостей win", а просто у Борланда, между его слоем визуальных компонентов и WinAPI, прослойка более толстая, чем у VS. Более толстая и тяжёлая эта прослойка. Соответственно - хоть она предоставляет больше возможностей (и большего упрощения для программиста), в то же время - отдаляет прикладную программу от WinAPI.
Тут есть некая схожесть в сравнении "си vs асм" и "Борланд vs VS" Многие вещи на Борланд сделать проще, но зато на VS код получается гораздо более легковесным. Особенно заметно на коротких, простых программах: бывает разница - даже кратная.
Например: Нужно менять цвет какого-то компонента на диалоге. У Борланда в свойствах всех визуальных компонентов (насколько помню) просто есть член "цвет". Меняете его - цвет меняется. А в VS для той же цели, скорее всего придётся перехватить обработчик WM_CTLCOLOR (или подобного сообщения) и внутри сделать несколько больше телодвижений. Понятно, что визуальная прослойка Борланд внутри делает то же самое. Но это скрыто от программиста.

Более толстая прослойка над GUI, упрощая многие вещи, в то же самое время естественно и ограничивает возможности (свободу) программиста. Примерно как си (по сравнению с асм) ограничивает свободу: в количестве и способах передачи и возврата аргументов в функции; манипуляций со стеком. И си вообще полностью убивает возможность создания самомодифицирующегося кода.
Имхо - Борланд-визуал-API немного проще для начинающих, чем VS. Ниже порог входа.


PS: Или другая аналогия: Борланд - это толстый презерватив, а VS - тонкий. В толстом - безопаснее, но и ощущения совсем не такие яркие.
Кстати и для: си vs асм - аналогия тоже верна. Точнее асм - это вообще без.

[Starichok51]

А в VS для той же цели, скорее всего придётся перехватить обработчик WM_CTLCOLOR

ну да, мне приходилось такое делать.
и кстати, в VS я сначала взялся писать в WinAPI. а когда понял, что там приходится руками до хера писать самому, быстро перешел в классы (MFC).

[Adrift]

[uquote="Starichok51",url="/forum/viewtopic.php?p=4685443#p4685443"]у меня классические MFC-ые.
по крайней мере, диалоги там "начиняются" элементами управления визуально.
и обработчики событий от этих элементов я создаю визуально, щелкая на элементе.
и вижл студио переводится как визуальная студия.[/uquote]
На винде давно рулит .Net, там стандартная библиотека намного богаче плюсовой и перетаскивание компонентов на форму, как в делфи или VB, а сами компоненты рисуются не древним и тормозным GDI, а DirectX, хотя смотря какой тип проекта выбирать. Основной язык разработки по .Net - C#, не важно для новичков или профессионалов. Он проще C++, там сборка мусора и т.д.. MFC умер давно, как и делфи, а как переводится VS вообще без разницы ) Сама VS написана на C#, как и компиляторы для .Net языков.

[Starichok51]

мне для моих простых нужд вполне хватает MFC. и я, как самоучка, и тут далеко не всё знаю и умею. но то, что понадобилось в моих программах, я освоил.
более того, сама студия у меня до сих пор стоит довольно старая - 2005 (восьмерка, под ХР), но в виндоус10 работает прекрасно.