a_b_r_a, вы же можете аппаратно считать импульсы одним из счётчиков, без использования прерываний. Время от времени смотреть, сколько там натикало. И дельту прибавлять уже к счётчику, допустим, 32-х битному.
a_b_r_a, вы же можете аппаратно считать импульсы одним из счётчиков, без использования прерываний.
Как вариант можно попробовать.
Добавлено after 17 minutes 2 seconds: Как я думаю тогда поступить. Да, идея хорошая по входу внешнего тактирования T1 считать импульсы. У меня есть прерывание по таймеру T0. Каждую 1 миллисекунду. Можно проверять счетчик миллисекунд и когда он дойдет до тысячи (1 сек) смотреть содержимое счетного регистра. Наверно это будет не совсем точно, но попробовать можно.
Martian Если 4000 импульсов на километр, то при скорости 300 км/ч какая частота импульсов? 350 герц? И не успевает?
Ну чему тут удивляться - логическая обработка на уровне решения задач третьего класса. Какое-то деление или умножение на какой-то коэффциент, зачем-то подсчёт герц, ... . С "железом" надо работать несколькопо по друному. На его "мышлении" 0/1, т.е. как там в фильме: <без фанабериев всяких>, уходя от неоправданных сложных вычислений (тем более, что это вполне достаточный, но всё же маленький МК),
Цитата:
Martian ...а вот с программой что-то не то...
Да уж и с работой с прерываниями не совсем и попытка в языке высокого уровня изгаляться при решении простейших текущих задач, решаемых в две команды на ассмеблере.
Короче - проект может и интересный, но подготовка исполнителя по его логической и языковой реализации, мягко говоря, пока слабовата. a_b_r_a, чтоб не "тонуть" в словофлуде вокруг да около, я вот вижу это так (т.е. сугубо имхо): если писать о достаточно многозадачном проекте, то его, вами видимое, прохождение желательно предоставлять к совету не словесно, а в графическом виде с вашими комментариями. Сначала отдельными кусками по задачам, потом уже обьединять.
Кстати, попробую я завтра в прерывании которое каждую миллисекунду инвертировать какую-нибудь ножку МК и гляну осликом, что там происходит. А потом подам 113 герц на вход скорости и гляну еще раз.
И прислушаться к valentinovich - разбить задачу, нарисовав и описав некую блок-схему, получить в итоге ТЗ и решить его оптимальнейшим образом. По тому что сейчас непонятно, зачем каждую миллисекунду что-то там вызывается (хотя, мож и говорилось, но я пропустил)? это ведь чуть ли не на порядок быстрее, чем частота вспышек в цилиндрах...
И прислушаться к valentinovich По тому что сейчас непонятно, зачем каждую миллисекунду что-то там вызывается.
Вы писали код когда-нибудь на Си? Если я вам скину проект, можете конкретно указать, что не так написано или конкретно кодом помочь в оптимизации? Там собственно все структурировано.
//====== // Функция чтения байта с датчика uint8_tdt_readbyte(void) { uint8_t c=0; uint8_t i; for(i=0;i<8;i++) c|=dt_readbit()<<i; // Читаем бит return c; } //======= // Функция записи бита voiddt_sendbit(uint8_t bt) { uint8_t stektemp=SREG; // сохранение значения стека cli(); // запрещаем прерывания DDRTEMP |= 1<< BITTEMP; PORTTEMP &= ~ (1<<BITTEMP); // Притягиваем к нулю шину _delay_us(2); if(bt) DDRTEMP &= ~ (1<<BITTEMP); // Отпускаем шину _delay_us(65); DDRTEMP &= ~ (1<<BITTEMP); // Отпускаем шину SREG=stektemp; // Вернем значение стека sei(); } //======= // Функция записи байта в датчик voiddt_sendbyte(uint8_t bt) { uint8_t i; for(i=0;i<8;i++) { if ((bt & (1<<i))==1<<i) dt_sendbit(1); // Передаем 1 else dt_sendbit(0); // Передаем 0 }
} //========
uint16_tdt_check(void) { uint8_t bt; // переменная для считывания байта
if (!st) // Начало первой фазы измерения {
if (dt_test_device()==1) // Если устройство нашлось {
dt_sendbyte(NO_ID); // Пропускаем идентификацию dt_sendbyte(T_CONVERT);// Измеряем температуру st=1; // Установим флаг окончания первой фазы измерения last_time=millis; } } // Вторая фаза измерения if (millis-last_time>750) // Проверяем, прошло ли 750 мС. В 12 битном режиме преобразование 750 мС { last_time=millis; dt_test_device(); dt_sendbyte(NO_ID); dt_sendbyte(READ_DATA); //Даем команду на чтение данных bt=dt_readbyte(); // Читаем младший бит ttt=dt_readbyte(); ttt=(ttt<<8)|bt; // Сдвигаем старший байт влево, на его место пишем младший байт st=0; // Готовимся к новому измерению }
//====== // Преобразование температуры в единицы uint8_tconverttemp(uint16_t tt) { uint16_t b=0; uint8_t t; b=tt; b=b>>11; // Оставляем 5 старших знаковых бит if (b) // Если хотя бы один из этих бит равен 1, то температура отрицательная { v=1; // Установим флаг отрицательной температуры t=((~tt)+1)>>4; // Проинвертируем побитно и прибавим 1 для преобразования } else { v=0; // Температура положительная t=tt>>4; // отсекаем часть младших битов. Оставляем только единицы градусов. }
return t;
}
Для спидометров лучше, на мой взгляд, применить измерение периода захватом. Для Вашего случая 10*S[км/час]=(36000*Fo/4073)*Nx/nox Fo- частота тактирования таймера Nx- число измеряемых периодов nox- число периодов частоты тактирования за время прохождения Nx Число в скобках является константой Пример Fo=8000000 Nx=1 (36000*Fo/4073)=70709550 Измеряется скорость 100км/час nox=70709 10*S[км/час]~1000,00 Измеряется скорость 5км/час nox=1414191 10*S[км/час]=50
я вам скину проект, можете конкретно указать, что не так написано или конкретно кодом помочь в оптимизации? Там собственно все структурировано.
Если вы не возражаете, то давайте переведём вашу мысль, т.е. вы предлагаете: 1. с вашего наброска программы надо попробовать изобразить какое-то ТЗ (и наверное вы его ещё и утвердить должны? ), 2. потом попытаться понять и проанализировать видимую вами логику реализации проекта (причём уже видимо в как-то собранном виде), 3. далее по каждому логическому участку по моему усмотрению поправить логику, 4. следом (если получиться) состыковать все ваши хотелки воедино, ну и - 5. наконец написать программу на желаемом вами языке (именно получается, что уже написать заново, а не править ). Уверяю вас, что это уже как бы "Реверс-инжиниринг", который несколько сложнее, чем просто написать кому-то свою программу по вашему ТЗ. Причём к МК, который исполнителю удобнее и на языке, который исполнитель сочтёт для сего нужным. Ну а вам тогда купить этот проект со вплюс его схемной реализацией вкупе Ну или попытаться идти по пути который я вам уже порекомендовал: где (повторюсь) сначала надо отделить "мух от котлет". И сорри, но ещё раз - (1)например я не вижу подробности того что вы хотите реализовать (подробного ТЗ, графической структуры видимой вами реализации, см. посты выше). Хотя в общих чертах проект понятен. И только когда проект будет "вылизан" логически под возможности выбранного МК, то (2)тогда уже можно будет говорить о его реализации на каком либо языке. Вот тогда на каждом представленном вами этапе, начиная с графического представления процесса, можно будет чего-то посоветовать.
P.S. Мне это видится как-то так. Или может кто-то из форумчан вам порекомендует какой-нибудь другой путь. P.P.S И при многих желаниях от небольшого МК, для выжима из него максимальной его производительности, Имхо проект надо бы реализовывать на ассемблере.
Последний раз редактировалось valentinovich Чт сен 07, 2023 22:52:14, всего редактировалось 1 раз.
Интереснее было бы реализовать измерение скорости по принципу оптической мышки. Авто = мышь, светит на покрытие под машиной, принимает отражение. Фантастика, конечно, но. .. когда нибудь… При работе с 1820 я вводил переменную Mode_DS. Возникла потребность в температуре- ставим туда 0. Далее (cli), слот reset, инкремент переменной и (sei). Спустя сколько то времени проверить переменную, она будет равна 1, - опять (cli) и следующий слот. И так далее. Тогда работа с датчиком размазывается по времени и не мешает.
Надо на автомобиль установить курвиметр, только большой. Специальное колесо, которое касается дороги и измеряет пройденный путь. А если от этого пути взять производную, то получим скорость. Жаль, что на автомобилях не бывает колёс, которые всё время касаются дороги.
Во блин, как оно оказывается. Благодарствую. Век живи - век учись.
Добавлено after 34 minutes 44 seconds:
>TEHb< писал(а):
Надо на автомобиль установить курвиметр
Вам бы только возможности ляктроники обкакать. А мы, например, вот не совсем курвОметр, но аля что-то похожее с ребятами делали как-то. Светодиодная полоса мгновенного расхода горючки (л/100км) без МКовейуев, без них короче. Практически на 2-х МС. Оченно забавно, вполне наглядно и информативно получилось.
Оооо, это надо было видеть (слышать). Предложений по первУ сыпалось как из рога изобилия ... вот где понимаешь, что такое весёлая жизнь. Как раз и курвиметры (почему и вспомнилось), и даже тахометры (не они, но идею выдали на горА правильную), и много чего смешного и прочего ещё. Но занимались мы не фантастическими или космическими проектами и посему волевым решением всё же были выбраны и утверждены всё те же пресловутые стандартные родные датчики. Так как "во главу угла" всё же ставились мозговой штурм неокрепшими (но стремящихся к познаниям) умами решения задачи и попытка её реализация в пределах желательно простой электроники.
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 10
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения
Вход
Регистрация
Правила
FAQ
Поиск
уходя от неоправданных сложных вычислений (тем более, что это вполне достаточный, но всё же маленький МК),
). 
без них короче. Практически на 2-х МС.
решением всё же были выбраны и утверждены всё те же пресловутые стандартные родные датчики. Так как "во главу угла" всё же ставились мозговой штурм неокрепшими (но стремящихся к познаниям) умами решения задачи и попытка её реализация в пределах желательно простой электроники.
