Dmitry__ писал(а):
Ну, дык, программирование и делится на программирование железа (оно у вас есть в роботе?) и программирование остального.
Если тебя это пугает, значит вас должно быть 2: Ембеддед программист и программист белоручка.
Ясен перец, что программистов должно быть два. API (интерфейс прикладного уровня) - это то, что разделяет работу embeded программиста, и прикладного программиста. Только в данном случае embedded программист схалтурил, и на места его халтуры я и указываю. API кривой, документация на API крайне неполная. Я, как программист-прикладник, крайне возмущён
И каждый программист "белоручка" меня поймёт, надеюсь. А некоторые embeded программисты будут защищать собрата, типа "да и так сойдёт".
Dmitry__ писал(а):
kran писал(а):
Даже если без таких вещей не обойтись, их надо прятать в функции или макросы, которые надо убирать из файла программы.
Нельзя спрятать прыжок на бутлоадер в функцию, т.к. потом этот бутлоадер делает харакири всем стекам и кучам СЫ
Я же написал - "в функции ИЛИ МАКРОСЫ". Я понимаю, что не всё можно запихать в функцию. Хотя в данном случае, если постараться... Есть соглашения о вызовах, где можно стека избежать. Есть такие функции, которые не предусматривают возврата из них. С этим в Си всё нормально, не надо на него капать.
И чтобы компилятор чего-то там лишнего не убрал, есть директивы препроцессора, есть опции оптимизации - всё можно сделать по-людски и аккуратно, если к этому стремиться, и уметь.
Ладно, без обид, это вечный спор железячников и "белоручек", не будем холивар разводить. Пришли вроде к общему мнению, что это пока заготовка, именно как заготовка она совсем не плоха, может даже и вполне себе хороша. Работать с этим можно, но вот именно что надо не просто дорабатывать, а "с нуля" (со скелета) писать готовую программу. Потому что программы-то там и нет. Никакой логики роя нет ещё пока. С этим моим умозаключением все согласны, товарищи железячники?
А на счёт того, что такие вещи на C++ не пишут... Ну вообще-то надо к этому стремиться (и даже к более высокоуровневым языкам, скриптовым, специальным, заточенным под прикладную область). С++ потом можно транслировать в Си, который AVR прожуёт. Программа от этого только выиграет, по-моему, в смысле понятности для простых смертных. Опять же, если места в памяти будет мало, и оптимизирующий компилятор не справится, то квалифицированный embedded программист может вручную оптимизировать то, что "накорявит белоручка".
В данном же конкретном случае я не против писать на аккуратном Си. Где все магические константы и ассемблерные вставки будут определены через макросы, снабжены понятными комментариями. Аккуратный Си очень похож на C++, вместо классов можно делать структуры с функторами, и разница почти незаметна. Прикладник должен иметь возможность писать как-то так (очень примерно):
Код:
turn(LEFT, 5);
int red1 = saw_light(RED);
if (red1 > red0)
{
say("Saw %s %d", RED, red1);
move(FORWARD, 10);
}
else
{
turn(RIGHT, 10);
}
А если вместо этого расставлять битовые флаги со смещением, ассемблерные вставки делать, массивы заполнять... За всем этим очень сложно будет увидеть чистую логику поведения. Неужели тут есть желающие с этим поспорить? Всем ведь очевидно, что вышеупомянутый код понятнее, чем вот такое:
Код:
kprints("Saw ");
kprints(RED);
kprints(", ");
kprinti(itoa(red1));
set_motor(cw_motor,ccw_motor);
_delay_ms(10 * 1000);
set_motor(0,0);
Это я ещё не весь фрагмент искорявил, а только содержимое секции if, где всего две строчки.
Вход
Регистрация
FAQ
Поиск
ааааааааааааааааааа" - когда они действительно нужны, использовать их совсем не проблема.
я его уже начал делать)