PinBoard в руках Чайника - MicroPascal и LCD

AVR
И снова Чайники атакуют, на этот раз на вооружении чайников МикроПаскаль и LCD. Задача стоит перед нами простая: научиться отображать как символы латиницы так и кириллицы при помощи средств МикроПаскаля.
Первое что нужно нам сделать так это подключить дисплей. Подключать его будем по схеме которая указана в быстром старте PinBoard.

PB0 - E (6) 
PB1 - RW (5) //// Можно кинуть на GND
PB2 - RS (4) 
 
PB4 - DB4 (11) 
PB5 - DB5 (12) 
PB6 - DB6 (13) 
PB7 - DB7 (14) 

Микро паскаль имеет встроенную библиотеку для работе с LCD, вот его и будем сегодня мучить. Должен обратить внимание на то, библиотека lcd не управляет сигналом RW дисплея, поэтому RW нужно кинуть на GND или управлять ручками.

Для корректной работы LCD необходимо указать как мы подключили его. Для этого существуют спец. переменные, настраиваем их:
LCD_RS : sbit  at PORTB2_bit;       
LCD_EN : sbit  at PORTB0_bit;       
LCD_D4 : sbit  at PORTB4_bit;       
LCD_D5 : sbit  at PORTB5_bit;       
LCD_D6 : sbit  at PORTB6_bit;       
LCD_D7 : sbit  at PORTB7_bit;       
LCD_RS_Direction : sbit at DDB2_bit;
LCD_EN_Direction : sbit at DDB0_bit;
LCD_D4_Direction : sbit at DDB4_bit;
LCD_D5_Direction : sbit at DDB5_bit;
LCD_D6_Direction : sbit at DDB6_bit;
LCD_D7_Direction : sbit at DDB7_bit;

Теперь библиотека LCD знает как физически у нас подключен экранчик, осталось дать команду Lcd_Init() и можно будет выводить символы.
Рассмотрим команды для работы с LCD:

Lcd_Out(row: byte; column: byte; var text: string);
Выводит на LCD текстовую строку text в строке row позиции column.
txt:='Hello';
Lcd_Out(1,1,txt)
выведет текст «Hello» в позиции 1,1 (1 строка,1 символ).
Lcd_Out_CP(var text: string);
Выводит на LCD текстовую строку text в текущей позиции курсора.

Lcd_Chr(row: byte; column: byte; out_char: byte);
Выводит один символ код которого находится в переменной out_char в позицию row (строка),column (столбец).

Lcd_Chr_CP(out_char: byte);
Выводит один символ код которого находится в переменной out_char в текущей позиции курсора.

Lcd_Cmd(out_char: byte);
Посылает команду LCD экрану.
Список команд:

  • _LCD_FIRST_ROW Передвигает курсор на первую строку
  • _LCD_SECOND_ROW Передвигает курсор на вторую строку
  • _LCD_THIRD_ROW Передвигает курсор на третью строку
  • _LCD_FOURTH_ROW Передвигает курсор на четвертую строку
  • _LCD_CLEAR Очистка экрана
  • _LCD_RETURN_HOME Возврат курсора в начальное положение, отмена сдвига дисплея. Память дисплея не затрагивается
  • _LCD_CURSOR_OFF Выключить отображение курсора
  • _LCD_UNDERLINE_ON Включить отображение курсора в виде символа подчеркивания
  • _LCD_BLINK_CURSOR_ON Включить моргание курсора
  • _LCD_MOVE_CURSOR_LEFT Передвинуть курсор влево без затрагивания памяти дисплея
  • _LCD_MOVE_CURSOR_RIGHT Передвинуть курсор вправо без затрагивания памяти дисплея
  • _LCD_TURN_ON Включить дисплей
  • _LCD_TURN_OFF Выключить дисплей
  • _LCD_SHIFT_LEFT Сдвинуть дисплей влево без затрагивания памяти дисплея
  • _LCD_SHIFT_RIGHT Shift Сдвинуть дисплей вправо без затрагивания памяти дисплея

