Jump to content
a_sergeevich

Язык Си Для Микроконтроллеров

Recommended Posts

1 час назад, COKPOWEHEU сказал:

Все эти фокусы нужны чтобы собирать оптимальный код под любую платформу, используя ее особенности. Поэтому якобы неопределенное поведение (char<<7) вполне можно использовать - если точно известен диапазон платформ.

В данной теме я и говорю не про любые платформы, а про embedded, где по большей мере царят GCC и немного IAR с Keil. Поскольку я вообще ограничен платформой AVR, то в плане переносимости меня беспокоят только эти МК, т.е. ARM, например, не входит в круг моих интересов. И с этой ограниченной точки зрения я высказываю свои суждения. И, как мне кажется, с учетом сказанного только что, вы не поколеблете мою точку зрения никак - я могу все учесть, и стандарт (насколько я его знаю) мне только помогает. Придумывать варианты, когда это может быть не так, мне неинтересно.

1 час назад, COKPOWEHEU сказал:

В Си же для этого придется приводить оба числа к 16-битным со всеми вытекающими последствиями

В Си это уже делается автоматически. Т.е. пример неудачный :)

Только что, ARV сказал:

Поэтому якобы неопределенное поведение (char<<7) вполне можно использовать

Можно. Но приведите мне довод, когда это предпочтительнее (uint8_t << 7), работающее на любых платформах?

Share this post


Link to post
Share on other sites
2 минуты назад, ARV сказал:

платформой AVR

То есть вы не учитываете что байт может быть не 8-битным. А ведь стандарт это не гарантирует. Другое дело что в 99% случаев учитывать это не вижу смысла - разве что добавить

#if (CHAR_BITS != 8)
#error сами мучайтесь с нестандартными системами
#endif
6 минут назад, ARV сказал:

В Си это уже делается автоматически. Т.е. пример неудачный :)

Пример был про эффективность кода (скорость, размер прошивки), а не удобство записи.

7 минут назад, ARV сказал:

Можно. Но приведите мне довод, когда это предпочтительнее (uint8_t << 7), работающее на любых платформах?

Понятия не имею! Сами же говорили что не интересуетесь абстрактными примерами. Сейчас мне тоже неохота  их выдумывать. Разве что когда char используется именно как символ. Ну и писать char все-таки быстрее чем uint8_t.

Share this post


Link to post
Share on other sites
5 минут назад, COKPOWEHEU сказал:

То есть вы не учитываете что байт может быть не 8-битным.

Вы сами не учитываете, что в первую очередь я сам следую собственным советам :) Я всем рекомендовал пользоваться типами строгой размерности С99, поэтому проблема char меня абсолютно не касается - я применяю uint8_t - в соответствии со стандартом С99. 

5 минут назад, COKPOWEHEU сказал:

Пример был про эффективность кода (скорость, размер прошивки), а не удобство записи

В обоих случаях нормальный компилятор сделает нормальный код (при оптимизации). Ну, во всяком случае я в это верю :)

5 минут назад, COKPOWEHEU сказал:

Разве что когда char используется именно как символ

Когда char используется, как символ, его не надо двигать! :)

Подумайте еще, поищите в закромах памяти примеры, когда стандарт вредит :) пока не получается у вас...

Edited by ARV

Share this post


Link to post
Share on other sites

Высококачественные конденсаторы Panasonic для надежности вашей электроники!

Электролитические алюминиевые конденсаторы Panasonic отличаются повышенной надежностью, длительным сроком службы, низким импедансом и выдерживают большой ток пульсаций, в то время как семейства полимерных конденсаторов Panasonic SP-CAP, POSCAP, OS-CON и HYBRID характеризуют сверхнизкий ESR и увеличенная емкость, работа при высоких напряжениях и в расширенном температурном диапазоне. Приобретая продукцию Panasonic, вы гарантированно получаете самое передовое решение для ваших задач. Для облегчения вашего выбора, мы подготовили подборку полезных материалов.

