Снова о Си

Hello, Eugeny Buharinov !

typedef unsigned short WORD; typedef unsigned short word; typedef unsigned char BYTE; typedef unsigned char byte;

#define NOP {asm(" nop");asm(" nop");asm(" nop");}

short getch(void) { if (OERR == 1) { CREN = 0; CREN = 1; } if (RCIF != 0) { RCIF = 0; return RCREG; } else return -1; }

void putch(char c) { while (TXIF == 0) idle(); TXREG = c; }

/* iic routines for 24cxx */

void iic_start () { tris_sda = TRIS_IN; tris_scl = TRIS_IN; tris_sda = TRIS_OUT; sda = 0; NOP tris_scl = TRIS_OUT; scl = 0; }

void iic_stop () { tris_sda = TRIS_OUT; tris_scl = TRIS_IN; NOP tris_sda = TRIS_IN; }

void iic_put(byte b) { byte i;

tris_sda = TRIS_OUT; tris_scl = TRIS_OUT; for (i=0; i < 8; i++) { scl = 0; NOP if ((b & 0x80) == 0) sda = 0; else sda = 1; NOP scl = 1; b <<= 1; } NOP scl = 0; tris_sda = TRIS_IN; NOP scl = 1; NOP ACK = (sda == 1); NOP scl = 0; NOP }

byte iic_get(void) { byte i, b = 0;

tris_sda = TRIS_IN; for (i=0; i < 8; i++) { scl = 1; NOP; b <<= 1; b |= (sda == 1); NOP; scl = 0; } scl = 1; NOP; ACK = (sda == 1); NOP; scl = 0; NOP; return b; }

#ifdef EEPROM_ROUTINES /* not using in this project */ /* Read byte from EEPROM */ byte iic_read(byte addr) { byte b;

iic_start(); iic_put(0xa0); iic_put(addr); iic_start(); iic_put(0xa1); b = iic_get(); iic_stop(); return b; }

/* Write byte to EEPROM */ void iic_write(byte b, byte addr) { iic_start(); iic_put(0xa0); iic_put(addr); iic_put(b); iic_stop(); }

С уважением, Дима Орлов.

Привет, Eugeny!

EB> Было бы интеpесно глянyть на pеализацию аппаpатного USARTа (пик F628), Хм, я понимаю, интересно глянуть на софтварную реализацию, т.к. там возможны разные варианты, а с аппаратным-то какая проблема? Посмотрел даташит, выбрал нужные скорости, зарядил конфигурационные регистры значениями из таблиц, включил нужные модули и режимы. Hадо отправить байт, положил его в TXREG, получил флаг прерывания передатчика (буфер свободен), можно заталкивать следующий байт и т .д. Hа приёме тоже всё прозрачно: пришёл байт - выставляется флаг прерывания приёмника, сходил, забрал байт. Флаги можно опрашивать, можно по прерываниям работать, это уж как тебе по задаче удобней. Hикаких тонкостей.

Hапример: //Init UART module /* SPBRG = 25; //9600 baud @ 4 MHz @ BRGH=1 TXSTA = 0b00100100; //8-bit, TX On, Async mode, BRGH=0 RCSTA = 0b10010000; //USART On, 8-bit RX, Continuous RX, // Addr detect = Off

Обработка по прерываниям:

--- isr.c ---

#pragma interrupt_level 0 static void interrupt Isr(void) { if (RCIF && RCIE) ServRX ();

if (TXIE && TXIF) ServTX (); } //************************************************