Казалось бы все просто, присвоили txt:='Привет!' и вывели Lcd_Out(1,1,txt), но есть один нюанс — при выводе кириллицы нужно позаботиться о перекодировки с ASCII в кодировку понятную LCD, иначе будет каша. Привожу процедуру, которая занимается перекодировкой строк.
procedure ConvToAscii(var str:string);
const
rusTable:array[0..63] of char= (
0x41, 0xA0, 0x42, 0xA1, 0xE0, 0x45, 0xA3, 0xA4, 0xA5, 0xA6, 0x4B, 0xA7, 0x4D, 0x48, 0x4F, 0xA8,
0x50, 0x43, 0x54, 0xA9, 0xAA, 0x58, 0xE1, 0xAB, 0xAC, 0xE2, 0xAD, 0xAE, 0xAD, 0xAF, 0xB0, 0xB1,
0x61, 0xB2, 0xB3, 0xB4, 0xE3, 0x65, 0xB6, 0xB7, 0xB8, 0xB9, 0xBA, 0xBB, 0xBC, 0xBD, 0x6F, 0xBE,
0x70, 0x63, 0xBF, 0x79, 0xE4, 0x78, 0xE5, 0xC0, 0xC1, 0xE6, 0xC2, 0xC3, 0xC4, 0xC5, 0xC6, 0xC7);
var
i:byte;
begin
i:=0;
while(str[i]<>0) do
  begin
  if str[i]>=0xC0 then str[i]:=rusTable[str[i]-0xC0]; //если код символа больше или равно 192, то конвертим его
  inc(i);
  end;
end;

На входе у нее строка в ASCII, после отработки строки она будет уже готова к употреблению в LCD.
Вот собственно код для теста LCD.

program PinBoardLCD;

var
///Указываем как подключен у нас LCD  ///
LCD_RS : sbit  at PORTB2_bit;          //
LCD_EN : sbit  at PORTB0_bit;          //
LCD_D4 : sbit  at PORTB4_bit;          //
LCD_D5 : sbit  at PORTB5_bit;          //
LCD_D6 : sbit  at PORTB6_bit;          //
LCD_D7 : sbit  at PORTB7_bit;
LCD_RS_Direction : sbit at DDB2_bit;   //
LCD_EN_Direction : sbit at DDB0_bit;   //
LCD_D4_Direction : sbit at DDB4_bit;   //
LCD_D5_Direction : sbit at DDB5_bit;   //
LCD_D6_Direction : sbit at DDB6_bit;   //
LCD_D7_Direction : sbit at DDB7_bit;   //
////////////////////////////////////////

txt,txt1:array[0..16] of char;

procedure ConvToAscii(var str:string);  //// процедура конвертации "неправильной" в "правильную" кодировку
const
rusTable:array[0..63] of char= (
0x41, 0xA0, 0x42, 0xA1, 0xE0, 0x45, 0xA3, 0xA4, 0xA5, 0xA6, 0x4B, 0xA7, 0x4D, 0x48, 0x4F, 0xA8,
0x50, 0x43, 0x54, 0xA9, 0xAA, 0x58, 0xE1, 0xAB, 0xAC, 0xE2, 0xAD, 0xAE, 0xAD, 0xAF, 0xB0, 0xB1,
0x61, 0xB2, 0xB3, 0xB4, 0xE3, 0x65, 0xB6, 0xB7, 0xB8, 0xB9, 0xBA, 0xBB, 0xBC, 0xBD, 0x6F, 0xBE,
0x70, 0x63, 0xBF, 0x79, 0xE4, 0x78, 0xE5, 0xC0, 0xC1, 0xE6, 0xC2, 0xC3, 0xC4, 0xC5, 0xC6, 0xC7);
var
i:byte;
begin
i:=0;
while(str[i]<>0) do
  begin
  if str[i]>=0xC0 then str[i]:=rusTable[str[i]-0xC0]; //если код символа больше или равно 192, то конвертим его
  inc(i);
  end;