Читать статьи

2 часа назад, ARV сказал:

В обоих случаях нормальный компилятор сделает нормальный код (при оптимизации). Ну, во всяком случае я в это верю :)

Ну, раз верите, что тут возразить.

2 часа назад, ARV сказал:

Подумайте еще, поищите в закромах памяти примеры, когда стандарт вредит :) пока не получается у вас...

Вы сначала приведенные опровергните прежде чем новые требовать.

Share this post


Link to post
Share on other sites
8 часов назад, COKPOWEHEU сказал:

Вы сначала приведенные опровергните прежде чем новые требовать

Позвольте, уважаемый!

Я говорю, что если соблюдать требования и учитывать ограничения стандарта, это повредить не может никак, а скорее (и даже практически однозначно) поможет. Вы приводите аргументы неопределенного поведения и говорите, что может. Но ведь это означает, что вы предлагаете НЕ УЧИТЫВАТЬ неопределенное поведение компилятора по стандарту, что противоречит моим принципам! То есть вы не опровергаете мои подходы, а доказываете свои! Если отказаться от типов с неопределенной размерностью (точнее, с платформо-зависимой), а использовать СТАНДАРТНЫЕ типы С99, количество вариантов undefined behavior, на которые можно нарваться в своих программах, кардинально уменьшается. Аналогично есть возможность СТАНДАРТНЫМИ средствами и разумным подходом к кодописанию ИСКЛЮЧИТЬ все оставшиеся подобные ситуации. Если ТАК НЕ ДЕЛАТЬ - вы безусловно правы. А вот ЕСЛИ ДЕЛАТЬ ТАК - безусловно прав я. Во всяком случае безусловность этого вы не опровергли.

И я не собираюсь вас опровергать, ведь это вы начали возражать моим принципам программирования :) А я согласен, что если делать плохо (в том числе не по стандарту или по выборочным местам стандарта, не обращая внимание на предупреждения о неопределенном поведении компилятора), то можно нарваться на проблемы.

Share this post


Link to post
Share on other sites
                     

Вебинар "Как создать BLE-устройство на базе новейшего беспроводного микроконтроллера STM32WB55"

27 ноября 2019 года компания КОМПЭЛ приглашает разработчиков, технических руководителей и энтузиастов беспроводной связи на вебинар, посвященный новинке 2019 года – мультипротокольному беспроводному микроконтроллеру STM32WB55, который позволяет создавать устройства на базе стандартов BLE 5.0; BLE Mesh; 802.15.4/ZigBee и Thread. На вебинаре мы покажем, как с помощью привычных инструментов STM32Cube и STM32CubeMX можно создать свое первое, надежно работающее BLE-приложение.

Зарегистрироваться на вебинар

В общем случае неопределенное поведение дают:

преобразование float->int (6.3.1.4)

использование внутри #include символов / , \ , ' , " (6.4.6)

даже доступ к полю атомарной структуры (6.5.2.3)

Еще можете посмотреть примеры тут https://habrahabr.ru/post/136283/

https://habrahabr.ru/post/229963/

https://habrahabr.ru/post/230777/

 

Share this post


Link to post
Share on other sites
Только что, COKPOWEHEU сказал:

В общем случае неопределенное поведение дают

И? Договаривайте :) 

Что может заставить программиста использовать в своей программе эти "особенности", кроме лени и неопрятности стиля?

В руководстве к автомобилю написано "не рекомендуется начинать движение на непрогретом двигателе". Это означает, что, в принципе, не запрещено, т.е. можно, но за последствия, если вдруг таковые будут, отвечать придется водителю - его предупредили. Так и здесь: стандарт говорит, что делать-то можно, но надо иметь ввиду неопределенное поведение. И делать это не будет нарушением стандарта, но ЗАЧЕМ так делать?!

