SED1335,PIC18F4550 и LCD320x240, разбираем по косточкам модуль SED1335.c Опции

[andreichk]

Привет народ.Вот решил я слепить себе нечто из указанных в теме компонентов.Нарисовал и изготовил макетку, красиво всё распаял и написал из надёрганных в сети кусков маленькую програмку для управления ЖКИ. Вначале, после нудного изучения даташитов никак не мог инициализировать ЖКИ, но потом разобрался что к чему и наконец он начал подавать признаки жизни и засветился.
Компилятор, который я пользую - CCS, имеет в своём составе файл SED1335.C , но как я не пытался приспособить его, так и не смог.Порывшись в сети,я нашёл другой файл с таким же названием, но вроде бы не для ПИКов, а для чего-то другого.Однако , слегка подшаманив его, я смог встроить его в прогу и он заставил таки выдавать на экран символы в текстовом режиме(даже с возможностью размещения в заданое место) и переключаться в графический режим.
И на этом всё и закончилось.
Все попытки нарисовать линию или круг или просто точку,несмотря на множество примеров, я так и не смог. Позаимствовав из старого файла процедуру

void glcd_pixel(int16 x, int16 y, int1 color)
{
int8 data;
int16 addr;
// Calculate the byte address containing the pixel
addr = GLCD_GRAPHICS_ADDR + (GLCD_WIDTH/8 * y + x/8);
// Read the byte of data at the address
data = getData(addr);
// Turn the pixel on or off
if(color == ON)
bit_set(data, 7 - x%8);
else
bit_clear(data, 7 - x%8);
// Write the new data byte to display memory
setData(addr, data);
}

я попробовал нарисовать на экране пиксель, но он вроде как нарисовался но разместился не в тех координатах, которые я указывал.Как я понимаю, за размещение отвечает строка
//GLCD_GRAPHICS_ADDR- нач. адрес- 1200, GLCD_WIDTH- кол во символов в строке- 320
addr = GLCD_GRAPHICS_ADDR + (GLCD_WIDTH/8 * y + x/8);
Может кто из вас раскомментирует эту странную формулу и подправит её, если она неправильная.

Сообщение отредактировал andreichk - Jan 25 2008, 21:03

[andreichk]

на АЦП подаётся фиксированная частота оцифровки 80 МГц. С него 8бит идут на ФИФО, кот. в свою очередь тактируется частотой от 80 МГц до 625 кГц,посредством запрограммированной ПЛИСки, то есть это и есть переключатель развёртки и соответственно показания от 0.4 мкс до 51.2 мкс(за что мы с вами не так давно бились) оба канала имеют независимый переключатель, то есть одновременно можно наблюдать и 20 кГц и 2 МГц. На последнем фото импульсы подаются на нижний канал(0.4 мкс) .Но нормальный их вид как вы правильно заметили , это 1 период на весь экран.А тут вдруг такая мелкота и не пойму -откуда она берётся и почему потом пропадает? Причём частота оцифровки никоим образом не менялась(ну разве только какая-нить гармоника пролазит) такое вообще возможно?
На всякий случай вот тут схема.Кстати, что теперь будем делать с EEPROM? С картинками , как я понимаю, вопрос закрыт

[Ilya_A]

А тут вдруг такая мелкота и не пойму -откуда она берётся и почему потом пропадает?

А раньше (до изменения программы) такое случалось?

Просто я сомтрю у вас FIFO буферы то всего по 512 байт. (я думал несколько Кб). Следовательно скорость считывания при отрисовке должна быть не меньше чем 1/2 от скорости заполнения данными АЦП.
Если она будет меньше, то на высоких частотах оцифровки возможна отрисовка неправильной картины (из-за перезаписи правильных значений новыми данными)

Чтобы этого избежать придется переписать процедуру curve_A() следующим образом:

Код