end;


begin
     ///Можно обойтись без этих команд если RW сигнал дисплея подтянуть на GND
     DDB1_bit:=1;  //вывод PORTB.1 как выход
     PORTB1_bit:=0; //выводим его в нолик
     /////////////////

    Lcd_Init();                        // Инициализация LCD
    Lcd_Cmd(_LCD_CLEAR);               // Очищаем LCD
    Lcd_Cmd(_LCD_CURSOR_OFF);          // Вырубаем курсор
    txt:='2011 PinBoard';
    txt1:='Пример русиша:-)';
    ConvToAscii(txt);                  //Конвертируем строку txt
    ConvToAscii(txt1);                 //Конвертируем строку txt1
    LCD_Out(1,1,txt);                  //Выводим строку txt в первой строке с позиции 1
    LCD_Out(2,1,txt1);                 //Выводим строку txt во второй строке с позиции 1

while(1) do
  begin
  //курим бамбук до бесконечности
  end;

end.


Готовый проект в MicroPascal и hex файл
  • +1
  • 21 марта 2011, 15:03
  • Episcop

Комментарии (40)

RSS свернуть / развернуть
Микропаскаль орудие дьявола! Брось каку! :)
0
Дык я это, просто)) Вообще я ассемблерщик. А статейку для развития написал.
0
Нда, библиотеки микропаскаля (железные особенно) мне нравятся еще меньше, чем он сам. Какие-то они закрытые, негибкие, плохо документированные и вообще подозрительные (особенно в плане «что там творится с задержками и cli/sei?»). А закрытость не позволяет раскурить код и найти ответы на все эти вопросы (и/или допилить). Эта библиотека например явно должна тупить в почти всех функциях, причем с запасом — без RW от диплея BUSY не получить.
Еще плохо, что нету ни своего макропроцессора, ни настройки custom build'а. А то можно было бы писать строки на человеческом языке и конвертировать в compile time.

Кстати, сколько весит скомпилированный пример? Тока желательно без функции конвертирования кодировки.
0
Вместе с конвертированием кодировки — 1591 байт, без — 1374 байт.
Закрытость это для меня тоже ппц. И я еще в шоке от входных параметров модулей, какие то переменные надо объявлять, ни в какие ворота не лезет это.
0
Переменные это как раз нормально. Это довольно забавный способ для привязки к регистрам в mP, без оверхеда. Я его описывал.
А вот размер удручает. Чую я, если хочу упихать все желаемое хотя бы принципиально необходимое в tiny2313 — придется курить асм. Или, хотя бы, С/С++ (на х86 они уже уверенно запинывают ассемблерщиков по оптимальности кода).
0
Да не то чтобы плохой. Компилит он неплохо и оптимизирует ничо так. Просто паскаль мертвый язык. И с каждым годом все мертвей и мертвей.
0
Не надо наезжать на паскаль. Мне не нравится именно mP. Если допиливать паскаль более адекватно, можно получить не менее подходящую для МК штуку, чем С. Хотя да, получится котопес со всеми минусами С)
Алсо, как-то мне не нравится его оптимизация. Мне кажется, код мог бы быть и поменьше. Намного притом. Похоже, на mP в какой-нить tiny1xxx ничего серьезней мигалки светодиодом не запихать :(
0
тебе на баском нельзя смотреть
0
Баском это пиздец. я видел. Даже правил код написанный на нём
0
Ну это смотря в чьих руках :-)
0
ну почему же, в правильных руках и хуй — молоток.
0
Кстати, авторы mP — немцы. Так что называется он mikroPascal) И на него уже три разных тега)
0
  • avatar
  • Vga
  • 21 марта 2011, 17:24
