pliss
-
Постов
768 -
Зарегистрирован
-
Посещение
Тип контента
Профили
Форумы
Блоги
Весь контент pliss
-
В авто, аккумулятор используется именно в буферном режиме. В авто, используются аккумуляторы для которых ударные нагрузки "в виде стартера" - штатный режим эксплуатации. Сделаны они для этого специально. Так и называются - стартерные.
-
Proteus. ARV_PWM_arrow_ind.rar -
Вот это можно более вменяемо записать?.. void change_width_Pwm(unsigned char *b, const int a, const char c, const char d) { if(c == *b)// переход через минимум или максимум ширины { *b = d; } else { *b += a; } } ///////////////////////////////////////////// case BTN_UP_0 : change_width_Pwm(&width_Pwm_0, NEXT, WIDTH_PWM_MAX, WIDTH_PWM_MIN);//увеличиваем ширину change_ind_Pwm(&ind_Tens_0, &ind_Ones_0, width_Pwm_0); //увеличиваем индикацию break; case BTN_DWN_0 : change_width_Pwm(&width_Pwm_0, PREV, WIDTH_PWM_MIN, WIDTH_PWM_MAX);//уменьшаем ширину change_ind_Pwm(&ind_Tens_0, &ind_Ones_0, width_Pwm_0); //уменьшаем индикацию break;
-
Видите ли в чём дело... Ваш код или код коллеги ARV отличается от моего не тем, что он хорошо отформатирован, а тем что он хорош сам по себе. Форматирование здесь сильно ни причём.)
-
Не знаю, смеяться или плакать.) Мудрый дядька эту книжку написал, а может, просто следил за этой веткой форума. Девятая страница:
-
Конечно мало, но это я "на скорую руку" переделал, когда прошивал контроллер. Точнее - сначала запрограммировал с арифметической прогрессией, потом переделал на геометрическую. Но, не с характером приращения у меня сложности.) Возможно. Я делал по High Integrity C++ Coding Standard И это говорите мне вы?!!!! ))))))) Возможно, но я не постой разработчик. Я разработчик, который лучше всех остальных разработчиков знает т.з. Я сам и есть - Т,З. Да, я - объективная реальность и т.з.
-
Чтобы развеять сомнения достаточно прочитать начало темы.) Я не гипотетический. Я объективная реальность. Ну, и опять же - у темы есть начало.) По поводу форматирования - я "пошёл в гугл и набрал в яндексе" "оформление форматирование код си". Нашёл перевод существующего стандарта оформления. Исполнил все пункты кроме "№ 1". Да. Прогрессия должна быть геометрической. "Один" и "один + один" различаются в два раза. (100%) "Девяносто девять" и "девяносто девять + один" различаются в 1,01(01) раза.(1%) Ну, вот если бы в моём коде намекнуть на место, где можно применить такой фокус, если такое есть, но не сам фокус - это было бы здорово...
-
Согласен. Я, когда вырасту и стану большим, такие же штуки буду писать.) Если честно - я никак не "въеду" в объявление и дальнейшее использование функций. Вот у вас - Я так понимаю, что я её должен изобрести. Это вы мне оставили, и в результате нажатия на ту или иную кнопку вместо неё должно получиться число. А от того, какое число получиться зависит какой случиться case. Ну вот на таком уровне у меня "функции". Были бы на другом - я бы в своём коде их бы давно прикрутил куда-нибудь...
-
Подгонка по месту оказалась не такой сложной. Я в протеусе уже не могу определить изменение частоты при любых манипуляциях с кнопками. Хотя, повторюсь - стабильность мне важна во время работы. Во время перенастройки она меня не интересует. Единственное, что сложнее победить, при использовании целочисленных переменных - это абсолютную разницу в ширине импульса... Но можно.
-
Это от условий задачи зависит. Если в условии есть требование о строгом поддержании частоты импульсов и строгой точности приращения их на любом шаге исполнения кода - это да. А меня - и это я никак не могу донести до коллег, совершенно не интересует поведение устройства во время изменения ширины импульса. Пусть хоть в космос слетает - лишь бы после изменения вернулось обратно и ширина и частота импульсов соответствовала заданным во время изменения.
-
Желаю. И учусь. Сначала хочу научиться организовывать многоканальный шим без аппаратного таймера. Это у меня пройдёт. У вас же прошло.) А что закодировал "говнокодом" - так можно и перекодировать. Дело не хитрое. Но, сделал это принципиально, чтобы навсегда не остаться виртуальным программистом. У многих на форуме, я уверен, весь диск забит кодом, который ни разу не исполнялся ни где, кроме симулятора.
-
Ну, это вы всё, на верное, правильно говорите, только непонятно.) Но тем не менее оно работает. Може быть внутри оно неправильное, но снаружи - вполне. Спасибо всем, кто вольно или не вольно помог сделать первый шаг. ))
-
@ARV , вашу статью прочитал. Если вы не потеряли интерес к вашему сайту, то вопросы по ней я задам там. Ну хорошо. Вы описали последовательность так, как её видит программист: А вот так выглядит последовательность с точки зрения "нормального")) человека: 1. Получить несколько - пусть две (для простоты), последовательности импульсов определённой частоты. 2. Иметь потенциальную возможность независимо изменять скважность импульсов для каждой последовательности. 3. Иметь возможность запомнить установленную скважность импульсов. Кнопок у меня, на этапе постановки задачи - нет вообще! А каждое третье сообщение в обсуждении - о необходимости специальным образом организованного опроса кнопок. Каждое четвёртое - о необходимости поддержания точности частоты импульсов до +-1 такта процессора. И в каждом из них напоминают, что мой код - это основа очередного сервис-пака для windows, а с моим подходом он будет сильно глючным...) Пока код выглядит так: Прикинул. Пауза каждого, в моём случае восьмого периода, отличается от остальных на количество тактов за которое выполняется действие if((!(port_state&0b00000001)) умноженное на количество кнопок. Если кнопки не нажимались... Если я перемешаю опрос кнопок и отсчёт периода, то период всё равно будет плавать тогда, когда будет выполняться приращение импульса при нажатой кнопке... Так?
-
Ну, вот я и разделил на задачи - кнопки отдельно, шим - отдельно. На верное, вы имели ввиду совершенно другое разделение, но вы говорите на языке программистов, а я пока ещё на обычном - человеческом, естественно, что чаще всего я вас понимаю не правильно. Вообще-то, появление отдельного цикла для шим - это для того, чтобы не потеряться в том, что я понаписал... А здесь - я вам возражу. Для меня строка "0b00000001", пока, более наглядна, так как я вижу восемь однотипных ножек микросхемы, одна из которых отличается от других. А здесь "0b00000010" - отличается другая ножка. И т.д. Но это именно - "пока".
-
При данном количестве тактов и данной частоте CPU получается нужная мне частота шим.
-
PORTD=0xFF;//включаем всё while(T<=260)//период { if(T==ton0)//сравниваем время PORTD0_on PORTD&=0b11111110;//выключаем PORTD0_on if(T==ton1)//сравниваем время PORTD1_on PORTD&=0b11111101;//выключаем PORTD1_on T++;//считаем период } T=T_;//восстанавливаем период Ну да. Так конечно лучше... И каналы меньше расползаются относительно друг-друга. Приращение импульса, вообще, в ерунду какую-то превратилось. Смех один... // **** кнопка "+" *** // if((!(port_state&0b00000001))&&(260>=(ton0+d0))&&(!r))//если нажат "+" и есть возможность расширения импульса и разрешено изменение { ton0=ton0+d0;//увеличиваем время PORTD0_on r=1;//запрещаем изменения }
-
В чём принципиальная разница между увеличением счётчика и уменьшением? В аппаратном таймере - понятно. Устроен он так - считает от нуля до числа заложенного в OCRx, или до переполнение OCRx. Я начал не с увеличения, а с уменьшения. Могу наоборот. Если же основная ваша мысль - то, что можно обойтись одной переменной и для периода и для заполнения - ну так и сделайте её основой сообщения.... Но всё равно - спасибо.) Буду пробовать.
-
Спасибо. Именно об этом, но своими словами я говорил ещё на первой или второй странице. Собственно, помимо владения программированием, необходимо иметь понятие о дидактике и методике. Без этого процесс сеяния разумного доброго и вечного идёт именно так, как он идёт на любом не педагогическом форуме. P.S.Для некоторых, особенно для не владеющих собой коллег, который не хотят отвлекаться, но не могут с собой совладать и постоянно отвлекаются - это вообще просто повод для саморекламы и набора количества сообщений.
-
Следуя вашим советам, коллеги, код обработки одной кнопки уменьшился до неприличных размеров. Если не переходить к использованию аппаратного таймера, можно что-то улучшить радикально? И чем лучше сравнение с переменной, в которой сохраняется состояние порта, чем сравнение с самим состоянием порта?
-
Ну вот. Умеете вы рассторить. Я так долго с автоповтором боролся... То есть, если я просто уберу вторичный счётчик, то автоповтор станет очень быстрым?... Переменную "r" придумал. Эх... Мне автоповтор пока не нужен. С величиной приращения можно или за две-три перепрошивки определиться или - если получится совладать с eeprom, то его, как и начальную скважность можно сделать настраиваемыми... Пошёл накапливать вопросы. Я правильно понимаю - если пользоваться таймером, то максимальная разрядность шим это максимальная разрядность таймера, если пользоваться программным - это количество тактов в периоде шим. Если у меня период состоит из T=110 тактов, то у меня 110 - разрядный шим?..
-
Я - нет. Протеус - давно умеет. Я же уточнил, что, возможно в железе будет совершенно нормально... Может, я не правильно вас понял. Вернулся к вашему варианту опроса через "Х" циклов: Считаем "n" до 0bxxxx x000 (это первичный, общий счётчик) - проверяем кнопки. Если кнопка нажата - считаем "n0" до 0bxxxx x111 (это вторичный, счётчик) - выполняем действие. У меня вторичный счётчик инкрементируется каждые 8*8 раз при нажатой кнопке... То есть, нажатие может быть зафиксировано, самое позднее - через 8 периодов, а выполнено через 64 периода... Если вы говорите, что после определения нажатия - микросекунды, то я не правильно завёл вторичный счётчик...
-
Я делал как вы сказали, но именно регистрация "в следующем цикле" мне не очень понравилась... Но это конечно, в протеусе. Может в железе это будет не заметно. Ещё не понравилось, но это из той же оперы, имхо, что время между моментом нажатия и приращением переменной сильно разное бывает. Да запускал я на таймере колебания. Несколько страниц назад... Нормально. Но обработка нажатия кнопок получилась какая-то лохматая - сейчас пытаюсь совладать не столько с самими импульсами, сколько с обработкой кнопок... И на библиотеке делал задержку для антидребезга. Был подвергнут жесточайшей обструкции. И так я тоже делал. Мне было указано, что не "нужные книжки я в детстве читал".© Я стал читать о приложении С к микроконтроллерам - опять не так!))))
-
Конечно прочитал. Всё что понял - это то, что компиляторы мягко говоря, с пренебрежением относятся к тому, что написано в программе. Решил проверить. Ну, эт конечно шаманство. Но не извращение.
-
Нет, такой задачи пока не было. Но, конечно я вижу, что период плывёт при изменении ширины импульса и чудовищное несоответствие между тактовой частотой и количеством тактов заложенных в период "Т". Но это пока не принципиально...
-
Ну да, конечно... Опять туплю.) Это мне, вдруг, не нравилось то, что по совету коллеги @Alexeyslav, программа через каждые сколько-то циклов, без разрешения заходила проверять мои кнопки, а после обнаружения нажатия - опять начинала считать перед тем как исполнить то, что должно быть в результате нажатия... Ну, эт я у него самого попробую уточнить. Я переписал код так, чтобы отсчёт "антидребезга" начинался после нажатия на кнопку. Ну, и решил, что никакого циклического опроса у меня не стало.))) Бесовское это дело - контроллеры программировать.