Отправлено: 24.01.07 12:08. Заголовок: EEPROM не просматривается

Нет возможности видеть изменение регистров в пошаговом режиме.
Эту возможность, что, упразднили в новых версиях?
Потерял кучу времени с разбирательствами записи - чтения EEPROM, и
все бестолку, пока не поставил MPLAB 5.7.40, в нем все работает.
Может чего-то недовключил, хотя весь ХЕЛП перевернул???

 Отправлено: 21.01.09 15:14. Заголовок: Alberto пишет: "..

Alberto пишет:

цитата:

"сижу" на одном устройстве с динамической индикацией

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

 Отправлено: 21.01.09 16:47. Заголовок: Dmitry Dubrovenko пи..

Dmitry Dubrovenko пишет:

цитата:

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

использую пять индикаторов с полем 7х5 светодиодов. Время отображения одного столбца 800 мксек, частота обновления 50 Гц (800 х 25 х 50 = 1 сек). Не могу я вхолостую ждать 4000 - 6000 мксек. Может у Вас подход другой, может я делаю неправильно, но это мы можем обсудить в другой ветке, скажем по динамической индикации.

 Отправлено: 21.01.09 20:40. Заголовок: Я не опоздал к филос..

Я не опоздал к филосовским разборкам?
Вопрос принципиальный и касается не только проверки записи, но и проверки других событий типа - закончена ли передача информации в EEPROM, в другоую микросхему, на индикатор, в компьютер и т.п.

Ни что не мешает мне сделать программу передачи (или записи) текущей информации.
И ни что не мешает с делать программу прерывания, для экстренной передачи/записи информации (например кода ошибки или врезки информации о событии в тот же момент времени).
Проблема появляется при обращении к одному устройству обеих программ, основной программы и программы прерывания.
В то время как основная программа, никого не трогая (записав в регистр), усердно высиживает байт, пока тот не созреет и не улетит (и осядет) туда, где ему положенно быть.
Вдруг где-то что-то взрывается, врывается программа прерывания и откладывает в тот же регистр своей байт и, нетерпеливо, (по протоколу) усаживается в ожидании своего чуда.
Есть варианты решения... разные... очевидные и через........ пень колоду.

Я сам как программа прерывания :-) врываюсь.
Я ничего не пропустил? Я не о том? Ну извините :-)

 Отправлено: 21.01.09 21:47. Заголовок: Alberto пишет: част..

 Отправлено: 21.01.09 22:05. Заголовок: Dmitry Dubrovenko пи..

Dmitry Dubrovenko пишет:

цитата:

Здесь "собака и порылась"

не понял .

 Отправлено: 21.01.09 22:39. Заголовок: Photographer пишет: ..

Photographer пишет:

цитата:

никого не трогая, усердно высиживает

только не программа, а программист. Это его заботы сделать так, чтобы этого небыло. Вы в армии служили? "Товарищ капитан, разрешите обратиться к товарищу прапорщику". И никак иначе. Если "товарищ капитан" разрешает, то обращаетесь, а нет ждете своей очереди, периодически повторяя "волшебную фразу". Вежливость и еще раз вежливость.
P.S. Написал, прочитал, что-то заумно вышло . Так что в ролях: товарищ капитан - бит GIE из регистра INTCON.

Добавлено А не хотите запрещать прерывания, значит прерываетесь, первым даете команду "Отбой" на текущий обмен, передаете архиважные данные, выставляете какой-либо архиважный бит по которому основная программа понимает что ее цикл обмена был прерван, выходите из прерывания, основная команда при периодической проверке архиважного бита понимает что ее передача была прервана и она начинает передачу текущих данных с начала байта (группы байт). Вариантов много. Решение за Вами.

 Отправлено: 23.01.09 07:33. Заголовок: Alberto пишет: Вы в..

Alberto пишет:

цитата:

Вы в армии служили?

Так точно! :-)

Alberto пишет:

цитата:

............................ бит GIE из регистра INTCON. Добавлено А не хотите запрещать прерывания, значит прерываетесь, первым даете команду "Отбой" на текущий обмен,..........................

Вот черт! Опять моя проблема с общением. Я не так сказал - меня не так поняли. :-(
Вообще все "не в ту степь".
Извиняюсь, забудьте что я там написал.
В предь постараюсь писать ... не знаю как... рзборчивее.
Надо будет над почерком поработать :-)
Не стоит на это письмо отвечать.
см. далее.

 Отправлено: 23.01.09 07:33. Заголовок: Было такое мнение: ..

Было такое мнение:
Alberto пишет:

цитата:

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

И такое:
RW1ZK пишет:

цитата:

Разница между WR и EEIF: WR после успешной записи сбрасывается аппаратно, а EEIF нужно сбросить программно. Вот именно флаг прерывания я и привык контроллировать. Ты предлагаешь "плюнуть" на проверку окончания записи в EEPROM и исполнять программу дальше... Интересно... Вопрос спорный... По моему мнению, так делать нельзя. Игра на грани фола, но на вооружение взять можно для неответственных операций.

Вопрос: А не лучше ли выполнять проверку записи по прерыванию EEIF, в подпрограмме обработки прерываний? и там же выполнять обязательную процедуру записи в EEPROM. И не париться c запретом GIE.

 Отправлено: 23.01.09 07:42. Заголовок: Photographer пишет: ..