Кстати, авторы mP — немцы.
Сербы на самом деле, как выяснилось. Впрочем, все равно mikro.
0
блин вот все пишут какой микропаскаль плохой, что это дерьмо и все прочее. Вы хоть обьясните чем он плох то. Я микроконтроллерами занимаюсь в качестве хобби, писал и на С и на микропаскале. Все работало. Чем он хуже С не понял, зато сам компилятор помойму очень удобный.
0
Сишники — просто не уважают, они с паскалистами всегда срались.
А я писал, чем оно мне не нравится.
0
блин вот все пишут какой микропаскаль плохой, что это дерьмо и все прочее. Вы хоть обьясните чем он плох то.
«Сие тайна велика есть»…

Его хают те, кто на нем писать не умеет.
Ну, и обкуренные фанаты, прочитавшие когда — то где — то, что «Истинные программисты пишут только на C !!!»…

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

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

Я пишу на нем и для PIC, и для AVR, все хорошо и просто. И размеры своих программок не раз приводил. Не каждый на С в такой размер уложится при том же функционале.

Писал я и на ассемблере, и Бэйсике, и на других языках. И С++ когда — то пробовал… А все же выбрал Паскаль и Дельфи. И ни разу не пожалел.

Мне — нравится, и вполне устраивает. Кому не нравится — это их личное горе. Значит, не судьба…
0
Зато синтаксис Паскаля интуитивно понятен, не то что Сишные закорючки.
То-то твои листинги на нем больше ассемблер напоминают, чем паскаль. И прокомментированы так же.
И оптимизатор никакого отношения к алгоритмической оптимизации не имеет. Он просто должен из читабельного кода сгенерить оптимальный, а не вынуждать писать понятно для компилера, а не человека. Я хочу писать кратко и понятно, это компилер должен превратить «UCSRB:=UCSRB or (1 shl RXEN) or (1 shl TXEN) or (1 shl UDRIE)» в «IN R0, UCSRB; ORI R0, 14; OUT R0, UCSRB», а не «IN R0, UCSRB; ORI R0, 2; ORI R0, 4; ORI R0, 8; OUT R0, UCSRB» и не заставлять меня писать быдлокод «UCSRB:=UCSRB or $0E», как у тебя.
Вот к дельфи у меня нареканий нет. Ее оптимизатор хоть и менее эффективен, чем сишный, но зато вызывает куда меньше проблем и работает куда лучше, чем mP.
0
И С++ когда — то пробовал… А все же выбрал Паскаль и Дельфи. И ни разу не пожалел.
Мне — нравится, и вполне устраивает.
о какой объективности говорить?
0
о какой объективности говорить?
А какова обьективность тех, кто хаит Паскаль, не умея им пользоваться, а то и вовсе даже не попробовав?

А таких среди хаятелей — подавляющее большинство.
0
ну, кто «слышал звон» да. безосновательные заявления. впрочем, учится пользоваться микро*(подставить свое) нет ни малейшего желания. как, скажем, АВ, там, или драконом или еще какой поделкой.
0
Лично я — матерый дельфист. И плююсь на микропаскаль больше, чем на ненавистный С. Это символизирует.
0
Лично я — матерый дельфист. И плююсь на микропаскаль больше, чем на ненавистный С. Это символизирует.
Не нравится — не ешь.
Чего плеваться — то?

Может, для профессионала с большим опытом написания программ для компа, МикроПаскаль и покажется слишком простым (как же на нем, без обьектов — то!).
Но тем, для кого микроконтроллеры и их программирование — всего лишь хобби, он позволяет, не шибко напрягаясь, написать нужную ему программу за вечер. И она — заработает.
В то время как tru Cишник потратит на нее, может, неделю, и долго будет трахаться еще с ее отладкой.

МикроПаскаль — самодостаточен, содержит все, что надо, в библиотеках, и новичку не надо изобретать велосипед или искать посторонние библиотеки для работы, например, с графическим индикатором, флэшкой, или еще чем — либо. Вплоть до ETHERNET — все есть встроенное. И размер нормально написанных программ не так уж и велик.
И очень дружественная среда, и прекрасные HELPы…