Все приведенные вами случаи (и не только они - вообще все, описанные в стандарте) элементарно исключаются из обихода другими стандартными приемами.

Хабрахабр я регулярно читаю, и практически всегда там рассматриваются проблемы, о которых я говорю "хотел геморроя, когда так делал?". Если главное стремление сделать с переподвыподвертом - то и нечего жалиться на побочные эффекты...

Share this post


Link to post
Share on other sites

Вы хотите сказать что никогда не делаете преобразование float->int?

Или не используете относительные пути к подключаемым библиотекам? Хотя бы #include <avr/io.h>

Не верю.

Share this post


Link to post
Share on other sites
Только что, COKPOWEHEU сказал:

Вы хотите сказать что никогда не делаете преобразование float->int?

Читайте внимательнее мои высказывания, и тогда а)вам не придется переспрашивать, и б)мне не придется повторять.

float -> int дает неопределенный результат когда? когда мы, например, пытаемся 1Е12 впихнуть в int. Если мне приходится что-то подобное делать (не припоминаю), я всегда учитываю диапазоны значений (вспоминайте - я уже говорил о контроле переполнений и т.п.). Если я ЗНАЮ, что float у меня не превысит INT_MAX, можно пользоваться подобных преобразованием.

Или вы имеете ввиду явное приведение типов?

Только что, COKPOWEHEU сказал:

Или не используете относительные пути к подключаемым библиотекам? Хотя бы #include <avr/io.h>

Использую, как же. Но так как вы не следите за мыслью, а оспариваете все формально, я вам поясняю: особенность указания путей для конкретной платформы компиляции не порождает ПЛОХО РАБОТАЮЩУЮ ПРОГРАММУ, или НЕАДЕКВАТНО работающую. Все мои рассуждения о пользу стандарта при написании кода направлены именно на избежание проблемы, когда небрежно состряпанная программа работает не так, как задумывалось. Если же путь найден не будет, то и программа скомпилирована не будет, соответственно, никаких проблем в ее РАБОТЕ не возникнет по определению. Что пытаетесь доказать вы - мне неведомо. Сформулируйте свое мнение окончательно, чтобы я хотя бы это смог понять.

Share this post


Link to post
Share on other sites
36 минут назад, COKPOWEHEU сказал:

Вы хотите сказать что никогда не делаете преобразование float->int?

Или не используете относительные пути к подключаемым библиотекам? Хотя бы #include <avr/io.h>

Не верю.

Если Вы находите возможным жаловаться на проблемы реализации преобразования  float->int на С-ях, тут как раз и получается что поколения разработчиков С какие то недоумки по сравнению с Вами, и только Вы поняли их ошибку! :)

И что за проблемы с include как это вообще может быть связано с эффективностью кода, или я опять потерял тему обсуждения???

Share this post


Link to post
Share on other sites
Только что, ruhi сказал:

или я опять потерял тему обсуждения???

Нет, на этот раз в точку! :)

Edited by ARV

Share this post


Link to post
Share on other sites
5 часов назад, ARV сказал:

Использую, как же. Но так как вы не следите за мыслью, а оспариваете все формально

Я оспариваю ваше категоричное высказывание

В 26.10.2017 в 18:35, ARV сказал:

я могу все учесть, и стандарт (насколько я его знаю) мне только помогает.

Использование конструкции #include <avr/io.h> формально является неопределенным поведением.

Может признаете наконец, что в ряде случаев вполне можно положиться на поведение, характерной не для языка, а для конкретного компилятора и платформы.

 

Share this post


Link to post
Share on other sites
21 минуту назад, COKPOWEHEU сказал:

Может признаете наконец

Я так понимаю, женщины вам никогда не отказывают? Ибо вам легче отдаться, чем убедить, что не хочется это делать...

Я стоял и буду стоять на своём: стандарт Си, если его хорошо знаешь, только помогает делать качественные, надежно и правильно работающие программы.

