Да бери используй EEPROM и даже не думай. Если полетит заменить не проблема . 100000 циклов стирания . Даже если в каждый день по 100 разы выключать станок вам МК хватит на 3 года. А иметь в запасе 2-3 МК прошитых не проблема притом что они не дорогие.
yron писал(а):Если полетит заменить не проблема . 100000 циклов стирания .
Даже проще - перепрошить так, чтобы переменная попадала на новую ячейку памяти, и ещё 100000 циклов. Ведь еепром весь не стирается перед записью одного байта, правильно?
[color=#006699]In der großen Familie nicht kluven klatz-klatz![/color]
Проц pic12f675.
На одном сайте человек написал что максимальное напряжение на входе АЦП 4.097. Везде пишут 5 вольт. Кому верить. для расчётов что брать. Опорное АЦП на питание кинуто.
10 разрядов это 1023. Получим при максимальном напряжении на входе АЦП. А дальше как считать?
Если к примеру у нас вышло 456 после обработки . То какому напряжению оно соотвецтвует? Через пропорцию вычисляется или есть ещё способы?
misterkuk писал(а):Через пропорцию вычисляется или есть ещё способы?
Да, через пропорцию. Напряжение на входе АЦП = (опорное напряжение)*(результат преобразования)/(максимальное число)
В вашем примере 5 * 456 / 1024 = 2,23 В.
[ Всё дело не столько в вашей глупости, сколько в моей гениальности ] [ Правильно заданный вопрос содержит в себе половину ответа ]
кидаю байты на комп с определенной частотой (6 байт 100/200/480/960 раз в секунду)
соединяюсь на разной частоте 9600/14400/57600/115200
так вот, если кидать редко, то все проходит без проблем.
если же кидать часто (960 раз в секунду на скорости 9600) по идее должен переполняться буфер FT232 и выдаваться RTS=1. Но этого не происходит.
Вместо данных (или задержки передачи) я вижу кучу принятых битых байт. Повторяю, сигнал RTS не поднимается.
Проблему конечно решу в лоб, понижу скорость передачи, но интересует причина.
Проверял через программку Terminal с выставленным (и не выставленным тоже) handshaking RTS/CTS.
Serj324, я собирал ExtraPIC как раз на 74HCxx и ST232 (тот, что с кондёрами по 0,1мкФ).
Хочу предупредить, что при замене на 74HC-серию (с нестандартными ТТЛ-уровнями, переключаются они намного раньше) нужно будет поэкспериментировать с диодом (D5 на Вашей схеме). У меня логика никак не хотела переключаться, пришлось ставить диод Шоттки с меньшим порогом.
А по настройке могу посоветовать отличный ресурс по ExtraPIC'у. Тут подробная методика тестирования. Надеюсь Вам поможет как и мне.
player259 писал(а):Кто работал с FT232RL подскажите в чем загвоздка
Схему, для начала, покажи. Хотя бы ту часть где МК с FT-шкой соединён.
Вроде, там всё без проблем работает.
А чем смотришь на сигнал? Как определяешь, что не поднимается?
Когда уже ничего не помогает - прочтите, наконец, инструкцию.
Лучший оптимизатор находится у вас между ушей. (Майкл Абраш, программист Quake и QuakeII)
Избыток информации ведёт к оскудению души - Леонтьев А. (сказано в 1965 г.)
Kavka писал(а):А чем смотришь на сигнал? Как определяешь, что не поднимается?
На схеме завел RTS CTS проводками, т.к. изначально не думал что понадобится. Завел на обычные i/o пины меги. определял программно, если сработал хотя бы один раз, загорал диодик. овцелографа под руками нет.
Вообще сам handshaking как бы работает, потому что в ноль RTS падает при подключении к порту.
Странно, как-то. Скорее всего что-то упустили из виду. Пока больше соображений нет.
Просмотрел доки которыми пользовался - особых заметок не нашёл.
Только, пожалуй, вот эта. Но и то, это всего лишь как полезная инфа и проблему не решает.
Она относиться к FT232BM, но думаю, что и к FT232R тоже может относиться.
When RTS/CTS hardware handshaking is enabled CTS# can be used to stop the FT232BM transmitting data to the MCU / external logic. When CTS# is active ( low ) the FT232BM will transmit any data in it’s internal buffers. On taking CTS# high, the FT232BM will stop transmitting data. Due to the asynchronous nature of the interface, there is a latency of 0 to 3 characters between taking CTS# high and data transmission stopping. The FT232BM drives RTS# high when the available buffer space inside the device drops below 32 bytes. This allows the MCU / logic to continue to send up to 30 characters to the FT232BM after RTS# goes high without causing buffer over-run.
В моём устройстве всё заработало сразу, проблем не было. Пожалуй совет только один - проверяйте номера ножек, непропаи, "залипухи".
Когда уже ничего не помогает - прочтите, наконец, инструкцию.
Лучший оптимизатор находится у вас между ушей. (Майкл Абраш, программист Quake и QuakeII)
Избыток информации ведёт к оскудению души - Леонтьев А. (сказано в 1965 г.)
player259, почему Вы решили, что буфер должен переполниться на такой скорости?
Насколько помню, глубина ФИФО на передачу 64 байта, опрос ОСью ЮСБ девайсов делается раз в одну мс.
Загружая на вход компьютера "мусор", на выходе получим "мусор^32".
PS. Не работаю с: Proteus, Multisim, EWB, Micro-Cap... не спрашивайте даже
isx писал(а):Добрый день)) Решил вот тут поюзать EEPROM.
Ранее было решено использовать EEPROM для этой цели, но сегодня наткнулся на статью, что EEPROM позволяет перезаписывать себя только 10000 раз, а моя установка будет делать это около 100 раз в сутки...
Поднятый вопрос не даёт покоя
По словам ТС, сохранять нужно максимум два байта. Так понимаю, деградация происходит только в тех конкретных ячейках, куда осуществляется запись, правильно? По идее да, тогда алгоритм для подобных задач прост:
- при прошивке МК выделяем одну ячейку в еепром под адрес, пишем туда х;
- в конце работы сохраняем параметр в еепром три раза с адреса х, итого 6 ячеек;
- при старте программы сравниваем все три копии, если результаты совпадают - берём любой и работаем;
- если одно из значений отличается, берём одно из двух совпавших и работаем, в ячейку адреса пишем х+6, и теперь сохранение происходит в новую, доселе неюзанную область еепром;
- и так каждый раз, пока не дойдём до границы.
Конечно, идея не нова, где-то я это наверняка давно читал, однако вопрос конечности циклов записи для таких простых случаев почему-то всегда ставится прямо - 100 тыщ и усё. Может в мои рассуждения закралась ошибка?
[color=#006699]In der großen Familie nicht kluven klatz-klatz![/color]
Meteor писал(а):player259, почему Вы решили, что буфер должен переполниться на такой скорости?
Насколько помню, глубина ФИФО на передачу 64 байта, опрос ОСью ЮСБ девайсов делается раз в одну мс.
Опрос это одно, а будет ли устройство отвечать на него передачей данных - это другое.
В драйверах есть настроечка как часто отправлять данные если буфер не заполнен. Может её покрутить - уменьшить время.
У FT232R
буфер USB->UART - 128 байт
буфер UART->USB - 256 байт
И ещё, не надо забывать, что к USB могут подключаться другие устройства, которые могут занимать полосу пропускания и мешать "плавной" передаче данных.
Когда уже ничего не помогает - прочтите, наконец, инструкцию.
Лучший оптимизатор находится у вас между ушей. (Майкл Абраш, программист Quake и QuakeII)
Избыток информации ведёт к оскудению души - Леонтьев А. (сказано в 1965 г.)
// Timer/Counter 1 initialization - 10 Гц
.......
OCR1AH=0x00; // это старший байт
OCR1AL=0x62; // это младший
Я не так много МК прошил (если честно всего один серьёзный проект, так вот там тоже почему-то расчётное значение при такой же настройке таймера сильно не совпадало с реальным, пришлось подгонять подбором, причину пока не понял).
ничего странного
Да просто меняешь например
OCR1AH=0x02; // это старший байт
OCR1AL=0x62; // это младший, т.е. к-т деления 262 в 16-ричной системе счисления
не знаю что вы называете коэффициентом деления,но расчет времени до следующего прерывания производится так:
таймер 16 бит.
(2^16-0x262)* время_тика_камня* коэффициент_деления_таймера = время_между_прерываниями
таймер 8 бит.
(2^8-0x62)* время_тика_камня* коэффициент_деления_таймера = время_между_прерываниями
если думать как в вашем случае,то нужно запускать таймер в обратную сторону.
комп лень запускать,чтобы посмотреть что у вас там с коэффициентом деления в таймере и куда он идет.просто напомнил, может вы забыли вычесть из максимального счета таймера ваше значение при расчетах