Если кто-то там чего — то не понял, это вовсе не повод хаить нормальный и дружественный к новичкам инструмент.

Мне — пофигу, кто там на чем пишет. Хоть на Алголе или PL/I. Я же их не обсираю… Но почему-то многих начинает бить Кондратий, стоит лишь на этом сайте или форуме помянуть Паскаль или PIC. Фанатизм какой — то… Как будто кто-то их насильно тащит.

У кого есть желание и умение — и на Бэйсике вещи делает.
А у кого тяму нет — и на С да ARM только и будет годами светодиодами мигать…
0
Не нравится — не ешь. Чего плеваться — то?
Чтобы выплюнуть уже съеденное.
МикроПаскаль и покажется слишком простым (как же на нем, без обьектов — то!).
Не в объектах дело. Хотя да, некоторых возможностей не хватает. Хуже, что он даже не способен пропарсить некоторые выражения, допустимые описанным в документации синтаксисом.
он позволяет, не шибко напрягаясь, написать нужную ему программу за вечер. И она — заработает.
Если повезет. А вот с mP for 8051 (точнее с любым версии 2.х, просто 8051 единственный не обновлялся с тех пор) она наверняка не заработает — просто из-з глючного компилятора.
МикроПаскаль — самодостаточен, содержит все, что надо, в библиотеках
Тяжелых, негибких, весьма ограниченных и неизвестной кривости. Учитывая кривость самого компилятора, библиотеки доверия не вызывают.
И очень дружественная среда, и прекрасные HELPы…
Хелпы скудные. Среда — для МК неплохо, но лишь потому, что у других совсем говнище. Впрочем, остальные начали переползать на нормальные среды, так что и этого преимущества mP лишается.
Если кто-то там чего — то не понял, это вовсе не повод хаить нормальный и дружественный к новичкам инструмент.
Я, как раз, все понял. За то и хаю. Дружественный — да. Нормальный — нет.
0
SWG, я тоже пришёл к выводу, что ПИКи в своей архитектурной организации как бы прозрачнее для восприятия в самом начале, нежели АВРы (притом, что я очень далёк от возведения антагонизмов между теми и другими, и уж тем более — от холивара на эту тему).
Так вот, что хочу сказать: если в связке MP+PIC всё обстоит так хорошо, как вы говорите, то может быть вам стоит написать хотя бы белее-менее обстоятельный и практичный «быстрый старт» по этой связке? Ну, подобно «AVR учебный курс»…
Тогда вдумчивый читатель мог бы самостоятельно сравнить то и другое, извлекая из сравнительного анализа несомненную пользу.
Как вы на это смотрите?
+2
Что-то я сомневаюсь, что mP+PIC чем-то отличается от mP+AVR (ну, кроме интерфейсов периферии). Во всяком случае, я работал на mP для AVR и для 8051 и существенной разницы на уровне программиста не заметил. Для PIC и ARM микропаскали у меня стоят, но что-то на них разрабатывать я уже врядли буду, поставил только из-за любви к паскалю.
0
Сербы начинали именно с mikroPascal для PIC и поэтому он получился получше от AVR, а особенно от 51. Насчет Helpов не соглашусь, отличные, F1 на операторе и вот тебе описание обязательно с примером. Библиотеки да тяжелые, но примеры все рабочие. Не нравятся встроенные — пиши свои, есть для этого Package Manager. Хорошая переносимость. Ради любопытства перевел демо-проектик часов с термометром с PICа на STM32 изменением всего нескольких строчек. Инициализацию управляющих линий и настройку портов. Все, часики стали на STM32. По поводу mP для ARM хочу сказать, что очень еще сырой.
0
Сербы начинали именно с mikroPascal для PIC и поэтому он получился получше от AVR, а особенно от 51.
Не знаю, как для 51, а для AVR в последнее время (использую сейчас версию для AVR 4.6), вроде ничего плохого сказать не могу. Пишу на ней программу для Центрального Контроллера (ЦК) своего робота на Меге 128. Пока программа небольшая, для отладки использую также Мегу 64.
Протестированы уже почти все устройства и интерфейсы, имеющиеся на плате ЦК. Каких — либо проблем с компилятором не заметил. Размер кода тоже вполне адекватен выполняемым задачам. Правда, с апреля не брался, не до того было, да и лень… Но скоро продолжу, как с домашними делами закончу. Посмотреть можно на форуме:
forum.easyelectronics.ru/viewtopic.php?f=11&t=6964
forum.easyelectronics.ru/viewtopic.php?f=11&t=1582
Там я подробно освещаю ход работ. Иногда и программы выкладываю, полностью или кусками. Правда, пока еще листинги не прилизаны, постоянно проверяю то один кусок, то другой, что-то меняю, добавляю, переделываю… Но в целом — все рабочее.
0
а для AVR в последнее время (использую сейчас версию для AVR 4.6), вроде ничего плохого сказать не могу.
Ну, в 4.60 я вроде ошибок генерации кода не нашел (в отличие от более ранней версии, но не помню точно какой — то ли 3.хх, то ли 2.хх), но оптимизация по прежнему плохая. Впрочем, на этом хотя бы можно писать, в отличие от версий, где ошибок компилятора в итоговой программе больше, чем моих собственных. Мой пост в основном написан под впечатлением от mikroPascal PRO foir 8051 v.2.20, вот это — адов пиздец. Впрочем, AVR-овый то ли второй, то ли третьей версии тоже сильно кривой. На 4.60 я вполне успешно софтину написал, но размер меня не устраивает, и процентах в 30 оного виноват именно оптимизатор. С тех пор вышел 5.60, его не пробовал вообще.
0
Насчет Helpов не соглашусь, отличные, F1 на операторе и вот тебе описание обязательно с примером.
Бывает, конечно, и хуже, но хелп таки оставляет желать лучшего. Я его таки весь прочитал, так что имею неплохое о нем представление.
Хорошая переносимость. Ради любопытства перевел демо-проектик часов с термометром с PICа на STM32 изменением всего нескольких строчек.
Ну это любой нормальный HAL даст. Хотя и плюсик, да. Но это только если писать на их библиотеках, а не работать напрямую с железом.
0
Help не читал, я им просто пользовался и на освоение по help-у и примерам ушло меньше дня (работал с TurboPascal и Delphi). Набор библиотек такой, что в основном хватает для не больших проектов, а большие я не стал бы делать на mP, при большом количестве совместно используемых библиотек начинают вылазить баги.
0
Я осваивал чисто по хелпу, на это так же не ушло и дня, хелп там на самом деле коротенький. Основные темы в основном освещены, но более глубоко лежащие вопросы приходится выяснять экспериментально.
а большие я не стал бы делать на mP, при большом количестве совместно используемых библиотек начинают вылазить баги.
Хе, чего и следовало ожидать) Ну тащемта для небольших набросков вроде этого я его и оставил.
0
при большом количестве совместно используемых библиотек начинают вылазить баги
«Большое количество используемых библиотек» — подразумевает сложность самой программы, большое число выполняемых ей функций.