Photographer пишет:

цитата:

И не париться c запретом GIE.

Это который перед началом записи?

 Отправлено: 23.01.09 12:23. Заголовок: RW1ZK пишет: Это ко..

RW1ZK пишет:

цитата:

Это который перед началом записи?

?
Перед обязательной процедурой записи не требуется выставлять глобальный запрет прерываний, если она выполняется в подпрограмме обработки прерываний. Эту подпрограмму прерывания прервать ни как не могут.

Вот бы кто нибудь проверил, а то я все это из пальца высосал, сам не проверял, мне пока некогда. :-)

Вот вариант:
Скрытый текст

Основная программа 1) В основной программе можно записать адрес, данные и флаг(о необходимости произвести запись) в какие нибудь временные регистры общего назначения. 2) При помощи WR можно проверить не идет ли запись. Если нет, то выставить EEIF в единицу. Если запись всетаки идет, то ничего выставлять не нужно. В конце записи единица появится сама собой. 3) Программа автоматом вылетит в программу обработки прерываний. Подпрограмма обработки прерываний. 4) В подпрограмме прерываний, так или иначе, проверяем успешна ли была предыдущая запись в EEPROM. 5) Если была ошибка, то повторяем запись. (в данном случае она всегда успешна, т.к. мы прервались принудительно для записи, а предыдущая запись должна была провериться в предыдущем прерывании. 6)Проверить есть ли данные для записи, если есть - то произвести обязательную процедуру записи. 7) Снимаем флаг EEIF и выходим - retfie Все.... вроде, больше ничего делать не нужно.

 Отправлено: 23.01.09 14:15. Заголовок: Photographer пишет: ..

Photographer пишет:

цитата:

Перед обязательной процедурой записи не требуется выставлять глобальный запрет прерываний, если она выполняется в подпрограмме обработки прерываний.

боюсь что я Вас опять не так понял. В чём выиграш?

 Отправлено: 23.01.09 23:28. Заголовок: Alberto пишет: В чё..

Alberto пишет:

цитата:

В чём выиграш?

Выигрыш по сравнению с чем?
Записи в EEPROM в теле подпрограммы обработки прерываний (без запрета GIE),
по сравнению с записью в EEPROM в теле основной программы (с запретом GIE)?

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

Надежней, быстрее, экономичней....... чего еще? может просто непривычно?

К тому же, на мой взгляд, так выглядит красивее

 Отправлено: 24.01.09 00:33. Заголовок: Photographer пишет: ..

Photographer пишет:

цитата:

Надежней, быстрее, экономичней....... чего еще? может просто непривычно?

Alberto (10.01.09 02:16) пишет:

цитата:

Просто данные биты служат для разных целей. Задача бита EEIF именно прерывания. Например: есть какая-то программа, которая что-то делает и при этом периодически нужно как можно быстрее сохранить 40 байт данных в EEPROM. Есть два пути: можно тупо отправлять байт на запись, ждать 4-6 мсек (контроль бита EEIF или WR), потом отправка следующего байта и так 40 раз с потерей 160-240 мсек. А можно сделать проще: разрешаем прерывание по EEIF, отправляем данные на запись в EEPROM и спокойно занимаемся своими делами, как только запись будет завершена выставится бит EEIF, уход в прерывание, сброс бита EEIF, отправка следующего байта на запись, занимаемся своими делами до следующего прерывания по окончанию записи в EEPROM и так пока не будут сохранены все данные. Нет тупого ожидания. Вот это, в моём понимании, будет его (EEIF бита) задача.

то же самое только в профиль. Или Вы не согласны?

 Отправлено: 24.01.09 21:14. Заголовок: Конечно согласен, це..

Конечно согласен, целиком и полностью. Признаю Ваш приоритет. Тысяча извинений. :-(
Видимо я это пропустил. Бегло просмотрел обсуждение этой темы.
Видимо меня сбило с толку Ваше позднее сообщение. Alberto пишет:

цитата:

Я запрещаю прерывания по EEIF и не парюсь с ним, сброшен/установлен без разницы, прерывания-то по нему запрещены. Всё, ушёл .

 Отправлено: 24.01.09 23:04. Заголовок: Photographer пишет: ..

Photographer пишет:

цитата:

Признаю Ваш приоритет.

ну, поехало... Тогда мне надо признать приоритет Майка Предко (см. стр.102, "Устройства управления роботами. Схемотехника и программирование", 2004), а ему приоритет Микрочипа (см. "Справочник по среднему семейству микроконтроллеров PICmicro", раздел 7.6 "Запись в EEPROM память данных", 2002) .
Оффтоп: Еще раз повторю суть дискусии: по моему мнению, делать проверку окончания записи в EEPROM выгоднее, в плане экономии времени, перед началом цикла записи (см. стр.43, раздел 4.3 "Запись в EEPROM память данных", "Однокристальные 8-разрядные FLASH CMOS микроконтроллеры компании Microchip Technology Incorporated", ревизия DS30292C). В этом меня, пока что, не переубедили. О применении бита прерывания, как я это понимаю, я уже писал, повторяться не буду.
А мое предыдущее сообщение было не в плане приоритета, а как ответ на:

цитата:

чего еще? может просто непривычно?

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

цитата:

сбило с толку Ваше позднее сообщение

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