В.Н. Гололобов |
Экскурсия по электронике |
460 |
Рис. 5.2. Проверка с помощью примера из пакета системы Gambas
Долгожданный ответ скрыт в символах «b7».
Расширение кругов (на воде?)
Я не собирался доводить развитие проекта, о котором шла речь выше, даже до этой стадии. Все казалось достаточно очевидным, я не ждал каких-то подвохов, программа для микроконтроллера была взята из уже проверенного варианта, но теперь, когда все оказалось вопреки ожидаемому столь запутано, есть смысл довести работу с проектом до некоего логического завершения.
Начну я интерфейсной части проекта. Поскольку в терминале ответ от микроконтроллера виден, он должен быть виден и в соответствующем окне интерфейса. Часть кода, написанного мною в Gambas, которая отвечает за получение ответа от контроллера, выглядит так:
PUBLIC SUB Button2_Click() ' Клавиша "Счет"
SerialPort1.Open
SerialPort1.RTS = FALSE
PRINT #SerialPort1, "b"
INPUT #SerialPort1, TextBox2.Text, Eof(SerialPort1)
END
Результат безуспешных проб, этот код мне кажется правильным, но работать он не желает. Проведя ряд экспериментов по добавлению настроек порта непосредственно в текст программы, по добавлению разных переменных, я наконец нахожу разумным (и почему не сразу?) заглянуть в работающий с последовательным портом пример, который я использовал для предыдущей проверки, и в котором получил долгожданный ответ, как
В.Н. Гололобов |
Экскурсия по электронике |
461 |
последовательность символов «b7».
По виду коды в своей сути совпадают, хотя программы разные, и коды, соответственно, тоже. Проходит несколько часов заполненных фантазиями и разочарованием, прежде чем я замечаю, что получение ответа от COM-порта выполнено в работающем коде иначе, чем у меня. Я исправляю это место, копируя с последующим исправление нужную часть кода, и теперь работает и интерфейс.
Рис. 5.3. Отклик контроллера в интерфейсной части программы
Часть кода, ответственная за это выглядит так:
PUBLIC SUB Button2_Click() ' Клавиша "Счет"
SerialPort1.Open
SerialPort1.RTS = FALSE
PRINT #SerialPort1, "b"
END
PUBLIC SUB SerialPort1_Read()
DIM answ AS String
READ #SerialPort1, answ, Lof(SerialPort1)
TextBox2.Text = TextBox2.Text & answ
SerialPort1.Close
END
Здесь получение отклика от микроконтроллера интерфейсом вынесено как событие. Открывание и закрывание порта я поделил между двумя процедурами, что неправильно, но это легко поправить, хотя бы возвращаясь к первоначальному решению – добавить кнопку открывания и закрывания порта. Мне же следует решить задачу опроса порта ввода контроллера и передачу не просто символа, а этого состояния порта в виде символа. То есть, пора возвращаться к программе Piklab и программатору. Я сейчас не доверяю самодельному программатору и буду использовать купленный ExtraPic, не дорогой, но хорошо работающий (пока). И проверку я буду проводить, видимо, используя не интерфейс, а программу работы с COM-портом из примеров системы Gambas.
Не буду спешить. Для начала переделаю часть программы, отвечающую на команду «b»:
void cmd() // Получение и выполнение команды
{
switch (input) { case 'a': PORTA = 0x0; break;
В.Н. Гололобов |
Экскурсия по электронике |
462 |
case 'b':
COUNT = PORTA & 0x38;
if (COUNT == 0x38) PORTA = 0x7; // Индикация тестовая break;
default:
break;
}
}
COUNT – это переменная типа unsigned char, добавленная мною в программу давно, но до сих пор не используемая. Теперь я хочу использовать ее для того, чтобы понять, что я получаю при чтении в эту переменную именно состояния выводов порта A, которые буду читать впоследствии?
Светодиоды загораются. Попробуем отправить эту переменную через COM-порт. Шестнадцатеричное число 38 соответствует символу «8» кода ASCII. В первом эксперименте это число я и отправлю.
switch (input) {
......
PORTB = 0xFF; // Включаем передатчик TXEN = 1; // Включаем передачу putch(0x38);
for (i=0;i<5000;i++); // Пауза
PORTB = 0xFE; // Выключаем передатчик TXEN = 0; // Выключаем передачу
......
}
}
Эта посылка доходит до адресата. Теперь пойдем дальше. Шаг я делаю совсем маленький
– добавляю присвоение переменной состояния порта с маской:
COUNT = PORTA & 0x38;
Все. Нет реакции ни на команду «a», которая ничего не должна делать, только погасить все светодиоды (должна бы), ни на команду «b», которая должна прислать посылку и зажечь все светодиоды. Ни одна из команд не работает. И этого я вновь не понимаю. И не понимаю долго.
Чтобы отвлечься от грустных размышлений о том, как плохо не знать языков, я делаю попытку понять, что не так с самодельным программатором, который не так давно исправно работал. Программа Piklab, как мне кажется, стала вести себя несколько иначе после обновления. Проверить мне это легко, достаточно перезагрузить компьютер и войти в Ubuntu, где программа не обновлялась. И впрямь, когда я запускаю программу в Ubuntu, компилирую текст, а затем записываю его в контроллер, используя самодельный программатор, то ошибок не возникает. Мало того, запись идет гораздо быстрее, а в окне вывода мало сообщений, тогда как в Fedora 7 эти сообщения при записи кода мелькают непрерывно. Я не исключаю, впрочем, случайностей – когда что-то работает неустойчиво, несколько попыток не дают верного результата. А поскольку я перезагрузил компьютер, я возвращаюсь к проблеме не работающей программы. Для продвижения вперед я удаляю всю программу, оставляя только строки вида:
COUNT = PORTA;
COUNT = COUNT << 2; // Сдвиг на два бита влево
В.Н. Гололобов |
Экскурсия по электронике |
463 |
COUNT = COUNT >> 5; // Сдвиг на пять бит вправо
Такими операциями я хочу выделить вводы RA3-RA5 с целью их использования, когда и если мне удастся решить проблемы. С помощью симулятора gpsim я отслеживаю значения порта и переменной COUNT, и вижу, что операции побитового сдвига не выполняются. А это приводит меня к мысли, что дело-то может быть не в моих плохих знаниях, а в том, что используемый мной компилятор SDCC, программирование PIC-контроллеров у которого находится в стадии разработки, не всегда ведет себя корректно. Чтобы проверить это, я загружаю с сайта HI-TECH демо-версию их компилятора PICC. Слегка споткнувшись на то, что полученному мною файлу picc-demo.run в свойствах следует включить опцию «Позволять выполнение файла как программы» на вкладке «Права», я устанавливаю компилятор, перенастраиваю программатор на работу с этим компилятором, поправляю прежний текст (вместо #include <pic16f628a.h> следует записать #include <pic16f62xa.h>, а еще лучше этого не писать а добавить #include <htc.h>), удалив строку настройки конфигурации по адресу 2007h. Код программы компилируется, а программа работает.
С элегантной записью слова конфигурации по адресу 2007h я пока не знаю что сделать, по причине чего использую «обходной маневр» – записываю программу в контроллер из Piklab, прочитываю ее, а затем поправляю слово конфигурации в окошке обозначенном адресом «2007», куда записываю 2118. Результирующую программу я записываю еще раз. Долго, но работает. Кстати, и самодельный программатор опять работает без ошибок, что может быть случайностью.
Рис. 5.4. Работающая программа после смены компилятора
Я даже могу себе позволить замыкая выводы на землю получить несколько значений – b6, b5 и b3. В этом есть своя прелесть, не так уж я неправ, но есть и недостаток, связанный с тем, что компилятор HI-TECH не генерирует файл .cod, который нужен gpsim для полноценной симуляции. Кроме того, компилятор в полной версии проработает 45 дней, потом его