А вы уверены, что баги именно из за библиотек, а не из за того, что вы сами чего — то не учли, не додумали? Или неправильно использовали?

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

Если же просто столкнулись с неправильным поведением программы, и не разобравшись в причине, просто ее забросили, — то тут вероятность 99,9% и более, что баг был ваш…

Если же вы склонны валить любое неправильное поведение программы на баги компилятора, а не на собственные ошибки, — то это не есть хорошо, и не раз подведет еще вас в будущем…
0
Если же просто столкнулись с неправильным поведением программы, и не разобравшись в причине, просто ее забросили, — то тут вероятность 99,9% и более, что баг был ваш…
Это в случае с нормальным компилятором. С микроэлектроникой — максимум 90% вероятность, что баг свой (ну, от версии и платформы зависит, на 8051 v2.20 вероятность собственного бага меньше 50%).
0
Это в случае с нормальным компилятором. С микроэлектроникой — максимум 90% вероятность, что баг свой (ну, от версии и платформы зависит, на 8051 v2.20 вероятность собственного бага меньше 50%).
Я бы не был столь категоричен. Другие же как-то с ними работают…

Я обычно просматриваю историю версий программ, которыми пользуюсь. И если там есть упоминание о обнаруженном и исправленном баге, который может иметь значение и для меня, — качаю свежую версию. Но не забывая при этом, что в новой, еще мало обкатанной версии, могут быть и новые баги.
И иногда лучше оставить уже опробованную версию с известным, но не критичным для меня багом, чем рисковать получить новые…

