В тему будет.
Почему я не люблю "обьектроориентированное" и GCC в частности ?
потому что я программист старой школы, когда ЭВМ занимали многие залы, а памяти было 4к на все кодло это раз.
Так вот тогда тебя учили ДУМАТЬ ГОЛОВОЙ как процессор все это исполнять будет. Это два.
Сейчас этому не учат. вообще.
сейчас программер в Винде вообще оторван от работы с прерываниями!
в "сях" студентов учат какие функции что значат...
Смотрю на проги "укуренных индусов" и хочется их повесить показательно на столбах, за то КАК написан код...
Да, я пишу на "С" но "Кернигана и Ричи", в котором нет никаких надстроек и "обьектов" !
И пишу я так чтобы точно знать что вот этот код компилятор положит вот так на машинные коды, а вот этот кусок кода - вот так.
Почему не ассемблер ? старый я стал, ленивый, быстрее мне писать на С чем помнить и раскладывать простыни где в каких регистрах у меня чего лежит.
Этим пусть роботы занимаются - компиляторы. Они железные и память у них хорошая.
А где надо - там мы куски кода на Асме положим, чтобы на 100% знать что будет и чего не буде происходить.
И еще почему я очень не люблю "последовательный обмен по шине"(любой) и флешки и USB в частности.
Потому что в флеше есть всего 100тысяч перезаписей. Всего. Потом идет сбой записи, и если твой "контроллер" (а у вас их нет - у вас чьи-то чужие проги-драйвера) не понимает что с этим делать, то ты получаешь хороший лаг в лучшем случае, а в худшем зависание системы которая чего-то ждет.
Еще одна проблема о которой не пишут - в самих микросхемах флеша есть ДВА ПРОТОКОЛА:
1) последовательный дебильный, который все выпускают в USB потому что так проще и писать ниче не надо особо - просто уровнями преобразовать и проверок пачку по дороге от флеша к USB и процу за ним. Всё!
2) последовательно-паралельный, в котором 4 бита одновременно передавать можно. Этот протокол раз в 10-100 быстрее, но этож напрягаться надо, думать, проги писать, а самое главное что он не ложится на обмен USB без танцев и приседаний. Неа... не применяют его никто...
Ну и наконец - из личного опыта и опыта людей писавших "на низком уровне" обен и запись телеметрии в флеш: иногда, но довольно повторяемо и часто, при записи во флеш возникает лаг(задержка) которая раза в 3-5 превышает "написанное в даташите". Правило ее появления ХЗ, = случайность. Но если ты с последовательным обменом сидишь и "на лету" пишешь в флеш то получи фашист гранату...
Важно помнить: любой последовательный обмен на любой скорости ЭТО ОЖИДАНИЕ чего-то в процессе передачи. А у нас реалтайм! нам нельзя никого ждать кроме своих АЦП и портов через которые мы "видим" то чем мы управляем!
AlexSoroka Пост: 458668 От 13.Jan.2015 (20:19)
Почему не ассемблер ? старый я стал, ленивый, быстрее мне писать на С чем помнить и раскладывать простыни где в каких регистрах у меня чего лежит.
И я тоже старый и ленивый. Но пользую для тараканов макросы.
Они сами потихоньку копятся, от каждой разработки что то остается.
Пользоваться ими просто, даже если чего забыл- глянешь код макроса - аа вон оно чо..
Так это уже почти наполовину Си- та же библиотека макросов, те же функции, но хэндмэйд а не китайская штамповка.
А ручками можно и всякие фокусы делать.
Вот за это я и люблю свой асм.
Важно помнить: любой последовательный обмен на любой скорости ЭТО ОЖИДАНИЕ чего-то в процессе передачи.
Прям таки в ступор впал ... при аппаратном приёмнике-передатчике ничего ждать не нужно: вытолкнул данные наружу а там хоть трава не расти...
Для отсутствия таких сбоев связи просто нужно добиться, чтобы время передачи данных АЦП было меньше ожидания на самом АЦП, по крайней мере я именно так делал.
_________________ Человек отличается от обезьяны умением не замечать очевидных вещей.
Greyver Пост: 458678 От 13.Jan.2015 (23:27)
... при аппаратном приёмнике-передатчике ничего ждать не нужно: вытолкнул данные наружу а там хоть трава не расти...
Ждут, еще как ждут. Флажок должен выставить узел, что готов принять ,
что разрешена запись в буфер. Кстати у ЮСБ буферы аж до многих килобайтов доходят. Ты думаешь что комп уже все принял, во всем в курсе, что сейчас скомандует что делать- а там еще и хрен не ночевал.
Сказки то помнишь- как гонца к царю перехватывали- напоили, накормили, спать уложили... а потоим и родила царица в ночь
не то сына не то дочь.
Реалтайм он и есть реалтайм.
SunSB Пост: 458622 От 13.Jan.2015 (14:46)
Дискутировать я не буду. Это мне ни к чему. Да и не к месту здесь.
А коль ты так агрессивно настроен, просто напиши, что ты моим бейсиком ни под каким соусом пользоваться не будешь. Ок?
"Он матом не ругается, он на нем разговаривает"
Не обращай внимания.
ЗЫ: А моя отладочная платка на STM32F205RG так и не ожила, все некогда..
Поморгала и спряталась в дальний угол.. жалко, мощная машинка, ресурсов прилично..
Мне довелось столкнуться с некорректной работой компилятора - хитрый глюк со стеком при формировании массива и одновременном уходе в прерывание получается (проц.: Mega48)... В общем - пишу на ассемблере теперь (первый проект). А вот как деду Ивану удаётся Си-подобные функции в макросы преобразовать - мне не понятно: вот нужно к примеру "if" банальный реализовать - значит после сравнения будет стоять команда на прыжок, если условие не выполнено - прыгаем, если выполнено - исполняем код в следующей строке. Так вот - прыгаем на какую то метку - как её в нужном месте макросом поставить? Пока я вижу выход лишь в написании своего "транслятора" Си-подобного языка в ассемблер.
В любом виде деятельности есть знания и есть культура. Знания дают книжки, институты итд. Культуру дают только опыт и Учитель.
Если нет культуры нихрена хорошего не сделаешь и удовольствия от работы не получишь.
Объектное программирование - это лучшее, что есть в программировании. Если готовить его не умеешь ( а это и есть культура ), то понятно - оно гавно. Индусы не умеют, суют классы/объекты куда конь не совал.
Я первую Дедову схему паял - всё верно, все блоки работают, а всё вместе-хрен. А всё просто - провода короче нужно сделать. Но в схеме этого нету. Для Деда это само собой разумеющаяся часть культуры деятельности, для меня - это открытие. Теперь прежде чем повторять твои, Дед схемы, я 42 раза перечитываю букварики ищу культурные намёки))
Так что спор про ардуину - он совершенно не конструктивный, никуда не ведущий.
Хочешь писать на асс - дык не проблема.
Опять же всё от задачи зависит.
Я последний раз на уровне железа много программировал еще на ДВК, если кто в курсе. Это дописишное время. Потом на PC под MSDOS, но чуток совсем и для себя, для общего развития. Так что сейчас я не вспоминаю как это делается а учусь с нуля. Но имея некоторый культурный запас)).
Вот простой пример из Дедовой зарядки. Считываю АЦП много раз. Дальше можно по Найквисту (тру ассемблер, со сдвигами и без деления), можно просто усреднить. И вот оно но.
По Найквисту - нужо насобирать определённое количество семплов, и только потом их обработать. Т.е. вывод на экранчик я должен синхронизировать с готовностью данных. Получается частота обновления экранчика будет зависить от частоты зарядных импульсов? Можно конечно нагородить промежуточное сохранение, перерасчёт и прочее, т.е. усложнить программу и увеличить объём данных. Оно мне надо?
В случае простого усреднения всё во много проще - синхронизация по обновлению экрана. Пора выводить - нет проблем: поделил сумму АЦП на количество собранных семплов и усе. Точность на разных частотах будет разная, но это устройство в любом случае даёт лишь качественную оценку.
Чуток о реальном времени. Где оно здесь? В принципе? Я не вижу.
Реальное время, в моём понимании, это когда есть некий внешний процесс которому подчинены все действия программы.
Простой пример: в компьютерных играх, в видеопроигрывателях(программах) вывод на экран можно делать только во время обратного хода луча по монитору. Иначе рвать картинку будет. Это да, это оно, реальное время.
Успел картинку сформировать, положил в видеопамять пока луч взад шел - ура. Неуспел, вывел во время развёртки - порвал картинку, пропустил кадр - лаг.
Где в зарядке внешний процесс? Бульбашки пошли? Напряжение зарядки вниз пошло? Ну замечу я это на 100млс позже. И чего?
USB
У ардуины с точки зрения программиста нету USB. Дырка есть, а USB нет. Есть последовательный порт. А с ним работать просто: готовишь строку размером меньше буфера, пишешь в неё всякое, как размер к 100 байтам подбирается отправил в порт, вызвал flush() - чтоб ардуина умной себя не считала - и забыл. Чтение из порта тоже просто: есть в буфере данные - вызвал readln() и обработал.
Без прерывания, тупо в главном цикле. Потому как у атмеги запрет прерываний глобальный.
Урезанный С
Вот ардуиновский main
#include <Arduino.h>
//Declared weak in Arduino.h to allow user redefinitions.
int atexit(void (*func)()) { return 0; }
// Weak empty variant initialization function.
// May be redefined by variant files.
void initVariant() __attribute__((weak));
void initVariant() { }
int main(void)
{
init();
initVariant();
#if defined(USBCON)
USBDevice.attach();
#endif
setup();<- это то что в скетче
for (;; ) {
loop(); <- это то что в скетче
if (serialEventRun) serialEventRun();
}
return 0;
}
Можно его переписать, подкорректировать. Никаких проблем. Читал статейку, там мужик рассказывал как ардуину сделать многозадачной если припечёт.
Другое дело, что оптимизатор работает несколько, ммм, странно. Так это помоему не исключительно для ардуины, а гораздо глубже. Проделки менагеров по недопущению хорошего свободного компилятора. Или всё проще, компилятор индусы писали )).
Фух. Устал, пойду спаяю кнопки для новой зарядки:).
Если у 90 семейства проблемы с переходами и возвратами, значит их или слишком много или кто то не посмотрел в сторону. Фьюзов. Не знаю как сейчас на 8515 фьюзом выставлялась глубина стека для вызова подпрограмм. На атиньке 16 эта вещь была фиксирована и получалось или три вложения или сложить два дробных. По большей степени не понимание логики работы желёзки.
З.ы. если выкинуть прошивку ардуины не плохие кит получается.
Запрети прерывания.
Ассемблер для программиста необходим. Он приучает думать в терминах железки. После ассемблера, многие распространееные ляпы просто исчезнут из твоих программ. Но писать на нем в разы сложнее, потому как переходишь с уровня "логика моей программы" на уровень "логика вашей железки". А железку придумывали тоже люди со своими культурой и тараканами, и приходится играть на чужом поле.
Любой транслятор отличная вещь. Не зря все action игры на скриптах написаны. Так отделяют логику игры ( устройства ) от движка. По этому игровых движков в мире всего штук пять, а игр как ... Ну вы поняли.
Запрети прерывания.
Ассемблер для программиста необходим. Он приучает думать в терминах железки. После ассемблера, многие распространееные ляпы просто исчезнут из твоих программ. Но писать на нем в разы сложнее, потому как переходишь с уровня "логика моей программы" на уровень "логика вашей железки". А железку придумывали тоже люди со своими культурой и тараканами, и приходится играть на чужом поле.
Любой транслятор отличная вещь. Не зря все action игры на скриптах написаны. Так отделяют логику игры ( устройства ) от движка. По этому игровых движков в мире всего штук пять, а игр как ... Ну вы поняли.
подпишусь под каждым словом. без понимания до уровня транзистора хорошей железяки не сообразишь... но увы...
airman Пост: 458693 От 14.Jan.2015 (05:55)
Мне довелось столкнуться с некорректной работой компилятора - хитрый глюк со стеком при формировании массива и одновременном уходе в прерывание получается (проц.: Mega48)...
а вот нехуй массивы через стек передавать!
Верх маразма...
Это где вас таких научили так писать проги?
"С" тут не виноват - тут писателю надо по шапке надавать, чтобы головой думал.
А вот как деду Ивану удаётся Си-подобные функции в макросы преобразовать - мне не понятно
Забей. Это "высший пилотаж", и тебе он не нужен - пиши на С на самом простом, без заебов и "красивых описаний", и будет тебе счастье.
Вот простой пример маразма писателей кода:
что делает эта строка?
// Timer/Counter 1 Interrupt(s) initialization
TIMSK1=(0<<ICIE1) | (0<<OCIE1B) | (0<<OCIE1A) | (1<<TOIE1);
открываем h файл:
#define TIMSK2 (*(unsigned char *) 0x70)
для тех кто не умеет читать - строка
TIMSK1=(0<<ICIE1) | (0<<OCIE1B) | (0<<OCIE1A) | (1<<TOIE1);
по сути делает кучу СДВИГОВ бита "1" !!!!!!!!!!!!!
а вот такая строка
ADCSRA|=(1<<ADSC);
влеплена внутри(!) тела цикла работы с АЦП! эта пистец...
я весь этот маразм заменил на ОДНУ команду:
ADCSRA|=0b01000000;
Так что удачи тупорылым применятелям "библиотек ардуины" в своих разработках. У вас все получится ...про реалтайм забывайте сразу.
ахуенный совет !
это спасет от переполнения стека ? ну-ну...
Так отделяют логику игры ( устройства ) от движка. По этому игровых движков в мире всего штук пять, а игр как ... Ну вы поняли.
Как говна. И говностроение процветает именно поэтому - от нежелания думать - щас картинок нарисуем, шнягу по "идее игры" придумаем и вуаля!
очередное глючное говно поехало в тираж - все равно поиграют неделю и забудут, а нам новое говно собирать - чтобы бабло косить снова...
Это всё от того, что ты не знаешь, что операции с константами выполняются на этапе компиляции.
Строки в ассемблере после компиляции для
ADCSRA|=(1<<ADSC);
и
ADCSRA|=0b01000000;
будут одинаковые, но ты через год полезешь в справочник, смотреть что такое "ADCSRA|=0b01000000;", а человек написавший "ADCSRA|=(1<<ADSC);" или
"TIMSK1=(0<<ICIE1) | (0<<OCIE1B) | (0<<OCIE1A) | (1<<TOIE1);" максимум задумается, вспоминая как расшифровываются названия битов.
Вообще говоря, практически у каждого компилятора есть флаг, который позволяет сохранить производимый им ассемблер. Для gcc это -save-temps.
Папробуй. Много интересного узнаешь сначала ты о компиляторе, а потом писатели этого компилятора о своих родителях:).
Зы
А где написано о переполнении? Написано о глюке. Или ты только о переполнении слышал?
Дед, извини, нафлудил тут у тебя не про зарядку.
Но переход на контроллеры он неизбежен. А ниже планки вхождения в контроллеры чем ардуина нет, и вряд ли будет. Незнаю чего Alex так взьелся на эту зверушку, но нельзя ему дать отпугнуть новичков. Да оно кривенькое, да неоптимальное. Но так и Бедини не ангел. А вот моторчик его меня зацепил, и втянул в эту область знаний и я рад теперь, что у меня есть занятие которое приносит удовольствие и не напрягает. В разы лучше чем сериалы дурные смотреть или собирать какиенить пережитки прошлого:).
SunSB Пост: 458727 От 14.Jan.2015 (13:09)
Это всё от того, что ты не знаешь, что операции с константами выполняются на этапе компиляции.
Строки в ассемблере после компиляции для
ADCSRA|=(1<<ADSC);
и
ADCSRA|=0b01000000;
будут одинаковые, но ты через год полезешь в справочник, смотреть что такое "ADCSRA|=0b01000000;", а человек написавший "ADCSRA|=(1<<ADSC);" или
"TIMSK1=(0<<ICIE1) | (0<<OCIE1B) | (0<<OCIE1A) | (1<<TOIE1);" максимум задумается, вспоминая как расшифровываются названия битов.
Я сам себе лучше комент напишу рядом.
Папробуй. Много интересного узнаешь сначала ты о компиляторе, а потом писатели этого компилятора о своих родителях:).
:) я уже туда не лажу - чтобы настроение не портить ...
Зы
А где написано о переполнении? Написано о глюке. Или ты только о переполнении слышал?
:) известные это глюки, "детские" и у тех кто не знает что такое прерывания и как они работают на низком уровне.
Получается так: вызываем функцию, она напискладывает в стек свою "точку возврата", потом проц отрабатывает тело функции и начинает писать массив в стек, в процессе писания происходит прерывание, которое тоже пишет в стек... дальше сами допишите по вкусу...
Лечится просто заменой передачи массива через стек на передачу указателя на массив через статик переменную (если один и тот же массив гоняем) либо вообще массив держим в памяти если постоянно его дергаем - на этом еще экономим "выделение массива - развыделение массива" при каждом вызове функции, а это процессорное время.
Заповедь простая: если ты пишешь прогу и не знаешь как компилятор твое "художественное описание" на С положит в код - пиши тупо и невитиевато, или полезь посмотри в ASM листинг что там наваялось в итоге. ...все равно придешь к простому "Керниган&Ричи" С
это раз.
... при аппаратном приёмнике-передатчике ничего ждать не нужно: вытолкнул данные наружу а там хоть трава не расти... 
дальше сами допишите по вкусу...
Размер : 266.81 KB 