andy8mm Пост: 297408 От 26.Mar.2011 (15:33) ДедИван, да, пора наступить на мк-грабли.
Надеюсь подключатся спецы по контроллерам, живее будет и всем интереснее.
Давайте отделим котлеты от мух.
По контроллеру все сюда.
dedivan Пост: 355879 От 09.Mar.2012 (14:35)
Есть предложение для тех кто пишет пограммы сам.
Объединить усилия по написанию библиотеки макросов.
У меня есть кое какие наработки- давайте обсудим.
Двумя руками ЗА !!! Хоть толку от меня и всего ничего...........
Деда, хорошая идея, но я ничем не смогу помочь, потому как пишу на отверженном языке. у меня свои наработки, вот их и пользую, и получается кстати не намного медленнее чем у ВАС
Kasper Пост: 355882 От 09.Mar.2012 (14:40)
у меня свои наработки, вот их и пользую,
Да, наработки это самая страшная штука.
Многие сидят на древнем 51 ядре, только потому, что есть наработки.
Именно наработки съедают основное время например библиотеку макросов собрать надо годы- но дальше проще, по готовому програмку накидать уже и часа много.
Вот именно поэтому и предложение - вместе навалиться на тяжелый камень.
Но для этого нужны начальные соглашения- именно их и хотелось обсудить для начала.
Это в принципе почти то же самое что и разработчики компиляторов
делают в самом начале- определяют стандартные способы передачи
аргументов в функции .
Этим и отличаются различные компиляторы для одного и того же языка друг от друга.
Деда а в чем ты тут кстате увидел тяжелый камень? об какой прошивке идет речь? для какого именно процесса, Я их наклепал уже с дюжину... и для Егр и Нанозжигалки и Начал уже хороший кусок для Моновпрыска.
Так а что толку? народ как сидел ждал готовенького так и сидит....
Некоторые обсирают теорию даже не попробовав...
А мне от тебя помощи видимо не дождаться.....
Ратуешь за ассемблер, а комментарии пишешь как в С++
Это шутка юмора такая
Я в принципе не против, но много всяческих "но" вылазит. Если-бы мы это на "С" делали, тогда понятно, такая библиотека нужна, хотя в и-нете их как собак нерезанных, под всё что хош. А для проекта на асме, это как карта ляжет
// R15= ZERO=0b00000000 готовый нуль
// R14= ED =0b11111111 готовая единица
Выиграть по одной одно-тактовой команде (CLR & SET) за "счастье" потери 2-х регистров ? У меня например, младшие регистры активно используются в прерываниях, как СОЗУ и хранители флагов алгоритма. Флаги - это битики такие, кто не в курсе ...
// R0,R1 для чтения из памяти,
Дык эта, они-ж вроде как в командах умножения участвуютЪ ?! А вдруг в прерывании чего-ни-ть понадобится перемножить, что-бы рез-т загрузить в таймер, как у меня было ? Тогда как ?
.macro INTER_TABLE // одним макросом устанавливаем таблицу прерываний,
// но для каждого проекта она будет разной
Деда, ведь таблица прерываний берётся из ДШ !? На тиньки их несколько видов, на меги уже другие, и т.д. Т.е. в _одном_ макросе это учесть очень сложно, да и смысл её ложить в макрос, если придётся в нём-же и править для открытия нужных векторов ?!
.macro WR_EEPROM
cli
Запретили в макросе прерывания, запись "подвисла" на ожидании, а тут вдруг приспичило сосчитать искру в пачке, - и прерывание тю-тю т.е. пере-искрим, и эта лишняя искорка нам может потом вылезти ... через карб Такого типа макросы я оформляю в под-программы, и там никакого cli, кому надо, тот и прерывает ...
ДедаВаня, - может вместе с наработкой макросов подробненько обсудим _функционал_ ?
1. инициализация портов
2. инициализация периферии
3. прерывания
4. связь со вторым МК, т.е. сервисным
5. исполняемые команды от сервисного и их состав
6. обсчёт оборотов и октана
7. диагностика
JohnZ Пост: 355900 От 09.Mar.2012 (17:48)
Ратуешь за ассемблер, а комментарии пишешь как в С++
Во, нормальный разговор пошел. Спасибо.
Ага, это тоже мое предложение - компилятор кушает и слэши и двоеточия,
но я плохо отличаю двоеточие от точки с звпятой, и точка с запятой
неудобно расположена на русской раскладке, а именно на ней комменты пишем. Так что слэши имхо удобнее.
Выиграть по одной одно-тактовой команде (CLR & SET) за "счастье" потери 2-х регистров ? У меня например, младшие регистры активно используются в прерываниях, как СОЗУ и хранители флагов алгоритма. Флаги - это битики такие, кто не в курсе ...
Так зачастую именно одного такта и не хватает чтобы заменить кусок жесткой логики тараканом. То есть это предложения можно сказать по экстремальному программированию.
А для всех остальных случаев есть стэк.
R0,R1 ....Дык эта, они-ж вроде как в командах умножения участвуютЪ ?!
Ага, в мегах. Но поэтому и оставляем их в покое.
Деда, ведь таблица прерываний берётся из ДШ !? На тиньки их несколько видов, на меги уже другие, и т.д. Т.е. в _одном_ макросе это учесть очень сложно,
Ага, получается макрос местного применения, только в данном проекте.
Просто сам код не загораживается.
.macro WR_EEPROM
cli
Запретили в макросе прерывания, запись "подвисла" на ожидании, а тут вдруг приспичило сосчитать искру в пачке, - и прерывание тю-тю
Тут строго - во время записи во флэш- никаких прерываний
четыре такта. Согласен, переставить надо после ожидания готовности.
ДедаВаня, - может вместе с наработкой макросов подробненько обсудим _функционал_ ?
1. инициализация портов
2. инициализация периферии
3. прерывания
4. связь со вторым МК, т.е. сервисным
5. исполняемые команды от сервисного и их состав
6. обсчёт оборотов и октана
7. диагностика
Хм... А как можно отределить косяки в компилере, если собранная прога работает как и задумывалось ? Разве есть такая необходимость ? Это-ж в его внутренности лезть надо... А смысл ?
Да это просто- загружаешь в студию хекс, она маленько подумает, и получаешь
ассемблерный листинг.
Вот по нему и смотришь а как он это нахомутал - там обычно лишние петли сразу видно.
Компилятор делается под все случаи жизни, с запасом, типа с презервативом на морковке, может в любом пустячном прерывании запихивать все регистры в стэк,
Как только увидишь колонку пушей и пупов - там и смотри , а нафига это надо.
Всё правильно, дедаВаня, именно так он и работает, презиком на морковке
Когда я разбирался с протоколом USB для своего прогера, я так и делал с готовым хексом, и только так и удалось найти косяк в проге и частично в компилере. С одного исходника хексы не совпадали, вот и пришлось лазить "на коленках" Баг в компилере конечно-же поправили, но это было потом ...
По поводу соглашений - я в принципе "за", но честно признаться я не совсем сторонник именно макросов. Мне ближе юзать и создавать библиотеки под-программ. Это видимо сказывается опыт "С" Там стандартизация на высшем уровне, IMHO. Правда за это приходится платить "лишними" CALL & RET, но во-первых это не всегда так-уж и дорого, а во-вторых вызов нужной функции предусматривается там, где быстродействие от этого не "пострадает" Формат вызова и возврат ес-сно стандартизуются, как в библиотеке макросов. В принципе нам ведь никто не запрещает юзать оба соглашения по макросам и библиотечным функциям ?!
JohnZ Пост: 356062 От 10.Mar.2012 (15:58)
В принципе нам ведь никто не запрещает юзать оба соглашения по макросам и библиотечным функциям ?!
Естественно, но это вопрос стратегический.
Возьми ПИКи - у них есть PIC10, 12, 16,18,24 - это разные ядра, разная разрядность слова команд, разные команды,
и все это для разных применений.
Атмел пошла по другому пути- ядро обшее , но сам пользователь уже может выбирать именно стиль программирования,
конкретно для своих задач. То есть не ядра менять- а менять именно стиль- и получать нужный результат.
Вот тут то как раз большая разница иежду макросом, который вставляется в твой код как родной, и вызовом,
который уже как кусок чужого кода , который вызывается с определенными оговоренными условиями.
Если вспомнить х86- там вообще все с самого начала делалось именно на условиях чужой подпрограммы,
то есть строго- адрес в этом регистре, переменная в этом , результат получишь в том, и никак иначе.
И вся система биос построена точно также, и потом ДОС и винда все работали по этому принципу.
Унификация хорошо- пока это не тормозит основную задачу.
А потом оказалось- процессор молотит на гигагерцах- а прироста не видно. И многие работают до сих пор на 166 пеньках
и не паряться, а все гигагерцы не дают уж очень заметного прироста. И у меня есть машинка на 166ММХ , работает, и я ей доволен.
Вот чтобы не было такого парадокса , Атмел оставил нам возможность пользовать железо на всю катушку.
Грех этим не воспользоваться. Тем более все солидные программы оптимизируются именно на уровне ассемблера,
а все эти упрощенные языки- для разовых поделушек.
Ну тоже нужно, лишний раз не париться, но если серьезное что то...
А что то серьзное писать, и при этом не страдать от мелочности , тут макросы - тоже ничего нового, майкрософт в свое время
сразу начала с макроассеблера, и писали на нем игрушки - шустрили на 30 мгц машинках , без проблемм.
Макрос чем хорош- он у тебя перед глазами- не нравиться- взял поправил, и в тоже время он не загораживает логику программы.
С подпрограммой или тем паче с библиотекой так не поступишь- там есть более глубокие невидимые связи.
А я не люблю когда от меня что то прячут как от малолетнего дурачка.
Так что твой вопрос из серии - а нафига нам 12 пики, давай все делать на восемнадцатых.
А микрочиповцы чего , дураки? Нафига они двенадцатые делали?
Вот на уровне перехода от рассыпухи к тараканам , кстати многие на этом зависли, мое предложение и должно помочь.
То есть это однозначно не уровень файловых систем или баз данных.
Хотя там если посмотреть внимательно - вся основа на нашем уровне.
То есть начинается все с АА55. Там никаких Сей и Васиков.
Это все на уровне - вот мне лень расстегивать штаны чтобы поссать.
Переделайте мне штаны.
Так для этого есть фирмы, которые выпускают памперсы - это к ним.
Вот примерно там все васики и коденвижены.
Но с ними ты не сможешь написать струйкой на снегу слово - здесь был Вася.
Вот где то такое мое имхо.
т.е. пере-искрим, и эта лишняя искорка нам может потом вылезти ... через карб 