То есть, в наше время постоянных апгрейдов софта через Интернет, программы проверяются и тестируются уже не так тщательно, как лет 20 назад. Да и сами программы стали сложнее. Даже у крупных софтовых фирм что-то да обнаружится…

Тем не менее, я привык доверять компилятору, считая его безошибочным, пока не будет доказано обратное. И не голословно, типа «там все — херня и глючит», а с конкретными фактами.

Что касается компиляторов МикроЭлектроники для 51 и ARM, — они появились позже, соответственно, и они не так хорошо отработаны, как для PIC, например, но работа над ними постоянно ведется, и со временем они будут наверняка лучше.

Я пока использую только МикроПаскаль для PIC и AVR, поэтому мне трудно судить о других. Но эти — меня устраивают, и по совокупности свойств и удобства использования намного превосходят попробованные мной другие. В том числе — и фирменные среды разработки ATMEL и MICROCHIP.

Также я не пользуюсь отладчиками, предпочитая отлаживать программу сразу в реальных условиях, на готовой плате, использую для общения USART или ноги портов. Поэтому не могу ничего сказать и про встроенные в МикроПаскаль отладочные средства.
Некоторые тоже их критиковали. Но для меня это не имеет значения. Я предпочитаю сразу писать правильно, чем потом искать, что там не так.

Фактически, вместо отладки у меня — тщательное тестирование во всех возможных режимах, с устранением некоторых выявленных недоработок.
Да и программу пишу не сразу всю, а отдельными частями, добавляя очередной функционал после полной проверки и отладки уже написанного.
И сначала проверяю новый кусок в монопольном режиме, затем уже — распараллеливаю с другими задачами.

И отладка, в основном, у меня — не устранение ошибок программы, а поиск более оптимального взаимодействия с тем или иным устройством (УЗ локатором, например).

Может, поэтому у меня и проблем с софтом почти не бывает. Чтобы уж совсем не заработало — уж и не помню… Даже — неинтересно…
Особенно такие типовые узлы, как USART, АЦП, ШИМ… Какие там могут быть проблемы — то? Все по даташиту.
Хоть — с библиотеками, хоть — сразу по регистрам…
0
Тем не менее, я привык доверять компилятору, считая его безошибочным, пока не будет доказано обратное.
С хорошими компиляторами, вроде MSVC, Delphi или GCC — так и есть. В той же Delphi я только один раз натыкался на баг компилятора. С mP хуже.
И не голословно, типа «там все — херня и глючит», а с конкретными фактами.
Один конкретный пример кода, с разбором ассемблера я приводил. Другие тоже проверял на уровне ассемблера, и это были именно баги компилятора.
Что касается компиляторов МикроЭлектроники для 51 и ARM, — они появились позже
ARM — да, а вот 8051 старый и заброшен с 2009 года. И я сильно сомневаюсь, что версия 2.20 для AVR (и, возможно, PIC) намного лучше. По крайней мере та версия mPAVR, какую я ставил первой была кривой.
Я предпочитаю сразу писать правильно, чем потом искать, что там не так.
Отладочный вывод в UART — как раз и есть тот самый «искать, что там не так». Программ без ошибок не бывает вообще. Отладчик только позволяет искать их с большим удобством и без специального распихивания по коду отладочных кусков. В компиляторах микроэлектроники отладки по сути нет.
Фактически, вместо отладки у меня — тщательное тестирование во всех возможных режимах, с устранением некоторых выявленных недоработок.
Это и есть отладка.
Чтобы уж совсем не заработало — уж и не помню…
Это, как раз, проще всего в отладке.
0
может быть вам стоит написать хотя бы белее-менее обстоятельный и практичный «быстрый старт» по этой связке? Ну, подобно «AVR учебный курс»…
Как вы на это смотрите?
Да как — то лень… Кроме того, это опять может быть воспринято некоторыми (как уже не раз бывало), что я «навязываю свое мнение», «давлю авторитетом»…
Если даже на отдельные высказывания, не совпадающие с их мнением по поводу ARM или еще чего, набрасываются, как на еретика и старпера.

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