unsigned int8 Buf[256];
//--------------- собственно кривая ---------------------------
void curve_A(unsigned int8 y_pos_A){
   unsigned int8 x, y , yy;
   for(x=0;x<254;x++){
      Output_bit(READ_FIFO_A ,0); //PIN_C2. разрешить
      Buf[x]=input_b(); //чтение порта В
      Output_bit(READ_FIFO_A ,1); //PIN_C2.запретить
   }
   for(x=1;x<255;x++){
      yy = y;
      adcA = (Buf(x-1) > 200) ? 200 : Buf(x-1); //ограничитель до выбранной величины
      y = (255 - adcA) + y_pos_A; // разворот на 180° по вертикали и сдвиг
      if (yy>y) front(x,yy,y); // Рисуем фронт A
      if (yy<y) spad(x,yy,y); // Рисуем спад A
      pixel(x,y,1); // Рисуем вершину A
   }
}

Может быть это поможет....

Кстати, что теперь будем делать с EEPROM? С картинками , как я понимаю, вопрос закрыт

Кстати на счет EEPROM: не вижу подтягивающих резисторов на линиях SCL, SDA

[andreichk]

А раньше (до изменения программы) такое случалось?

я думаю,что да, просто я не обращал внимания


adcA = (Buf(x-1) > 200) ? 200 : Buf(x-1); //ограничитель до выбранной величины
тут очепятка ? должно быть так-Buf[х-1]

Может быть это поможет....

пока не понятно, но мне кажется , что ничего не изменилось

Кстати на счет EEPROM: не вижу подтягивающих резисторов на линиях SCL, SDA

Упс, забыл нарисовать, на самом деле они есть и даже припаяны

Просто я сомтрю у вас FIFO буферы то всего по 512 байт. (я думал несколько Кб). Следовательно скорость считывания при отрисовке должна быть не меньше чем 1/2 от скорости заполнения данными АЦП.
Если она будет меньше, то на высоких частотах оцифровки возможна отрисовка неправильной картины (из-за перезаписи правильных значений новыми данными)

тут мне не понятно- скорость считывания ФИФО устанавливает ПИК и она постоянная и всегда меньше
частоты АЦП, как быть?

кстати насчёт ФИФО, имеет ли смысл применить более ёмкую, напр.IDT7204 или даже IDT7205?

а может у меня вот это имеет место быть?

Сообщение отредактировал andreichk - Mar 29 2008, 08:30

[Ilya_A]

adcA = (Buf(x-1) > 200) ? 200 : Buf(x-1); //ограничитель до выбранной величины
тут очепятка ? должно быть так-Buf[х-1]

Естественно!

тут мне не понятно- скорость считывания ФИФО устанавливает ПИК и она постоянная и всегда меньше
частоты АЦП, как быть?
кстати насчёт ФИФО, имеет ли смысл применить более ёмкую, напр.IDT7204 или даже IDT7205?

Тут, помоему чем больше тем лучше. Ведь даже на 10 MIPS вы сможете обеспечить максимальную скорость считывания порядка единиц Мгц. А записывать данные вы можете до 80 Мгц!!!!

а может у меня вот это имеет место быть?

Чтобы это проверить, нужно замерить реальную скорость выгребания данных из FIFO буфера (можно по по количеству ассемблерных инструкций после компиляции программы) И сравнить со скоростью записи в буфер

[andreichk]

Чтобы это проверить, нужно замерить реальную скорость выгребания данных из FIFO буфера (можно по по количеству ассемблерных инструкций после компиляции программы) И сравнить со скоростью записи в буфер

Ок, а с какого места нужно начинать считать эти инструкции?

[Ilya_A]

Ок, а с какого места нужно начинать считать эти инструкции?

Незнаю, как в CCS, но в MPLABe это делается очень просто, открываем Dissasebly listing, находим строчку начала цикла:

Код

   for(x=0;x<254;x++){
      Output_bit(READ_FIFO_A ,0); //PIN_C2. разрешить
      Buf[x]=input_b(); //чтение порта В
      Output_bit(READ_FIFO_A ,1); //PIN_C2.запретить
   }

И считаем сколько команд ушло на этот цикл

Если в CCS такого нет, то может он хотябы отобразить текст откомпилированной программы? И если в нем возможна симуляция, то поставить BreakPoint на начало цикла, а затем посмотреть на какой строчке программа остановиться в асме. далее выполнять программу по шагам ассемблерных инструкций, пока не вернетесь снова на точку останова. Таким образом можно подсчитать количестов асм. инструкций.