И мне все равно, что в качестве путеводного девиза выбрали вы - я буду руководствоваться собственным. И по мере сил демонстрировать преимущества этого другим.

Share this post


Link to post
Share on other sites

То есть вы не будете использовать <avr/io.h>? Поведение этой записи не соответствует стандарту.

 

Share this post


Link to post
Share on other sites
16 часов назад, COKPOWEHEU сказал:

Поведение этой записи не соответствует стандарту

Если вы сообщите мне, каким образом применение этой строки может изменить поведение моей программы с правильного на неправильное (или непредсказуемое) - не буду. Стандарт говорит, что ему все равно, как компилятор отреагирует на эту строку, он не ОПРЕДЕЛЯЕТ эту ситуацию. На работоспособность кода такое "не стандартное поведение" компилятора (хотя вполне со стандартом - что стандарт не определил, то реализую, как хочу) никак не влияет. И говорить об этом просто бессмысленно.

Share this post


Link to post
Share on other sites

Это может повлиять на компилируемость программы. На других системах может быть другой резделитель директорий, например, обратный слеш. Таким образом, формально этот код не является переносимым.

Поэтому в очередной раз повторяю: помимо стандартов языка есть еще стандарт операционной системы и платформы. Поэтому не стоит бояться UB как огня, достаточно знать его стандартную реализацию распространенными компиляторами и платформами. Собственно, все так и делают.

Впрочем, можно поступить и наоборот: вы приведете достаточный кусок своего кода, а я поищу в нем несоответствия стандарту (хотя не обещаю что будет быстро)

Share this post


Link to post
Share on other sites
21 минуту назад, COKPOWEHEU сказал:

Впрочем, можно поступить и наоборот

Можно, но особого толку не будет, т.к. на русском языке я стандарта не встречал, а те жалкие кусочки, которые я смог уразуметь из английского текста, пока не сделали меня знатоком стандарта. так что я лишь стремлюсь к идеалу :) В основном, о тех или иных аспектах стандарта я узнаю на форумах. Основы "хорошего" я знаю и так, а вот про "плохое" узнаю, в частнсти, от вас.

Однако, как и ранее, вы не опровергаете мои утверждения, а опровергаете собственные мысли, которые, якобы, подразумеваются мной.

На других системах слеш может означть совсем иное, и в итоге программа не скомпилируется. После устранения НЕРЕАЛИЗОВАННОЙ В СТАНДАРТЕ возможности ОСТАЛЬНАЯ ЧАСТЬ, СДЕЛАННАЯ ПО СТАНДАРТУ, будет работоспособной на 100%. Если стандарт говорит "про слеш - это не ко мне!" - как вы можете утверждать, что что <avr/io.h> не соответствует стандарту?! UB - это аспект, не затрагиваемый стандартом. Т.е. обо всем стандарт говорит, а об этом - не желает даже напрягаться. Так что мимо ваш пример.

Share this post


Link to post
Share on other sites

Я уже цитировал ваше утверждение что всегда дословно придерживаетесь стандарта, что это 100% защищает от подобных ошибок (про ошибки алгоритма речь не идет, они с языком не связаны).

16 часов назад, ARV сказал:

UB - это аспект, не затрагиваемый стандартом.

То что стандарт языка не затрагивает, может быть на разных компиляторах или платформах реализовано по-разному. Именно об этом речь и шла: если вы используете тот же слеш, делает вашу программу потенциально непереносимой или, хуже того, потенциально ошибочной. Допустим, есть ОС в которой слеш не является спецсимволом и может входить в имя файла*. Тогда ваш include подхватит не нужную библиотеку, а постороннюю, в которой может быть другой код. Это маловероятная, но возможная ситуация. Совсем правильно было бы обернуть такой код в #define, проверяющие тип компилятора, платформу и прочее. Но так никто не делает. Да, все полагаются на UB, все пишут потенциально небезопасный код. Просто потому что подобные экзотические платформы встречаются исчезающе редко. То же самое и с другими подобными ситуациями: для цикла от 0 до 1000 я выберу int а не uint16_t, потому что на всех известных мне платформах int как минимум 16-битный и его достаточно для цикла. Хотя стандарт этого и не гарантирует. Вы можете сами посмотреть исходные коды сложных программ и убедиться в подобном подходе (только что посмотрел случайные места кода ядра - вовсю используется те же int или long).