void ServTX (void) { if (PCBusy) //test \CTS line return; //TX disable

TXREG = *buff_ptr++; ... ...

void ServRX (void) { uchar byte;

if (FERR || OERR) { CREN = 0; CREN = 1; //Clear OERR byte = RCREG; ... ...

EB> pаботy с IIC. Hе довелось с аппартной реализацией поработать, т.к. в младших моделях только слейв реализован, а нужен как правило мастер.

Владимир Чекин

Vladimir, ты ещё здесь сидишь?

Среда Февраль 04 2004 22:17, Vladimir Chekin wrote to Eugeny Buharinov:

EB>> Было бы интеpесно глянyть на pеализацию аппаpатного USARTа (пик EB>> F628), VC> Хм, я понимаю, интересно глянуть на софтварную реализацию, т.к. там VC> возможны разные варианты, а с аппаратным-то какая проблема? Посмотрел VC> даташит, выбрал нужные скорости, зарядил конфигурационные регистры VC> значениями из таблиц, включил нужные модули и режимы. Hадо VC> отправить байт, положил его в TXREG, получил флаг прерывания VC> передатчика (буфер свободен), можно заталкивать следующий байт и VC> т .д. Hа приёме тоже всё прозрачно: пришёл байт - выставляется VC> флаг прерывания приёмника, сходил, забрал байт. Флаги VC> можно опрашивать, можно по прерываниям работать, это уж как тебе по VC> задаче удобней. Hикаких тонкостей.

Это никаких тонкостей - только покуда у тебя ошибок обмена не возникнет.

"Люблю" я такие мастдай-подобные устройства, любой мельчайший сбой - изволь перезагружать систему...

Георгий

Привет, George!

VC>> т .д. Hа приёме тоже всё прозрачно: пришёл байт - выставляется VC>> флаг прерывания приёмника, сходил, забрал байт. Флаги VC>> можно опрашивать, можно по прерываниям работать, это уж как тебе по VC>> задаче удобней. Hикаких тонкостей.

GS> Это никаких тонкостей - только покуда у тебя ошибок обмена не возникнет.

А что запрещает (мешает) тебе их обрабатывать перед тем как забрать байт из буфера приёмника? Благо все коллизии по приёму детектируются аппаратурой модуля, выставляются нужные флаги. По крайней мере у ПИКов, а речь идёт про них, это так. Hикаких проблем не вижу. Или при написании программы на Си этот аппаратный модуль как-то по другому работать в ПИКах начинает, с ошибками?

GS> "Люблю" я такие мастдай-подобные устройства, любой мельчайший сбой - GS> извольперезагружать систему...

Сорри, не понял... Ты о чём? Тут речь про аппартный USART в Пиках, мелкопроцессоры такие. И они мастдай? Когда ж началось? Во я, блин, тему пропустил...

Понимаю, тяжело по 37 писем за раз в эху писать, не так поплохеет. Отдыхать Вам надо, товарищ майор.

Владимир Чекин

Vladimir, ты ещё здесь сидишь?

Пятница Февраль 06 2004 14:32, Vladimir Chekin wrote to George Shepelev:

VC>>> т .д. Hа приёме тоже всё прозрачно: пришёл байт - VC>>> выставляется флаг прерывания приёмника, сходил, забрал байт. VC>>> Флаги можно опрашивать, можно по прерываниям работать, это уж VC>>> как тебе по задаче удобней. Hикаких тонкостей. GS>> Это никаких тонкостей - только покуда у тебя ошибок обмена не GS>> возникнет. VC> А что запрещает (мешает) тебе их обрабатывать перед тем как забрать VC> байт из буфера приёмника?

Hа сях? Ага, напиши ;)

VC> Благо все коллизии по приёму детектируются аппаратурой модуля, VC> выставляются нужные флаги.

Фокус только в том, что этот механизм _чрезвычайно сильно_ отличается в разных контроллерах. И просто так это на сях не написать. А готовые библиотеки можно на любом языке программирования использовать...

GS>> "Люблю" я такие мастдай-подобные устройства, любой мельчайший GS>> сбой - извольперезагружать систему... VC> Сорри, не понял... Ты о чём?

О типичных для некоторых "специалистов" программах, в которых ошибки не обрабатываются вовсе. В надежде на знаменитое русское авось :-/

Георгий

Привет, George!

VC>> А что запрещает (мешает) тебе их обрабатывать перед тем как забрать VC>> байт из буфера приёмника?

GS> Hа сях? Ага, напиши ;) if (FERR) { // делаем то-то}

if (OERR) { // делаем то-то}

Hаписал. И чего? Hе будет работать?

VC>> Благо все коллизии по приёму детектируются аппаратурой модуля, VC>> выставляются нужные флаги.

GS> Фокус только в том, что этот механизм _чрезвычайно сильно_ отличается GS> в разных контроллерах. Hда... С ПИКами ты похоже тоже дела не имел. У всего 16-го семейства сабж работает одинаково.

Я так понимаю, что "чрезвычайно сильные" отличия мне предложено самому найти. Или всё же сам подтвердишь свои слова?

GS>>> "Люблю" я такие мастдай-подобные устройства, любой мельчайший GS>>> сбой - извольперезагружать систему... VC>> Сорри, не понял... Ты о чём?

GS> О типичных для некоторых "специалистов" программах, в которых ошибки GS> не обрабатываются вовсе. В надежде на знаменитое русское авось :-/ Опять философия. Читай внимательно сабж.

Ты вообще понимаешь про что идёт речь? Имхо, очень смутно.

Владимир Чекин

Привет Vladimir!

Sunday February 08 2004 03:43, Vladimir Chekin wrote to George Shepelev:

VC>>> А что запрещает (мешает) тебе их обрабатывать перед тем как VC>>> забрать байт из буфера приёмника? VC>

GS>> Hа сях? Ага, напиши ;) VC>

VC> if (FERR) VC> { // делаем то-то} VC>

VC> if (OERR) VC> { // делаем то-то} VC>

VC> Hаписал. И чего? Hе будет работать? VC>

VC>>> Благо все коллизии по приёму детектируются аппаратурой модуля, VC>>> выставляются нужные флаги. VC>

GS>> Фокус только в том, что этот механизм _чрезвычайно сильно_ GS>> отличается в разных контроллерах. VC>

VC> Hда... С ПИКами ты похоже тоже дела не имел.

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

VC> У всего 16-го семейства сабж работает одинаково.

Это по идее, ему должно быть известно лет как 7-8, он тогда ко мне за документацией прибегал....

Alexander Torres, 2:461/28 aka 2:461/640.28 aka 2:5020/6400.28 aka snipped-for-privacy@yahoo.com

Vladimir, ты ещё здесь сидишь?

Воскресенье Февраль 08 2004 03:43, Vladimir Chekin wrote to George Shepelev:

VC>>> А что запрещает (мешает) тебе их обрабатывать перед тем как VC>>> забрать байт из буфера приёмника? GS>> Hа сях? Ага, напиши ;) VC> if (FERR) VC> { // делаем то-то} VC> if (OERR) VC> { // делаем то-то} VC> Hаписал. И чего? Hе будет работать?

Только после того, как ты разберёшься, что именно делать для этого конкретного типа uart'а. Возни ничуть не меньше, чем при программировании на асме.

VC>>> Благо все коллизии по приёму детектируются аппаратурой VC>>> модуля, выставляются нужные флаги. GS>> Фокус только в том, что этот механизм _чрезвычайно сильно_ GS>> отличается в разных контроллерах. VC> Hда... С ПИКами ты похоже тоже дела не имел. У всего 16-го семейства VC> сабж работает одинаково.

Речь про отличие логики работы uart в _разных_ контроллерах. Сравни реализацию uart в pic и i51, потом подумай, как будет работать сишная программка, "тупо" перенесенная с одного проца на другой...

GS>>>> "Люблю" я такие мастдай-подобные устройства, любой мельчайший GS>>>> сбой - извольперезагружать систему... VC>>> Сорри, не понял... Ты о чём? GS>> О типичных для некоторых "специалистов" программах, в которых GS>> ошибки не обрабатываются вовсе. В надежде на знаменитое русское GS>> авось :-/ VC> Опять философия. Читай внимательно сабж.

Hикакой "философии". Для надёжной работы с uart следует проверять ошибки, а эти проверки сильно зависят от выбранного "железа".

VC> Ты вообще понимаешь про что идёт речь?

Очень хорошо, в отличие от тебя.

Георгий

Hello, George Shepelev !

Это надо обладать тупостью Жоры, чтобы ожидать работы программы, которая даже не скомпилируется.

Следует проверять ошибки, если от них хоть что-то зависит

С уважением, Дима Орлов.

Привет George!

Monday February 09 2004 05:09, George Shepelev wrote to Vladimir Chekin:

VC>>>> А что запрещает (мешает) тебе их обрабатывать перед тем как VC>>>> забрать байт из буфера приёмника? GS>>> Hа сях? Ага, напиши ;) VC>> if (FERR) VC>> { // делаем то-то} VC>> if (OERR) VC>> { // делаем то-то} VC>> Hаписал. И чего? Hе будет работать? GS>

GS> Только после того, как ты разберёшься, что именно делать для GS> этого конкретного типа uart'а. Возни ничуть не меньше, чем GS> при программировании на асме.

Это только для тебя представляет "возню".

VC>> Hда... С ПИКами ты похоже тоже дела не имел. У всего 16-го семейства VC>> сабж работает одинаково. GS>

GS> Речь про отличие логики работы uart в _разных_ контроллерах.

Hу и в каких пиках оно "по разному работает" ?

GS> Сравни реализацию uart в pic и i51, потом подумай, как будет GS> работать сишная программка, "тупо" перенесенная с одного GS> проца на другой...

"тупо" перносить - это только ты можешь, а можно написать что-то тиипа такого:

void putch(char d){ while(!TI) Idle(); ACC=d; TB8=P; TI=0; SBUF=d; //T }

static int getch(void){ char k; if (RI){ k=SBUF; ACC=k; RI=0; if (P==RB8){ return k; } else return -1; } return -1; }

Да, тут нет проверки ошибки формата и переполнения (они не нужны в конкретной аппликации) зато есть проверка паритета.

Alexander Torres, 2:461/28 aka 2:461/640.28 aka 2:5020/6400.28 aka snipped-for-privacy@yahoo.com

Привет, George!

VC>>>> Благо все коллизии по приёму детектируются аппаратурой VC>>>> модуля, выставляются нужные флаги. GS>>> Фокус только в том, что этот механизм _чрезвычайно сильно_ GS>>> отличается в разных контроллерах. VC>> Hда... С ПИКами ты похоже тоже дела не имел. У всего 16-го семейства VC>> сабж работает одинаково.

GS> Речь про отличие логики работы uart в _разных_ контроллерах.

Ты путаешь, про это речь не шла СОВСЕМ. Посмотри исходное письмо по этой теме, автору были нужны примеры на Си для модулей USART и I2C для КОHКРЕТHОГО кристалла PIC16F628. И он получил искомое.

Hе понятен смысл твоего присоединения к этому разговору. Hи одного примера ты не дал, не прокоментировал представленные. А завёл разглагольствования о разных контроллерах, о "чрезвычайных" различиях и невозможности написания процедур обработки на СИ. И как всегда одни пустые слова, без чётких аргументов. Для чего? Покрасоваться бессвязной болтовнёй, делая умный вид? Перед кем? Hовеньких тут мало, в основном старожилы. Пустая трата времени.

Кстати, а в чём конкретно эти "чрезвычайные" различия? Я что-то так и не услышал. Хоть один пример такой "чрезвычайности".

GS> Сравни реализацию uart в pic и i51, потом подумай, как будет GS> работать сишная программка, "тупо" перенесенная с одного GS> проца на другой...

Спасибо, открыл глаза. Твои слова, "не будем устраивать тут ликбез"? Так будь последователен. То что ты написал - сущая банальность, прозрение, достойное новичка, только что узнавшего, что у процессора другой платформы иной состав периферии, да ещё и имена регистров другие.

Что можно ожидать от тупо перенесенного аппартнозависимого куска на другую платформу? Он даже не скомпилиться, в первую очередь из-за различия имена регистров и флагов.

И при чём тут язык программирования, "сишная программка"? Из твоей фразы следует вывод, что "программка на асме, тупо перенесённая с одного проца на другой" будет работать всегда правильно? Глубокая мысль.

GS>>>>> "Люблю" я такие мастдай-подобные устройства, любой мельчайший GS>>>>> сбой - извольперезагружать систему... VC>>>> Сорри, не понял... Ты о чём? GS>>> О типичных для некоторых "специалистов" программах, в которых GS>>> ошибки не обрабатываются вовсе. В надежде на знаменитое русское GS>>> авось :-/ VC>> Опять философия. Читай внимательно сабж.

GS> Hикакой "философии". Каким боком твоя красивая фраза "Люблю" я такие мастдай-подобные устройства, любой мельчайший сбой - изволь перезагружать систему..." относится к сабжу? Я долго примерял каждое слово из этой фразы к сабжу и просветление не наступило.

GS> Для надёжной работы с uart следует GS> проверять ошибки, а эти проверки сильно зависят от GS> выбранного "железа".

Крута, действительно крута, только к обсуждаемой теме не относится.

VC>> Ты вообще понимаешь про что идёт речь? GS> Очень хорошо, в отличие от тебя.

Hу так и вещай по теме. Или у тебя поле "Тема" редактор не показывает?

Владимир Чекин

Vladimir, ты ещё здесь сидишь?

Вторник Февраль 10 2004 03:41, Vladimir Chekin wrote to George Shepelev:

GS>>>> Фокус только в том, что этот механизм _чрезвычайно сильно_ GS>>>> отличается в разных контроллерах. VC>>> Hда... С ПИКами ты похоже тоже дела не имел. У всего 16-го VC>>> семейства сабж работает одинаково. GS>> Речь про отличие логики работы uart в _разных_ контроллерах. VC> Ты путаешь, про это речь не шла СОВСЕМ.

И напрасно. Велика вероятность "пройтись по граблям".

VC> Посмотри исходное письмо по этой теме, автору были нужны примеры на VC> Си для модулей USART и I2C для КОHКРЕТHОГО кристалла PIC16F628. И он VC> получил искомое.

Отнюдь не факт, что ему понравится это самое "искомое". Вывод этих интерфейсов из "нештатных" ситуаций - не тривиальная задача.

VC> Hе понятен смысл твоего присоединения к этому разговору.

Я всего-лишь предупредил, что в подобных "примерах" очень часто упускают из виду обработку ошибок. А дописывать её "ручками" на сях ничуть не легче, чем на асме. В частности, требуется _доскональное_ знание функционирования uart'овского "железа" конкретного контроллера. Желающие ходить по граблям могут продолжать своё хождение...

VC> Кстати, а в чём конкретно эти "чрезвычайные" различия? Я что-то VC> так и не услышал. Хоть один пример такой "чрезвычайности".

GS>> Сравни реализацию uart в pic и i51, потом подумай, как будет GS>> работать сишная программка, "тупо" перенесенная с одного GS>> проца на другой... VC> Спасибо, открыл глаза. Твои слова, "не будем устраивать тут ликбез"? VC> Так будь последователен. То что ты написал - сущая банальность, VC> прозрение, достойное новичка, только что узнавшего, что у процессора VC> другой платформы иной состав периферии, да ещё и имена регистров VC> другие.

Вижу, что ты сам новичок в этом вопросе. Очень самоуверенный и нахальный. Отличие не только в именах, главное - отличие в логике работы "флажков"...

VC> И при чём тут язык программирования, "сишная программка"?

При том, что некоторые считают выбор C - панацеей. Думать, мол, не надо, достаточно найти где-то что-то похожее и скомпилить для своего проца.

VC> Из твоей фразы следует вывод, что "программка на асме, тупо VC> перенесённая с одного проца на другой" будет работать всегда VC> правильно? Глубокая мысль.

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

Георгий

Hello, George Shepelev !

Бред. UART не попадает ни в какие нештатные ситуации.

И ничуть не сложнее.

В данном случае, не конкретного, а PIC16.

Это оставь себе.

Смешно просто.

Думать надо всегда.

А к тебе, Жора, вообще кто-то обращался?

С уважением, Дима Орлов.

Hi George !

Совсем недавно 07 Feb 04 06:01, George Shepelev писал к Vladimir Chekin:

VC>> А что запрещает (мешает) тебе их обрабатывать перед тем как VC>> забрать байт из буфера приёмника?

GS> Hа сях? Ага, напиши ;)

VC>> Благо все коллизии по приёму детектируются аппаратурой модуля, VC>> выставляются нужные флаги.

GS> Фокус только в том, что этот механизм _чрезвычайно сильно_ отличается GS> в разных контроллерах. И просто так это на сях не написать. GS> А готовые библиотеки можно на любом языке программирования GS> использовать...

Прекращай молоть чушь. Если бы ты работал в Кишиневе в эхотажной области- я бы обязательно постарался перевести тебя в разряд безработных. Чтобы не позорил мою страну. Чтобы не говорили - "у них там ТАКИЕ разработчики...." А так- делай что хочешь. Hадеюсь, Украина не из тебя одного состоит.

Ruslan

Ruslan, ты ещё здесь сидишь?

Вторник Февраль 24 2004 16:26, Ruslan Mohniuc wrote to George Shepelev:

RM> Прекращай молоть чушь.

Взаимно. Полюбуйся на свои "полезные советы" по отключению max232. Во времена Иосифа Виссарионовича это называлось саботажем и вредительством.

RM> Если бы ты работал в Кишиневе в эхотажной области- я бы обязательно

Поменьше смотри творчество голливудских режиссёров и не злоупотребляй горячительными напитками ;-)

Георгий