Ну или в крайнем случае можно померять клоки осциллографом.

[andreichk]

есть такое дело

.................... //--------------- собственно кривая ---------------------------
.................... void curve_A(unsigned int8 y_pos_A){
.................... unsigned int8 x, y , yy;
.................... for(x=0;x<254;x++){
*
26E4: MOVLB 1
26E6: CLRF x6B
26E8: MOVF x6B,W
26EA: SUBLW FD
26EC: BNC 2710
.................... Output_bit(READ_FIFO_A ,0); //PIN_C2. разрешить
26EE: BCF F8B.2
26F0: BCF F94.2
.................... Buf[x]=input_b(); //чтение порта В
26F2: CLRF 03
26F4: MOVF x6B,W
26F6: ADDLW 55
26F8: MOVWF FE9
26FA: MOVLW 00
26FC: ADDWFC 03,W
26FE: MOVWF FEA
2700: MOVLW FF
2702: MOVWF F93
2704: MOVFF F81,FEF
.................... Output_bit(READ_FIFO_A ,1); //PIN_C2.запретить
2708: BSF F8B.2
270A: BCF F94.2
.................... }
270C: INCF x6B,F
270E: BRA 26E8
.................... for(x=1;x<255;x++){
2710: MOVLW 01
2712: MOVWF x6B
2714: INCFSZ x6B,W
2716: BRA 271A
2718: BRA 27AA
.................... yy = y;
271A: MOVFF 16C,16D
.................... adcA = (Buf[x-1] > 200) ? 200 : Buf[x-1]; //ограничитель до выбранной величины
271E: MOVLW 01
2720: SUBWF x6B,W
2722: CLRF 03
2724: ADDLW 55
2726: MOVWF FE9
2728: MOVLW 00
272A: ADDWFC 03,W
272C: MOVWF FEA
272E: MOVF FEF,W
2730: SUBLW C8
2732: BC 2738
2734: MOVLW C8
2736: BRA 274A
2738: MOVLW 01
273A: SUBWF x6B,W
273C: CLRF 03
273E: ADDLW 55
2740: MOVWF FE9
2742: MOVLW 00
2744: ADDWFC 03,W
2746: MOVWF FEA
2748: MOVF FEF,W
274A: MOVWF x54
.................... y = (255 - adcA) + y_pos_A; // разворот на 180° по вертикали и сдвиг
274C: MOVLW FF
274E: BSF FD8.0
2750: SUBFWB x54,W
2752: ADDWF x6A,W
2754: MOVWF x6C
.................... adcA = y;
2756: MOVFF 16C,154
.................... if (yy>y) front(x,yy,y); // Рисуем фронт A
275A: MOVF x6D,W
275C: SUBWF x6C,W
275E: BC 2774
2760: MOVFF 16B,16E
2764: MOVFF 16D,16F
2768: MOVFF 16C,170
276C: MOVLB 0
276E: CALL 1DEC
2772: MOVLB 1
.................... if (yy<y) spad(x,yy,y); // Рисуем спад A
2774: MOVF x6C,W
2776: SUBWF x6D,W
2778: BC 278E
277A: MOVFF 16B,16E
277E: MOVFF 16D,16F
2782: MOVFF 16C,170
2786: MOVLB 0
2788: CALL 1E18
278C: MOVLB 1
.................... pixel(x,y,1); // Рисуем вершину A
278E: CLRF x8B
2790: MOVFF 16B,18A
2794: CLRF x8D
2796: MOVFF 16C,18C
279A: MOVLW 01
279C: MOVWF x8E
279E: MOVLB 0
27A0: CALL 0BE8
.................... }
27A4: MOVLB 1
27A6: INCF x6B,F
27A8: BRA 2714
.................... }
27AA: MOVLB 0
27AC: RETLW 00
....................
.................... //########################################

Сообщение отредактировал andreichk - Mar 30 2008, 11:04

[Ilya_A]

есть такое дело

Да, это в принципе оно и есть. только не видать конца цикла, приведите еще несколько инструкций, чтобы точнее определить полное количество тактов. Я предполагаю, что конец цикла по адресу 0x270F