Возможно, имеет смысл завести там еще отдельную темку, в которой уделить еще внимание построению флаговых автоматов, по тем принципам, как я привык их делать, на примере тех же программ для модулей своего робота. Так же — распределение задач между ними, межмодульное взаимодействие…

По основам же программирования на Паскале — не знаю, стоит ли… Тут ничего особенного нет, язык, как язык. Специально созданный когда — то Виртом для обучению правильному структурному программированию.

И в реализации его для микроконтроллеров — вариант от МикроЭлектроники весьма неплох (по сравнению с другими, которые я пробовал до этого). На нем я пишу, не задумываясь над заморочками самого компилятора (типа неудобного синтаксиса в С).
Пишу, как думаю, легко и просто.
В то же время — поднявшись над уровнем ассемблера, не отвлекаясь на мелочи, типа переключения банков, или вычисления коэффициентов и распихивания по куче регистров при инициализации USART или PWM.
Не изобретая велосипед для работы с FAT-16, или еще чего… Все уже есть в библиотеках.

Если же что не устраивает или нет смысла использовать библиотечную функцию, например, для изменения единственно регистра, — работаю и напрямую с регистрами. И код этих кусков получается не намного хуже чисто ассемблерного…

И если кому — то кажутся слишком громоздкими, например, библиотечные универсальные функции работы с дисплеем, с побитовым раскладом ног (что очень удобно, например, для упрощения разводки), то никто не мешает самому написать аналогичную упрощенную функцию, например, когда все ноги индикатора — на одном порту.
Естественно, она будет намного проще. Но только для этого конкретного случая…
0
По основам же программирования на Паскале — не знаю, стоит ли… Тут ничего особенного нет, язык, как язык.

Нет, я имел в виду не язык, а именно данный компилятор, точнее связку с PIC — всё-таки язык языком, а реализация — реализацией, да ещё учитывая специфику целевого контроллера.
По-моему, стоит.
Возможно, имеет смысл завести там еще отдельную темку, в которой уделить еще внимание построению флаговых автоматов, по тем принципам, как я привык их делать, на примере тех же программ для модулей своего робота. Так же — распределение задач между ними, межмодульное взаимодействие…
вот-вот…
Кроме того, это опять может быть воспринято некоторыми (как уже не раз бывало), что я «навязываю свое мнение», «давлю авторитетом»…
Если даже на отдельные высказывания, не совпадающие с их мнением по поводу ARM или еще чего, набрасываются, как на еретика и старпера.
Вот уж самое последнее, на что стоило бы обращать внимание… собака лает — караван идёт.
0
Хороший тут холивар развели.
Лучше то, что бесплтано.
+1
Да нифига, лучше то, что дорого стоит :-)))
0
Да нифига, лучше то, что дорого стоит :-)))
Если только можно скачать его даром, сразу с ключами…
0
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.