*) я, кстати, проверял обратную ситуацию: создал на виндовом разделе каталог "a\b" (это его имя). При этом в проводнике он отображался как "a" и зайти туда было невозможно.

Share this post


Link to post
Share on other sites
В 29.10.2017 в 11:53, COKPOWEHEU сказал:

То что стандарт языка не затрагивает, может быть на разных компиляторах или платформах реализовано по-разному.

Вот только что прочитал заметку с хабра... цитирую кусочек:

Цитата

Рассмотрим пример. Представим тщательно написанный код на С:


void process_something(int size) { 
  // Catch integer overflow. 
  if (size > size+1) 
    abort(); 
  ... 
  // Error checking from this code elided. 
  char *string = malloc(size+1); 
  read(fd, string, size); 
  string[size] = 0; 
  do_something(string); 
  free(string); 
}

 

Всё, как вы и говорили: используется код, проверяющий int на переполнение. Но, простите, какой дебил на это пошел?! Сколько надо дряни выпить или вкурить, чтобы пойти на ЗАВЕДОМОЕ UB?! Чем хуже проверка на INT_MAX, не дающая UB?

if(size > INT_MAX-1)
  abort();

Какая зараза толкнула кодописателя под руку выбрать int для РАЗМЕРА ОБЛАСТИ ПАМЯТИ, величине, сугубо БЕЗЗНАКОВОЙ, т.к. отрицательного размера физически не может существовать?! uintXX_t подошел бы тут гораздо лучше, и при этом не породил бы UB.

То есть я к чему клоню? Способов выстрелить себе в ногу МНОГО БОЛЬШЕ ОДНОГО, и тупость программиста не исправит никакой стандарт. А если программист с головой дружит, стандарт ему ТОЛЬКО ПОМОЖЕТ.

Edited by ARV

Share this post


Link to post
Share on other sites

Я наблюдаю и тащусь... Нахера мне стандарт, если я использую конкретную реализацию компилятора?
Нужно будет перенести  - так проще переписать, Всё разное - особенно порты.

Share this post


Link to post
Share on other sites
5 минут назад, oldmao сказал:

Нахера мне стандарт, если я использую конкретную реализацию компилятора?

А нахера ПДД, если при наличии двух глаз и хорошей реакции можно ездить и выживать при этом? Нахера САНПИНы, если каждый и так видит, что в рот сует и где живет?

Стандарт нужен для того, чтобы разные люди понимали и, главное, предугадывали поведение своих коллег. Понимаете? Если вы заявляете, что пишите на Си, я вправе ожидать, что мы поймем написанное друг другом ОДНОЗНАЧНО. Причем я надеюсь на это благодаря наличию стандарта языка Си. А вы на что?

В 27.10.2017 в 13:35, COKPOWEHEU сказал:

Вы хотите сказать что никогда не делаете преобразование float->int?

Из недавно процитированной статьи, точнее, её первой части, я выяснил, что на самом деле UB возникает из приведения указателя на int к указателю на float с последующим разыменованием оного. Что, в общем-то, опять же очевидно: память, занятая int распределена побитово (и побайтово) совсем не так, как во float, и ожидать от разыменования указателя магического превращения одного формата данных в другой - глупо.

Share this post


Link to post
Share on other sites
18 часов назад, oldmao сказал:

