добрый день я время от времени возвращаюсь к изучению мк AVR, начинал знакомство с ними, и с программированием вообще с ассемблера. пока программки были небольшие, до 1-2 кб, мне как то еще удавалось все "разрулить", но чем сложнее программы тем больше понимаю что надо завязывать с этим "линейным" программированием, и как то все иначе организовать.
наверное надо написать свою "библиотеку" функций, более менее универсальных, пожертвовав возможно где-то быстродействием в угоду универсальности и большей скорости разработки. писать на Си и прочих языках высокого уровня я не хочу. ассемблер меня вполне устраивает.
вот и встал вопрос, если писать свои функции, с некоторой долей универсальности, встает вопрос о том как организовать лучше всего обмен между ними, по каким то одним правилам, учитывающим саму специфику архитектуры мк.
то есть, я так думаю что необходимо прежде чем что либо писать принять некие правила, каким образом в функцию передавать значения переменных, к примеру. и вообще нужно ли придерживаться этих правил или нет, нужны ли они? вот как все это организовано в компиляторах, того же Си?
ну и вообще, может кто подскажет, подкинет идеи как писать на ассемблере когда программа становится большой по объему. то есть вопрос как организовать все это, чтобы не увязнуть в коде
а зачем вам знать, как устроено в Си, если Си вы не хотите применять? вот и наслаждайтесь ассемблером в полной мере
а вообще - кто вам законы пропишет, кроме вас самих? определите для себя правила оформления ассемблерных модулей и пишите по этим правилам свои библиотеки. все равно ведь, кроме вас, они вряд ли кому понадобятся...
_________________ если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе при взгляде на многих сверху ничего не меняется...
а зачем вам знать, как устроено в Си, если Си вы не хотите применять?
чтобы почерпнуть идеи из него, возможно
п.с. меня не интересует язык Си как таковой. меня интересуют его компиляторы для avr, а именно по каким правилам и каким образом они передают значения, например как передают значения переменных в функцию, в регистрах, в ячейках озу, в каких именно и так далее
Последний раз редактировалось asdf12 Пн дек 11, 2017 18:46:23, всего редактировалось 1 раз.
Обязательным условием долгой и стабильной работы Li-FePO4-аккумуляторов, в том числе и производства EVE Energy, является применение специализированных BMS-микросхем. Литий-железофосфатные АКБ отличаются такими характеристиками, как высокая многократность циклов заряда-разряда, безопасность, возможность быстрой зарядки, устойчивость к буферному режиму работы и приемлемая стоимость. Но для этих АКБ очень важен контроль процесса заряда и разряда для избегания воздействия внешнего зарядного напряжения после достижения 100% заряда. Инженеры КОМПЭЛ подготовили список таких решений от разных производителей.
Компания EVE выпустила новый аккумулятор серии PLM, сочетающий в себе высокую безопасность, длительный срок службы, широкий температурный диапазон и высокую токоотдачу даже при отрицательной температуре.
Эти аккумуляторы поддерживают заряд при температуре от -40/-20°С (сниженным значением тока), безопасны (не воспламеняются и не взрываются) при механическом повреждении (протыкание и сдавливание), устойчивы к вибрации. Они могут применяться как для автотранспорта (трекеры, маячки, сигнализация), так и для промышленных устройств мониторинга, IoT-устройств.
Я тоже когда-то был ярым приверженцем асма. Но я зарабатываю на разработках. И когда объем программ стал значительно увеличиваться, перешел на си. Переход был мучительным. Несколько раз порывался, бросал. Потом понял, что меня останавливал страх. Перед сложностью, что не получится и так далее. Потом я поступил следующим образом: продолжал писать программы на асме, но читал книги, пробовал. Когда началось получаться полностью перешел на си и остановил все проекты до тех пор, пока более-менее не освоил си. Перенес свои наработки на асме на сишные проекты.
Теперь, оглядываясь назад, жалею, что не начал раньше.
Организация программ не зависит от языка. Обмен между модулями. Прямой обмен переменными, флагами, состояниями конечных автоматов. Посредством службы сообщений.
я не ярый приверженец ассемблера, но мне нравится ассемблер, для меня программирование МК хобби. меня ничто не гонит вперед кроме собственного интереса. что касается Си, я быдлокодил на нем, одно время, под ПК, общее представление имею, но писать на нем под МК мне не интересно. нет того удовольствия которое я получаю от ассемблера
У каждого и свои предпочтения (субъективные) и свои объективные причины использования разных компиляторов в соответствии с поставленными задачами (и средствами/элементной базой, для решения тех задач применяемой). Ассемблер также "разный" бывает (по уровню использования возможностей компилятора)...
тогда до кучи: мощный macro assembler под разные архитектуры (AVR есть) от Alfred Arnold, до сих пор развивается http://john.ccac.rwth-aachen.de:8000/as/ можно WHILE IF / ELSEIF / ENDIF SWITCH(SELECT) / CASE / ELSECASE / ENDCASE и пр.
Интересный проектик... В отношении микрочипа не слишком шикарно, да и АВР только как обобщенное AVR RISC МК, но довольно много "редковстречаемых"... Однако читать надо... моного и долго... Ессно с действующими IDE совместимости... речи бысть не может, дебаггер-отладчик также надо как-то ... "добавлять"... Однако подкупает "единый подход"... и существование до сего дня...
Последний раз редактировалось BOB51 Ср дек 13, 2017 09:15:28, всего редактировалось 1 раз.
в оригинале, вроде, для программистов все понятные слова:
Цитата:
g [format]: This switch instructs AS to create an additional file that contains debug information for the program. Allowed formats are the AS-specific MAP format ( format=MAP), a NoICE-compatible command file ( format=NOICE), and the Atmel format used by the AVR tools ( format=ATMEL). The information stored in the MAP format is comprised of a symbol table and a table describing the assignment of source lines to machine addresses. A more detailed description of the MAP format can be found in section 5.2 The file's extension is MAP, NOI, resp. OBJ, depending on the chosen format. If no explicit format specification is done, the MAP format is chosen.
Так все равно ВЫЧИТЫВАТЬ надо, даже ежли и частично понимаемое. И не только вычитывать, но и сравнивать с уже ранее обработанным. Это не просто "на любителя"... МНДЯАА...
asdf12, я думаю, не стоит расковыривать компилятор Си для изучения идей, стоит разработать конкретно для себя набор правил и потом строго его придерживаться. ................ Мысли старого ретрограда Я тоже кодил на Асме, но у меня был дополнительный стимул: работал на фирму по договору, и ее шеф не очень одобрительно воспринял бы необходимость в каждый прибор в сотнях экземпляров серии совать МК на 1..2$ дороже. Что бы там ни говорили - мол, разница не очень большая - есть она, и достаточно существенная. Пример? Да калi ласка ! Исходя из спектра задач, предстоящих фирме, я разработал "плавучку" нестандартную: один байт порядок, 2 байта мантисса. И когда тестировали по сравнению с Си, "скорострельность" была в 2 с лишним раза выше. Не говоря уже о printf, который тянет под 1кб кода. У меня преобразования для вывода на ЖКИ нужных нам данных (ну не было форматного вывода с форматом, который мог родиться в пьяном бреду сумасшедшого ежика ) уложились в сотню байт. За универсальность плата - избыточность. СпойлерТелепаю возражения: "Гуано твоя плавучка. Когда понадобится складывать разной величины данные, будет большая потеря точности. Может оказаться, что прибавляемые крохи окажутся вообще за пределами разрядной сетки " Ну что сказать - строг, но справедлив. Но ведь и я не совсем лапоть. Для таких редких случаев имелась полноценная 4-байтная float, в которую простенькая прога вливала "крохи". Возражение второе. "Это ж надо додуматься - свою плавучку! Может, ты еще и функции свои писал? Это ж какая прорва времени!" А как же без функций - корень, синус, логарифм. Времени отняло не так много на фоне того, что параллельно разрабатывалось железо, платы, обкатывалась сама концепция изделия. А когда этап арифметики закончен, не нужно же в каждом новом проекте все трясти заново, а написать в исходнике макровызов SIN alfa,x ничуть не затратнее, чем Си-шное x=sin(alfa) . Я не собираюсь в сотый раз затевать религиозную войну "ASM vs C" - каждому - свое, кому поп, кому попадья. Для себя я установил распределение регистров: входной аргумент был в R16, результат в R24,R25. "Неполноченные" регистры R1..R15 отдал под регистровый файл глобальных переменных, из которого любая подпрограмма могла черпать данные. Регистры R17..R23 были рабочими, и их не нужно было сохранять/восстанавливать при входе/выходе в/из п/п - кроме вложенных вызовов, разумеется. И пр. Это, конечно, не канон, но любая, даже не очень хорошая система лучше, чем никакой.
стоит разработать конкретно для себя набор правил и потом строго его придерживаться. но любая, даже не очень хорошая система лучше, чем никакой.
согласен. вот пытаюсь как то выработать для себя эту систему
отходя от собственной темы, хочу задать вопрос хочется попробывать МК с архитектурой ARM, но незнаю как к ней подступиться, хочу писать на ассемблере, но вижу что производители применимо к этой архитектуре навязывают Си, а мне хочется с ассемблера начать. у STM как я понимаю большие "проблемы" с настройкой периферии, необходимо долго возиться с ней, на ассемблере примеров я не находил. хотя и не очень долго искал. вопрос вот у меня, производителей МК с этой архитектурой достаточно как я понимаю, у всех аналогичные проблемы? хочется взять ARM и программировать, а не утонуть в изучении того как тупо дернуть ногой на этом МК. что посоветуете?
Процесс разработки устройства на асме STM32 ничем не отличается от того же на avr или stm8. Время вхождения, конечно, больше, т.к. необходимо осваивать немного более сложную периферию. Зато писать на асме STM32 и быстрее и удобнее чем, например, под avr (ИМХО).
Ну уж ежли ИМЕННО АРМ (а не частности в виде STM32) тогда изучение надо начинать отсюда https://www.arm.com ... А уже затем конкретую разновидность в семействе отрабатывать с изучением даташитов производителя. К тем АРМам не только STM, но и атмел/микрочип и NXP и много кто еще "лапу приложил" (включая российские Ангстрем и Миландр)...
BOB51, я нигде не путал в своем сообщении ARM и STM32, я же так и написал - "производителей МК с этой архитектурой достаточно"
мне самому было бы интересно узнать от опытных людей, МК какого производителя с архитектурой ARM проще в настройках периферии. мне нехватает знания английского и времени на то чтобы шерстить интернет изучать кучу всего от разных производителей чтобы сделать заключение, с чего проще стартануть в ARM. вот ежели бы кто сказал - возьми контроллер этого производителя, он проще всего конфигурируется. но большинство смотрю остановилось на STM, наверное в первую очередь из-за привлекательной цены и периферии. хотя мне как для того для кого это все хобби цена не играет роли, для меня не имеет значения 500р стоит МК или 1500
Ну уж ежли ИМЕННО АРМ (а не частности в виде STM32) тогда изучение надо начинать отсюда https://www.arm.com
Вы в своем уме неуважаемый? Что ты там "изучать" собрался? Не, если начать долгий и нудный путь писанины под асмЪ, то систему команд проштудировать стоит, но основное-это периферия а не ядро. Поэтому и изучают периферию и работу с ней, а не то что тебе взбрендилось.
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения
Вход
Регистрация
Правила
FAQ
Поиск
