«Вы хочете песен — их есть у меня».
Первый взгляд на схему, страница с питанием, смотрим от начала к концу.
1) Предположим, что DD6 — это bq24296, тогда я бы разместил C71 поближе к ней, чтобы было ясно, что он должен быть размещен как можно ближе к м/сх. Хотя, может быть, в используемой Вами CAD это можно удобно задавать, как требования к разводке.
2) Счетчик кулонов — он Вам действительно нужен? Но это вопрос не к схеме.
3) Дальше вижу 4 источника 3.3 В И если существование двух еще можно понять — один должен питать только счетчик кулонов, а второй — все остальной (хотя и в этом случае можно поставить 1 источник и коммутатор питания, но это вопрос вкуса и денег), то 4 — явный перебор.
4) Причем один из них, вырабатывающий LDO 3.3V (и питающий часы реально времени) не будет работать при разряженном аккумуляторе.
5) Настоятельно рекомендовал бы (хотя платы уже разведены) ставить небольшие резисторы последовательно в цепи i2c, чтобы сразу видеть неисправный прибор, закорачивающий линию (но это дело вкуса и денег, как и небольшие емкости на землю).
6) Я так понял, что МК у Вас никогда не выключается, не уверен, что это лучшее решение, даже с учетом режимов сна.
Полностью поддерживая вывод поста, тем не менее хотел бы отметить, что нет языка Ардуино, а есть:
1) Самый обычный gcc компилятор.
2) Набор библиотек для работы с аппаратурой (DigitalWrite и т.д.).
3) Препроцессор, снимающий с программиста часть механической работы, вроде объявления main, написания #include и т.п.
Интересное наблюдение по поводу применяемой формулы (i*5)/8, которая для вычислений требует 14 команд и 14 тактов.
Сначала я попробовал переписать ее в стиле i/2+i/8, которая потребовала 10 команд и 10 тактов, но это неверная формула.
А вот (i+i/4)/2 дает совершенно правильный результат и при этом требует все те же 10 команд и 10 тактов.
Если бы это решение нашел компилятор… но нет, его нашел человек, так что Вы отчасти правы, компилятору есть куда развиваться.
А по поводу кода, порождаемого компилятором — Вы рассмотрели голую функцию abs, если посмотреть на код, порождаемый для конкретного случая, то многие лишние пересылки исчезают — компилятор научился убирать излишнюю универсальность в конкретных условиях.
Например, для кода на С
int main(int16_t i) {
i=abs(i);
i=(i*5)/8;
return i;
};
в режиме оптимизации -О2 получается
main:
mov r18,r24
mov r19,r25
sbrs r19,7
rjmp .L2
neg r19
neg r18
sbc r19,__zero_reg__
.L2:
mov r25,r19
mov r24,r18
lsl r24
rol r25
lsl r24
rol r25
add r24,r18
adc r25,r19
asr r25
ror r24
asr r25
ror r24
asr r25
ror r24
ret
Обратите внимание, что abs заинлайнилась, что ничуть не хуже написанного руками. Строго говоря, этот фрагмент исполняемого кода полностью совпадает с приведенным Вами, только на С он компактнее и понятнее. «А если разницы нет, зачем платить больше?».
PS. Должен признать, что компилятор не всегда прав, когда я попробовал указать (i*10)/16? он честно добавил еще один сдвиг влево и сразу за ним сдвиг вправо, что меня несколько озадачило. То есть в данном конкретном случае сокращать дробь 10/16 до 5/8 приходится программисту.
Ну что же вопрос задан — надо ответить. Я наивно полагал, что человек, обучающий ассемблеру, должен знать, как осуществляется (на низком уровне) изменение знака числа при представлении отрицательных чисел в дополнительном коде. Вы сами верно указали формулу преобразования (~xxxx)+1. Приведенный Вами код
com valueH ;инвертируем старший байт
neg valueL ;младший -> доп. код
не соответствует приведенной Вами формуле. Для того, чтобы понять свою ошибку, посмотрите, как преобразуется число 0xFF00 (соответствующее десятичному -256), мне почему то кажется, что 0 — не совсем правильный ответ.
А компилятор совершенно любой, я настоятельно рекомендую пользоваться gcc на сайте godbolt, вот ссылка на указанный код godbolt.org. В Ваших обозначениях должно быть:
neg valueH
neg valueL
sbc valueH,__zero_reg__
Между тем, простое
if (Temp<0) {Temp=-Temp; };
решало все проблемы.
А компилятор языка С не «великий и могучий», а написан людьми, которые о системе команд того же AVR забыли больше, чем мы с Вами вместе знаем, так что он генерит совершенно правильный код.
PS. abs здесь не очень нужен, прямой код в данном случае нагляднее.
PPS. Любой современный компилятор и практически любой разработчик.
Я именно тот, кто настаивает, что компилятор сделает все не хуже, а лучше, чем обычный разработчик на ассемблере.
И для начала хотел бы заметить, что для взятия абсолютного значения отрицательного целого надо просто написать i=-i; а не заниматься черной магией с использованием «глубоких знаний» в представлении отрицательных чисел в дополнительном коде.
Ну и как вишенка на торте — автором предложен неправильный способ сделать то же самое в ассемблере, что лишний раз подтверждает — не следует применять его там, где чудесно справится С. Те, кто хотят знать, как это сделать, могут посмотреть генерированный компилятором код для приведенной операции.
Вообще то, АБС вопросы задают, но не отвечают на них, оставляя читателю поле для интерпретаций. Но очень часто ответов (хороших) просто нет — если бы Максим Камерер вовремя успел в зал Музея внеземных культур, то как он мог предотвратить убийство Льва Абалкина (вариант — самому первым убить Сикорски явно не подходит).
Ну я не настолько продвинут в языке оригинала, чтобы менять термины, предложенные программой, написанной носителями языка, хотя, в данном конкретном случае, Вы скорее всего правы, мне почему то «нытье» не пришло в голову.
Нет, не платят, а должны?
Мне кажется, как и автору оригинально поста, что у часть работы, которую можно переложить на плечи компьютера, следует перекладывать, просто потому, что намного проще редактировать уже готовый текст, нежели набирать свой. По моим оценкам, раза в 3-4 быстрее и почему я должен этой возможностью пренебречь?
На мой взгляд, «Трудно быть богом» совсем о другом — о том, что никакие практики морального совершенства неспособны превратить в высшее существо нормального человека — который способен убивать в ответ на убийство близких ему людей.
Цитата из другой книги АБС
существуют на свете носители разума, которые гораздо, значительно хуже тебя, каким бы ты ни был… И вот только тогда ты обретаешь способность делить на чужих и своих, принимать мгновенные решения в острых ситуациях и научаешься смелости сначала действовать, а потом разбираться
Похоже, это какая то бага нового редактора. Конечно, я беру сырой текст из Гугл переводчика и редактирую его. Но снаружи виден исходный текст — фигня какая то.
Что то я не понял, на осциллограмме выходные сигналы линии (AY и BY (BZ?)) имеют задержку относительно входа данных (DI), а выход данных (RO) имеет меньшую задержку и опережает линию?
Вопрос о развязку уже задали, тем более, что у Вас м/сх развязки уже есть, свой маломощный БП уже есть, осталось «начать да кончить».
А вот насчет автоматического включения/выключения передатчика, как у Тексаса, можно надеяться?
Ну если мы говорим о исключении пуш-поп, по компилятор С вполне может провести (и проводит) локальную оптимизацию и часто используемые переменные выносит в регистры, при этом он сам учитывает этот факт при планировании операций с другими переменными.
как Вы сделали на асме, но это не делает данный фрагмент хорошим с точки зрения стиля (магические константы).
Необходимые задержки следует не определять «опытным путем», а брать из документации на используемый электронный прибор, после чего увеличивать их бессмысленно (и поэтому не следует), а уменьшать опасно (и поэтому нельзя). Насколько я помню (хотя могу и ошибаться), у этих индикаторов есть признак готовности и именно им следуем руководствоваться.
И с вероятностью в 90% непостоянные сбои при запуске — это как раз дефекты временных диаграмм, оставшиеся 10% — это нестабильность питания, но в описанном Вам случае вероятнее первое.
Ну как скажете… еще раз подчеркну, что я высказался не против содержательной части представленных программ (это тема отдельного разговора и тоже непростого, если пожелаете) а исключительно против стиля написания.
Сначала о второй части Вашего комментария — про программно реализованную задержку. Само по себе это не преступление, например в Linux короткие (относительно 1/HZ) задержки реализованы именно на циклах и никто по этому поводу не комплексует. Но я категорически против неправильных объяснений вроде
Чтобы их можно было задействовать в основной программе для каких-то других целей, прерывания на время задержек запрещаются
Любая программа обработки прерываний должна начинать с того, чтобы сохранить используемые ею ресурсы общего назначения и должна их восстановить перед завершением. Другое дело, что возможное прерывание удлинит отрабатываемый интервал и именно для этого их и запрещают. Тут возможны два варианта:
1. Автор забыл, зачем сделал запрещение прерываний — неприятно, но не смертельно.
2. Автор скопировал этот фрагмент, не понимая его — ну все бывает, но тогда не следует учить других.
Ну а теперь совсем немного по стилю, просто чтобы подтвердить свою позицию осуждения стиля (на само деле надо все выкинуть и написать заново, но это всегда справедливо, я даже к исходникам Linux придираюсь.
Нам постулируют необходимость реализации задержек в 150мкс, 5мс и 500 мс, особенно забавляет фраза
они определены опытным путем, и подходят для любых типов дисплеев
(строго говоря, это не совсем/совсем не так, но это по содержанию, так что опустим), затем следует пассаж
Можно сделать одну универсальную процедуру Delay (сэкономив количество команд в коде), но для удобства программирования сделаем три отдельных процедуры задержек:
и (вуаля) перед нами три разные функции. Возможно, в книге показано, к каким именно удобствам приводит нарушение принципа DRY, но лично я таких удобств не знаю. Получение используемых в тексте констант приходится объяснять отдельно в сопровождающем тексте, </sarcasm on> что, несомненно, намного удобнее, чем определить их в тексте программы (через макросы или константные функции) и показать их реализацию </sarcasm off>.
Можно привести еще множество примеров сомнительных (с точки зрения стиля) решений, но проще предложить просто взглянуть на тексты программ под спойлерами и «ты все поймешь и все увидишь сам, ты все поймешь и все увидишь там».
Приводит в замешательство также уверенность автора, что возможность применить в литералах hex представление символа вместо символьного представления доступна только в ассемблере и является его неоспоримым преимуществом перед языком программирования С++ (это не я придумал, это прямо в посте написано).
Ну в общем, если перечислять все, что мне не понравилось, то получится пост подлиннее исходного, хочу в заключение отметить, что подход, заключающийся в следующем абзаце
Отметим, что функция createChar библиотеки LiquidCrystal в отношении OLED-дисплеев Winstar работает не очень надежно (иногда значок просто пропадает при первом включении), и причины мне установить не удалось. Соответствующая ассемблерная процедура (см. далее) не сбоила ни разу.
лично мне представляется сомнительным и это совсем не то, чему (опять таки, по моему личному мнению) следует учить.
Если представленные примеры действительно взяты из книги автора поста, то я категорически НЕ рекомендую ее к прочтению, независимо от моего отношения к ассемблеру. Просто потому, что я вижу примеры плохого стиля программирования, независимо от конкретного языка.
Интересно, автору не приходила в голову мысль, что власти в РФ просто нечего сказать умной аудитории, поэтому она с ней и не говорит, или приходила и он ее старательно изгонял.
Не устаю удивляться изобретательности программистов, которые, вместо того, чтобы сделать нормальный развитой препроцессор для С(С++), изворачиваются с шаблонами, заставляя их делать то, для чего они не очень приспособлены. К сожалению, это разные программисты.
Первый взгляд на схему, страница с питанием, смотрим от начала к концу.
1) Предположим, что DD6 — это bq24296, тогда я бы разместил C71 поближе к ней, чтобы было ясно, что он должен быть размещен как можно ближе к м/сх. Хотя, может быть, в используемой Вами CAD это можно удобно задавать, как требования к разводке.
2) Счетчик кулонов — он Вам действительно нужен? Но это вопрос не к схеме.
3) Дальше вижу 4 источника 3.3 В И если существование двух еще можно понять — один должен питать только счетчик кулонов, а второй — все остальной (хотя и в этом случае можно поставить 1 источник и коммутатор питания, но это вопрос вкуса и денег), то 4 — явный перебор.
4) Причем один из них, вырабатывающий LDO 3.3V (и питающий часы реально времени) не будет работать при разряженном аккумуляторе.
5) Настоятельно рекомендовал бы (хотя платы уже разведены) ставить небольшие резисторы последовательно в цепи i2c, чтобы сразу видеть неисправный прибор, закорачивающий линию (но это дело вкуса и денег, как и небольшие емкости на землю).
6) Я так понял, что МК у Вас никогда не выключается, не уверен, что это лучшее решение, даже с учетом режимов сна.
1) Самый обычный gcc компилятор.
2) Набор библиотек для работы с аппаратурой (DigitalWrite и т.д.).
3) Препроцессор, снимающий с программиста часть механической работы, вроде объявления main, написания #include и т.п.
Сначала я попробовал переписать ее в стиле i/2+i/8, которая потребовала 10 команд и 10 тактов, но это неверная формула.
А вот (i+i/4)/2 дает совершенно правильный результат и при этом требует все те же 10 команд и 10 тактов.
Если бы это решение нашел компилятор… но нет, его нашел человек, так что Вы отчасти правы, компилятору есть куда развиваться.
А по поводу кода, порождаемого компилятором — Вы рассмотрели голую функцию abs, если посмотреть на код, порождаемый для конкретного случая, то многие лишние пересылки исчезают — компилятор научился убирать излишнюю универсальность в конкретных условиях.
Например, для кода на С
в режиме оптимизации -О2 получается
Обратите внимание, что abs заинлайнилась, что ничуть не хуже написанного руками. Строго говоря, этот фрагмент исполняемого кода полностью совпадает с приведенным Вами, только на С он компактнее и понятнее. «А если разницы нет, зачем платить больше?».
PS. Должен признать, что компилятор не всегда прав, когда я попробовал указать (i*10)/16? он честно добавил еще один сдвиг влево и сразу за ним сдвиг вправо, что меня несколько озадачило. То есть в данном конкретном случае сокращать дробь 10/16 до 5/8 приходится программисту.
А компилятор совершенно любой, я настоятельно рекомендую пользоваться gcc на сайте godbolt, вот ссылка на указанный код godbolt.org. В Ваших обозначениях должно быть:
Между тем, простое решало все проблемы.
А компилятор языка С не «великий и могучий», а написан людьми, которые о системе команд того же AVR забыли больше, чем мы с Вами вместе знаем, так что он генерит совершенно правильный код.
PS. abs здесь не очень нужен, прямой код в данном случае нагляднее.
PPS. Любой современный компилятор и практически любой разработчик.
И для начала хотел бы заметить, что для взятия абсолютного значения отрицательного целого надо просто написать i=-i; а не заниматься черной магией с использованием «глубоких знаний» в представлении отрицательных чисел в дополнительном коде.
Ну и как вишенка на торте — автором предложен неправильный способ сделать то же самое в ассемблере, что лишний раз подтверждает — не следует применять его там, где чудесно справится С. Те, кто хотят знать, как это сделать, могут посмотреть генерированный компилятором код для приведенной операции.
Мне кажется, как и автору оригинально поста, что у часть работы, которую можно переложить на плечи компьютера, следует перекладывать, просто потому, что намного проще редактировать уже готовый текст, нежели набирать свой. По моим оценкам, раза в 3-4 быстрее и почему я должен этой возможностью пренебречь?
Цитата из другой книги АБС
Вопрос о развязку уже задали, тем более, что у Вас м/сх развязки уже есть, свой маломощный БП уже есть, осталось «начать да кончить».
А вот насчет автоматического включения/выключения передатчика, как у Тексаса, можно надеяться?
В программе на С++ Вам никто не мешает написать
как Вы сделали на асме, но это не делает данный фрагмент хорошим с точки зрения стиля (магические константы).
Необходимые задержки следует не определять «опытным путем», а брать из документации на используемый электронный прибор, после чего увеличивать их бессмысленно (и поэтому не следует), а уменьшать опасно (и поэтому нельзя). Насколько я помню (хотя могу и ошибаться), у этих индикаторов есть признак готовности и именно им следуем руководствоваться.
И с вероятностью в 90% непостоянные сбои при запуске — это как раз дефекты временных диаграмм, оставшиеся 10% — это нестабильность питания, но в описанном Вам случае вероятнее первое.
Сначала о второй части Вашего комментария — про программно реализованную задержку. Само по себе это не преступление, например в Linux короткие (относительно 1/HZ) задержки реализованы именно на циклах и никто по этому поводу не комплексует. Но я категорически против неправильных объяснений вроде Любая программа обработки прерываний должна начинать с того, чтобы сохранить используемые ею ресурсы общего назначения и должна их восстановить перед завершением. Другое дело, что возможное прерывание удлинит отрабатываемый интервал и именно для этого их и запрещают. Тут возможны два варианта:
1. Автор забыл, зачем сделал запрещение прерываний — неприятно, но не смертельно.
2. Автор скопировал этот фрагмент, не понимая его — ну все бывает, но тогда не следует учить других.
Ну а теперь совсем немного по стилю, просто чтобы подтвердить свою позицию осуждения стиля (на само деле надо все выкинуть и написать заново, но это всегда справедливо, я даже к исходникам Linux придираюсь.
Нам постулируют необходимость реализации задержек в 150мкс, 5мс и 500 мс, особенно забавляет фраза (строго говоря, это не совсем/совсем не так, но это по содержанию, так что опустим), затем следует пассаж и (вуаля) перед нами три разные функции. Возможно, в книге показано, к каким именно удобствам приводит нарушение принципа DRY, но лично я таких удобств не знаю. Получение используемых в тексте констант приходится объяснять отдельно в сопровождающем тексте, </sarcasm on> что, несомненно, намного удобнее, чем определить их в тексте программы (через макросы или константные функции) и показать их реализацию </sarcasm off>.
Можно привести еще множество примеров сомнительных (с точки зрения стиля) решений, но проще предложить просто взглянуть на тексты программ под спойлерами и «ты все поймешь и все увидишь сам, ты все поймешь и все увидишь там».
Приводит в замешательство также уверенность автора, что возможность применить в литералах hex представление символа вместо символьного представления доступна только в ассемблере и является его неоспоримым преимуществом перед языком программирования С++ (это не я придумал, это прямо в посте написано).
Ну в общем, если перечислять все, что мне не понравилось, то получится пост подлиннее исходного, хочу в заключение отметить, что подход, заключающийся в следующем абзаце лично мне представляется сомнительным и это совсем не то, чему (опять таки, по моему личному мнению) следует учить.