Я наблюдаю и тащусь... Нахера мне стандарт, если я использую конкретную реализацию компилятора?
Нужно будет перенести  - так проще переписать, Всё разное - особенно порты.

Вот вы интересные люди! О чем вы спорите не понятно!

Если ты используешь С-компилятор, ты используешь С-стандарт, который в любом случае реализует этот компилятор.

Но:

я, например, читал С-стандарт только когда занимался тестированием QNX-компилятора, потому что я должен был указать пункт стандарта в описании баги, а так в большинстве случаев мне не нужно ЧИТАТЬ стандарт, потому что, то что там написано, для меня очевидно или я предпочитаю проверять свое понимание логики работы компилятора создавая тестовые куски кода и разбирая ошибки и ворнинги, которые по ним выдает компилятор или разные компиляторы, если есть подозрения на неправильную работу одного из них.

Потом если стандарт существует и поддерживается (есть там какая то организация-достаточно серьезная которая следит за актуальностью и практикой применения), значит он был нужен и остается нужен, тут не о чем спорить, вы поспорьте еще о том что земля круглая!

Share this post


Link to post
Share on other sites

Здравствуйте! Помогите, плз, с прерывание по таймеру Т1, атмега 328р. Светодиод на PD5 в цикле не загорается.  

#define F_CPU 16000000
#include <avr/io.h>
#include <util/delay.h>
#include <avr/interrupt.h> 

int Nom1; // счетчик
int main(void)
{
       DDRD |= (1 << PD5);  // свето на выход
  
       Nom1=4; 
       TCCR1B = (1<<WGM12); // Режим CTC (сброс по совпадению)
       TCCR1B |= (1<<CS11); //запускаем таймер1 с предделителем на 8
       OCR1A=20000; // начальная уставка
       TIMSK1 = (1<<OCIE1A); // Разрешить прерывание по совпадению
       sei();

       while(1)
       {
           //_delay_us(900);

           if (Nom1<2)   // декремент идет в прерывании Т1.    
           {
               PORTD |= (1<<5);  //свет
             _delay_ms(200);
              PORTD &= ~(1 << 5);
              _delay_ms(200);
              Nom1=4;
          }
       }
}

ISR (TIMER1_COMPA_vect)  // сюда заходим весьма редко, но в while почему то не возвращаемся

{
       Nom1--;
       TCNT1=0; // сбрасываем счетный регистр чтоб считать снова с нуля
       OCR1A = 20000;
}

 

Edited by dim3740

Share this post


Link to post
Share on other sites
21 минуту назад, dim3740 сказал:

Светодиод на PD5 в цикле не загорается

Все переменные, которые используются одновременно в прерывании и в других местах программы, должны быть объявлены volatile

Share this post


Link to post
Share on other sites

@ARV , огромное спасибо! Все заработало! Хотя странно, что в других проектах и так работало иногда, просто ставил задержку в цикл...  А может это  был глюк))) 

Share this post


Link to post
Share on other sites

Join the conversation

