.macro kca ; sei !!!!! ldi temp,1 out sfior,temp clr temp sbr temp,0x02 out tccr0,temp ldi temp,0x1 out timsk,temp .endm
.cseg .org 0x0000 ; или имя вектора сброса по reset rjmp main_prog ; переход к началу программы пользователя, ; размещенной после блока векторов ; ВСЕХ ИМЕЮЩИХСЯ В МК ВЕКТОРОВ ПРЕРЫВАНИЙ
.org OVF0addr rjmp koca
main_prog: ldi temp,low(ramend) out spl,temp ldi temp,high(ramend) out sph,temp ldi temp1,128 sei ; перенести сюда
h: kca
ldi r18,0 out portd,r18 nop
rjmp h
koca:ldi r18,0xff out ddrd,r18 out PORTD,r18 out tcnt0,temp1 ; rjmp h это что за конструкция???!!! ; бесконечное обращение в точку вызова прерывания ; до полного исчерпания сткеа??? reti
Ну нельзя же так безбашенно тест составлять! Хотя бы минимальные "нормы приличия" соблюдать надо... Допустим МК = атмега8а, IDE авр студио4.19, компилятор аврасм2
.macro kca ;sei ldi temp,1 out sfior,temp clr temp sbr temp,0x02 out tccr0,temp ldi temp,0x1 out timsk,temp .endm
.cseg .org 0x0000 ; или имя вектора сброса по reset rjmp main_prog ; переход к началу программы пользователя, ; размещенной после блока векторов ; ВСЕХ ИМЕЮЩИХСЯ В МК ВЕКТОРОВ ПРЕРЫВАНИЙ
.org OVF0addr rjmp koca
main_prog: ldi temp,low(ramend) out spl,temp ldi temp,high(ramend) out sph,temp ldi temp1,128 ;sei
;h: kca; многократное дублирование макроса ; начальной настройки таймера ; должно быть kca sei
h: ldi r18,0 out portd,r18 nop
rjmp h
koca: ldi r18,0xff out ddrd,r18 out PORTD,r18 out tcnt0,temp1 ; rjmp h это что за конструкция???!!! ; бесконечное обращение в точку вызова прерывания ; до полного исчерпания сткеа??? reti
правильность участка инициализации таймера НЕ ПРОВЕРЯЛАСЬ
Решил чуток поиграться с кнопами - соорудить "векторный" вариант с заменой исполнительных функций "на лету"... Подобие того, что в муркотаймере применялось, но под адуринку... Схемка для теста: https://img.radiokot.ru/files/20529/2r7iquhcon.GIF и сам скотчик:
Это устройство (машина времени) уже успешно работает в области перехода на изготовленную в недавнем и более древнем прошлом элементную базу. В особенности на лежащие в "кащеевом ящичке" раритеты.
Почему все пренебрегают таким источником компонентов,как из старой техники извлекать? Разве это по хозяйски,пускать под пресс все это,если они на 90% исправны. Я не выкидываю ничего,гора аппаратуры собралась,например на инкубаторах мега8 в последнее время в основном применяются.
По поводу крутилок,вот родилась концепция. Некий деятель утверждает что его колесо вращается само. Имеем ротор с постоянными магнитами и статор с катушками. Коммутация катушек не раскрывается. Предположим,выходит 8+8 концов проводов. Собираем концы в матрицу 8*8. В узлах реле. 64 реле избежать не удастся.Шут с ними. Выводы реле тоже собираем в матрицу и к выходам МК.Колесо приводим во вращение вспомогательным мотором.Мониторим ток потребления и заводим его тоже в МК. МК перебирает всевозможные способы коммутации с учетом минимального тока. Результат выводится на индикацию.В идеале он должен завращаться сам. Питания на крутилку нет,только перемыкание концов контактами. Вариантов тупо коммутировать концы с паяльником слишком много. В любом случае это облегчит задачу. И еще синхронизацию по положению ротора неплохо бы иметь.
Это занятие для тех, у кого есть хорошо оснащенная слесарно-механическая мастерская, станочки, сварка да необходимые материалы в достатке. Я подобной базы не имею - могу только готовые полуфабрикаты использовать. Посему и не ханимаюсь экспериментами с подобными устройствами... Насчет "старой техники"в качестве донора компонентов... Вполне востребовано но в разумных пределах. Зависит от возможностей сделать неразрушаюший демонтаж (с учетом повторного нагрева и вероятной статики),типа корпусировки компонентов и прочих "мелочей". Дополнительно каждый из полученных таким образом компонентов требует обязательной проверки.
Зависит от возможностей сделать неразрушаюший демонтаж (с учетом повторного нагрева и вероятной статики),типа корпусировки компонентов и прочих "мелочей". Дополнительно каждый из полученных таким образом компонентов требует обязательной проверки.
Зато бесплатно... А с али-экспресса тоже многие компоненты нуждаются в проверке.
Встречался-ли кому проект микропотребляющего устройства на МК типа х51, реализующий сенсорную кнопку? Внешние чипы типа ТТР223 в расчёт не берутся. Нужно исключительно на МК.
Возможно у китайцев... Но там одни иероглифы. Я вот даже не смог от их сайта скачать/установить платформу под 51-е для ардуино ( viewtopic.php?p=4194910#p4194910 viewtopic.php?p=4196141#p4196141 ).... По идее возможна аналогия с ПИКами - там где-то в апнотах было про сенсорные кнопки на основе МК.
Имеете в виду микрочиповский AN1334 или ещё есть какие-то? А сами Вы пробовали этот подход вживую? Я пока изучил аналогичный силлабовский подход, основанный на их Cap Sense библиотеке CSLIB и попробовал его на АРМ семейства EFM32ZG. Подход основан на использовании компаратора МК в режиме релаксационного генератора (несколько резисторов обратной связи с выхода на вход компаратора уже интегрированы в МК и подключаются программно) и нескольких таймерах для подсчёта частоты в режиме ожидания и при нажатии, устранения дребезга и пр. Работает как часы, хотя и не без заморочек. Подключается к проекту буквально 3 строчками кода и парой кликов мышки в конфигураторе для подключения соответствующих ресурсов. Там всё очень высоко оптимизировано и упрощено для пользователя до предела. Токопотребление в режиме ожидания нажатия около 5 мкА, но можно и до 2 свести. Сейчас жду отладочную плату чтобы попробовать эту библиотеку на 8-битном семействе EFM8SB10. В любом случае ранее с сенсорными кнопками я не сталкивался и мне казалось, что эффекта можно проще дотигнуть. Возможно, я и ошибаюсь, не знаю. Микрочиповский подход будет также не "малой кровью". Может что-то проще имеется?
Попробовал ТТР223 с питанием от 3.3В. У неё потребление оказалось в 2 раза выше, чем в ДШ, т.е. также на уровне 5 мкА. В принципе допустимо, но мне ещё нужно некий процессинг делать, т.е. без МК не обойтись. А связка ТТР+МК уже как-то чересчур. Может мне экземпляр ТТР неудачный попался, не знаю. С китайскими чипами всегда лотерея.
в порядке оффтопа: а как при этом мизерном потреблении, что явно достигается "вечным сном", происходит коррекция влажности для сенсора? TTP223 производит эту коррекцию, на память, что ли каждые 20 мс... если этого не делать, сенсор перестанет работать при малейшем изменении условий...
я пытался и библиотеки атмеловские использовать, и сам писать - пришел к выводу, что проще готовый чип купить, спокойнее и проще результат достигается. возможно, я просто слишком ленив...
_________________ если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе при взгляде на многих сверху ничего не меняется...
Емкостных сенсоров я на МК не делал. Дело достаточно муторное и требует жесткой локализации места расположения устройства обработки данных. Позднее появились готовые модули с TTP223 (и с MPR121 но ту еще не пробовал - пока вылеживается до подходящего проекта
) и вопрос сам собой снялся из актуальных. Эти модули уже сделаны с учетом удобства размещения и минимизации монтажных да регулировочных работ - потому и прижились.
ARV: хороший вопрос. Библиотека CSLIB также производит автоматическую калибровку сенсора прозрачно для пользователя в зависимости от температуры и флюктуаций питающего напряжения, может ещё чего-то. Период калибровки можно регулировать программно в некоторых пределах. Я попробовал послюнявить палец и прикоснуться к сенсору. Работает также, как и с сухим пальцем. Что будет если на датчике будет лежать жирная капля воды - не знаю. Возможно, не будет работать. Но у меня это устройство будет дома в тёмном сухом шкафу и обильная влага на сенсоре не предполагаается. Я не упомянул о подходе фирмы Cypress к их датчикам, которые работоспособны даже с каплей воды на нём благодаря специальной конфигурации сенсора и hardware (см. картинку с их семинара 2016 года). Мне понадобилась Cap Sense для улучшения одного китайского устройства, от которого я в глубоком шоке. Такой мощной "подлянки" от них не ожидал. Устройство работает на батарейках и высасывает их очень быстро из-за большого токопотребления во сне и огромным током через светодиоды без всяких ограничивающих резисторов. Короче, помимо корпуса светильника меня в нём ничего не устраивает, включая алгоритм работы. Просто хочу заменить их начинку своей, задействовав имеющийся датчик (контактнaя площадку) под палец. Может статью напишу по завершении проекта.
BOB51: не вижу преимуществ MPR121 перед TTP223 если нужен всего один электрод. К тому-же, похоже, что первая уже не выпускается. В любом случае обе хуже по сравнению с CSLIB или Cypress/Infinion.
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения
Вход
Регистрация
Правила
FAQ
Поиск