You are posting as a guest. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Similar Content

    • By Артемон
      Всем привет. Просьба посодействовать в исправлении кода для термометра. Так как сам я в этом новичек, то код собирал из трех чужих проектов. Реализация такова, подключение термопары через микруху Max6675 к Atmega и вывод данных на LCD экран. В архиве прилагаю проект Atme Studio 7 и принт скрин из Протеуса. Ошибка заключается в неправильных показаниях температуры

      Test1.rar
      Вот код, чтоб не скачивать проект.

      #define F_CPU 1000000UL #include <util/delay.h> #include <avr/io.h> #include "max6675.h" #include "LCD.h" uint16_t gettemp(void); //Funktionsdeklarationen void initavr(void); //gettemp () returns absolute Temperature in Temp * 4 °C - in 1/4°-steps // uint16_t gettemp(void){ //Temperatur holen. uint8_t bit = 0, bitnr = 12; //Variablen uint8_t foo1 = 0; uint16_t Rohdata = 0; CS_Port &= ~(1 << CS); //Chip select anlegen for(foo1 = 0 ; foo1 < 16 ; foo1++){ //16 Bits einlesen bit = 15 - foo1; //Die Aktuelle Bitnr berechnen. SCK_Port |= (1 << SCK); //SCK hi if((bit <= 14) && (bit >= 3)){ //Einfach mal die 12 relevanten von den 16 Bits ausfiltern if((SO_Pin & (1 << SO))){ //WENN SO 1 ist, dann... bitnr--; //zдhlen wir runter... Rohdata |= (1 << bitnr); // und schieben eine 1 an bit x }else{ //WENN dem NICHT so ist, dann... bitnr--; //zдhlen wir runter... Rohdata &= ~(1 << bitnr); //und schieben eine 0 an bit x } }else{ //weis au nimmer, was das soll. bitnr = 12; } SCK_Port &= ~(1 << SCK); //SCK LO } CS_Port |= (1 << CS); //CS HI //Alles auf Standardkonfig. return Rohdata; //Das ist doch mal was ;D } // getTC() returns 0 if Thermocouple is not connected, 255 if thermocuple is connected // (to enable this feature T- must be connected to GND) uint8_t getTC(void){ //Temperatur holen. //Variablen uint8_t TC = 0; uint8_t foo1 = 0; CS_Port &= ~(1 << CS); //Chip select anlegen for(foo1 = 0 ; foo1 < 16 ; foo1++){ //16 Bits einlesen //Die Aktuelle Bitnr berechnen. SCK_Port |= (1 << SCK); //SCK hi if(foo1 == 2){ //das 3. bit ist fьr uns relevant. if((SO_Pin & (1 << SO))){ //WENN SO 1 ist, dann... TC = 0; }else{ //WENN dem NICHT so ist, dann... TC = 255; } } SCK_Port &= ~(1 << SCK); //SCK LO } CS_Port |= (1 << CS); //CS HI //Alles auf Standardkonfig. return TC; //Das ist doch mal was ;D } //Initiates the MAX6675 and IO-pins void init_6675(void){ //AVR initialisieren SO_DDR &= ~(1 << SO); CS_DDR |= (1 << CS); SCK_DDR |= (1 << SCK); //IOs setzen SO_Port |= (1<<SO); //Pullups an. (Wichtig fьr MAX6675, der kann nicht anders, hab ich festgestellt... CS_Port |= (1 << CS); //CS HI //Alles auf Standardkonfig. SCK_Port &= ~(1 << SCK); //SCK LO } int main(void) { init_port();// инициализируем порт ЖКИ lcd_init();// инициализируем ЖКИ init_6675(); while (1) { char buffer[8]; int temp; temp = gettemp(); temp /=4; lcd_gotoxy(0,0);//перемещаем курсор в верхний левый угол sprintf(buffer, "t=%i\xdf\C ", temp); // так как тут не плавающая запятая то числа с запятой записываются так %i.%i, код градуса записывается так \xdf lcd_putstring(buffer); } }
      вставляете код пользуйтесь тегами [CОDE][/CОDE] редактора сообщений, кнопка <>
    • By igoryan
      нужно ли обрабатывать RESET просто компилятор не видит RESET_vect?
    • By P32L
      Натолкните на мысль пожалуйста.Смысл в следующем.Нужно изменять задержку(Delay) из EEPROM. Контроллер PIC , язык СИ.
      Как реализовать чтение числа из ипрома ? Если не затруднит, то кусочек кода был бы очень кстати.
    • By Zver2011
      Здравствуйте! Недавно начал изучать МК AVR. Читаю книги Белова. Пользуюсь программами CVAVR и Proteus. По урокам, собирал все в железе. По готовым примерам кода конечно же мне легко учиться и все в принципе понятно из описания, хоть и в программировании не силен, но как только начинаешь создавать что то свое - начинаются проблемки.
      В общем я создаю что то вроде музыкального светильника, который должен включаться от звука (голоса). Датчик звука пытаюсь реализовать на компараторе, плавное включение света - ШИМ, а генерация мелодии (пищалки) благодаря таймеру Т1 и его прерыванию. Куски кода брал из разных чужих самоделок, вот только объединить не удается.
      В железе работает как будто цветомузыка какая-то. Мелодия не играет, Я думаю это из-за неправильной конфигурации компаратора, а также схемы. Вот это основной вопрос у меня. Ну и собственно основной цикл программы, там я думаю тоже накосячил.
      Помогите мне разобраться до конца, понять ошибки в коде, мне самому интересно вот только С - язык тяжеловатый на мой взгляд и без помощи знающих не обойтись))

      КОД.txt
    • By sensey88
      Продам счетчики бета-гамма излучения новые заводская упаковка
      Си1Г (79г) 62 шт. 5000р
      Си21БГ (79г) 49 шт. 350р
      Си22БГ (79г) 70 шт. 700р
      Си3БГ (84г) 20 шт. 300р
      Си3БГ (78г) 46 шт. 250р
      Си3БГ (77г) 10 шт. 250р
      Си3БГ (79г) 18 шт. 250р
      Си3БГ (75г) 10 шт. 200р
      Си37Г (80г) 40 шт. 400р
      Си37Г (76г) 24 шт. 350р
      Си37Г (79г) 16 шт. 350р
      Си33Г (78г) 28 шт. 450р
      Си33Г (77г) 15 шт. 450р
      СБТ13 (78г) 2 шт. 3000р
      СБТ13 (76г) 3 шт. 2700р
      СБТ13 (69г) 3 шт 2500р.
      Си8Б (79г) 1 шт. 2500р
      Си8Б (78г) 1 шт. 2500р
      СБТ10 (79г) 3 шт. 4500р
      8 (910) 7051241 Евгений
      bishop-x@yandex.ru
  • Сообщения

    • 1) А как Вы будете учитывать технологический разброс напряжений стабилизации? 2) А как Вы будете учитывать колебания напряжения стабилизации от тока через стабилитрон? 3) А как Вы будете компенсировать температурную нестабильность напряжения стабилизации? Продолжать? А делитель - он и в Африке делитель.
    • @BARS_ Спасибо, просто волшебная микросхема. А я уж собрался строить свой велосипед из двухкомпонентного композита  На коленке, правда уже не соберешь, но это уже другая проблема...  Такой вопрос: напряжение зарядки микросхема контролирует, ток тоже, а балансир при этом ставить надо? И что с ним делать, когда аккумуляторы заряжены? Ключами отключать, чтоб не тратить ток балансировки (а он не маленький)? @ГОГА рижский , я так понял, BMS - это балансир. Или она еще какие-то функции выполняет? И вопрос тогда тот же: надо ли как-то отслеживать момент окончания зарядки и отключать аккумуляторы от внешнего питания?
    • но на практике - реально в ТВ так и восстанавливали обрыв одной из обмоток ТПИ - развязывающим трансом с рабочей обмотки - важно только ФАЗИРОВКУ правильно сделать ... я сам так делал недавно - из 12-вольтового нужно было получить для стенда 24-48-72-96 - доп-трансформатор первичкой на 12-вольтовую, а потом - вторичка на него с отводами. Генероттор же именно по такому принципу и качает своим трансом за трансформатор проверяемого  ИИП
    • Электролит по первичке нормальный? Все диоды проверить на утечку, резисторы на соответствие номиналу. Вас  не смущает, что в цепи где вольт 350 стоит полевой на 80 вольт
    • Для легкости счета, к показаниям прибора добавить , скажем, 5 В, если стабилитрон на 5 В. А с делителем надо умножать, без калькулятора  трудно.
×
×
  • Create New...