CodeVision AVR в вопросах и ответах

[rxstart1]

Я полностью забил на тип переменных, я не записываю в eeprom. Просто выполняю чтение (оно быстрое)
И опять в протеусе работает на железяки нет!!!


unsigned char EEPROM_read(unsigned int uiAddress)
{
while(EECR & (1<<EEWE)); // Жду пока закончится последняя запись
EEAR = uiAddress; // Устанавливаю адрес
EECR |= (1<<EERE); // Запуск чтения из регистра EERE
return EEDR;
}


.........

while (1)
{
if (EEPROM_read(0)==0xFF) {PORTD.0=1;PORTD.6=1;}
}
В программаторе я могу записать значение и считать его. Порты работают проверил. В чем может быть косяк?

[RusikOk]

А есть какой нибудь способ программно определить на каком контроллера выполняется программа?
И какой объем eeprom доступен?

[rxstart1]

Спасибо нашел косяк, дело было в настройках регистра прерываний, сейчас все ОК.

[Сериг]

Всем привет! Пытаюсь победить oled 0.96 по spi. Контроллер ssd1306. Скоммуниздил шрифты, чтобы самому не рисовать. Проблема: При выводе через функцию LCD_Printf, на дисплее выписывается только последняя цифра (буква). Если писать через функцию LCD_Char посимвольно, то все работает. Кому не сложно, гляньте пожалуйста, несколько дней побороть не могу.
SSD_SPI - функции;
PC - main;
fonts - шрифты и картинки.
Спасибо!

Вложения

fonts.c

(31.69 KiB) Скачиваний: 438

PC.c

(3.25 KiB) Скачиваний: 456

SSD_SPI.c

(10.11 KiB) Скачиваний: 492

[WiseLord]

В код не заглядывал, но первый вопрос - позиция по X после вывода буквы меняется?

[Сериг]

Да, позиция прибавляется по иксу.

[*Trigger*]

Почему размер buff[] не указан?

Код:

char buff[];  //буфер дисплея

Компилятор не знает, сколько байт в RAM выделить под этот массив, и, в итоге, sprintf может записать мусор в какую-нибудь переменную в RAM недалеко от этого "массива". Это может вызвать самые неожиданные глюки.

[Сериг]

Почему размер buff[] не указан?

Код:

char buff[];  //буфер дисплея

Компилятор не знает, сколько байт в RAM выделить под этот массив, и, в итоге, sprintf может записать мусор в какую-нибудь переменную в RAM недалеко от этого "массива". Это может вызвать самые неожиданные глюки.

Определил его размерность в 40, это ситуацию не поправило.
вывожу инфу:

Код:

LCD_Goto(0,0);
       sprintf(buff,"ПРИВЕТ");
       LCD_Printf(buff,0);
       
       LCD_Goto(0,3);
        sprintf(buff,"ПРИВЕТ");
       LCD_Printf(buff,1);

На экране получаю:
т

Т
Т.е. опять же только последний символ. Голову уже сломал, явно sprintfу что-то не нравится

[*Trigger*]

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

Код:

SSD_command(0x00);  //пробел в одну точку между символами

sprintf() тут, я думаю, не при чём, можно для проверки и так написать:

Код:

LCD_Goto(0,0);
LCD_Printf("ПРИВЕТ",0);

Последний раз редактировалось *Trigger* Вт июн 19, 2018 23:45:16, всего редактировалось 1 раз.

[Сериг]

Ай да *Trigger*, Ай да красавчик, спасибо огромное это и правда данные.
P.S. Пойду карму поправлю тебе в плюс, да и посты пролайкаю

[*Trigger*]

Да не за что, я тоже следую правилу из твоей подписи.

На всякий случай рекомендую почитать где-нибудь про структуру программы на Си, про *.c и *.h файлы, чтобы не возникало больше желания #include'ить первые из них. Это к обсуждаемой проблеме не относится, но лучше делать как принято.

Последний раз редактировалось *Trigger* Вт июн 19, 2018 23:51:47, всего редактировалось 1 раз.

[Сериг]

Спасибо, почитаемс!
Но так вроде удобно, собираешь все, что нужно и в путь.

[elektro.kot]

CVAVR выдает три файла: *.eep , *.hex , *.rom .
В программе для прошивки только два пункта: Write Flash и Write EEprom.
С *.eep более-менее понятно, это Write EEprom.
Как шить *.rom?
Или это то же, что и *.hex, только в другом формате?
И в какой последовательности шить *.eep , *.hex , *.rom ?

[Сериг]

Мужики, снова я! Ломаю WS2812B, не поддается приручению! Прошу глянуть код, с таймингами похоже косячу, тактовая частота 8 мгц.

Код:

#define DIN_out DDRD.2
#define DIN PORTD.2


unsigned char i;

void CLEAR_ALL (void){
DIN_out = 1;
DIN = 1;
DIN = 0;
delay_us(60);
DIN = 1;
}


void SET_COLOR_1_LED (unsigned char R,unsigned char G, unsigned char B){
unsigned char i;
int z;
DIN_out = 1;
    DIN = 0;
    for (i=0;i<8;i++) {
    if (B & 0x80) { DIN = 1; for(z=0; z<6; z++){#asm("nop")} DIN = 0; for(z=0; z<4; z++){#asm("nop")}  }
    else {DIN = 1; for(z=0; z<3; z++){#asm("nop")} DIN = 0; for(z=0; z<7; z++){#asm("nop")}}
    B<<=1;   
    }
    for (i=0;i<8;i++) {
    if (B & 0x80) { DIN = 1; for(z=0; z<6; z++){#asm("nop")} DIN = 0; for(z=0; z<4; z++){#asm("nop")}  }
    else {DIN = 1; for(z=0; z<3; z++){#asm("nop")} DIN = 0; for(z=0; z<7; z++){#asm("nop")}}
    R<<=1;   
    }
    for (i=0;i<8;i++) {
    if (B & 0x80) { DIN = 1; for(z=0; z<6; z++){#asm("nop")} DIN = 0; for(z=0; z<4; z++){#asm("nop")}  }
    else {DIN = 1; for(z=0; z<3; z++){#asm("nop")} DIN = 0; for(z=0; z<7; z++){#asm("nop")}}
    G<<=1;   
    }
    DIN = 0; delay_us(120);
}
 

в мэйне:

Код:

CLEAR_ALL();
      delay_ms(1000);
      SET_COLOR_1_LED(1,1,0);
      delay_ms(1000);
      SET_COLOR_1_LED(0,1,1);
      delay_ms(1000);     
      SET_COLOR_1_LED(1,0,1);
      delay_ms(1000);

В цепи три диода, загораются только два, на 100% и белым...
Задержки высчитывал исходя из одного тактового импульса (125 наносек).
Благодарю!
P.S. ссылка на датащи http://www.seeedstudio.com/document/pdf ... asheet.pdf

[*Trigger*]

Открой файл *.asm после компиляции и посмотри, во что разворачивается, например, это:

Код:

for(z=0; z<6; z++){#asm("nop")}

Ты увидишь, что этот кусок исполняется куда дольше 6 тактов, т.к. есть ещё проверка условия, инкремент, условный переход. В этом случае правильно будет написать 6 nop'ов подряд, без цикла.

Код:

#asm("nop")
#asm("nop")
#asm("nop")
#asm("nop")
#asm("nop")
#asm("nop")

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

В этой статье есть исходники, но там всё полностью на ASM'е.

[ARV]

вообще-то, для WS2812B вряд ли можно придумать что-то лучше, чем управление через аппаратный SPI.

Код:

#if (F_CPU < 16000000UL) || !defined(F_CPU)
#error "F_CPU must be defined and must be greather or equal 16MHz"
#endif

/// Константа для формирования импульса "0" для WS2812
#define WS_BIT_0   0xE0
/// Константа для формирования импульса "1" для WS2812
#define WS_BIT_1   0xF8

/** Побитовая выдача 1 байта данных в WS2812
 *
 * @param byte выводимый байт
 */
__inline static void send_byte(uint8_t byte){
   for(uint8_t mask=0x80; mask; mask >>=1){
      SPDR = byte & mask ? WS_BIT_1 : WS_BIT_0;
      while(bit_is_clear(SPSR, SPIF));
   }
}

/** Обновление содержимого цепочки светодиодов WS2812
 *
 */
void ws2812_show(void){
   for(uint8_t i=0; i<PIXEL_CNT; i++){
         // для чипа WS2812 порядок цветовых составляющих должен быть таким:
         send_byte(pixels[i].g);   // сначала ЗЕЛЕНЫЙ
         send_byte(pixels[i].r);   // затем КРАСНЫЙ
         send_byte(pixels[i].b);   // в конце - СИНИЙ
   }
}

/** Инициализация аппаратного SPI
 *
 */
INIT(7){
   DDR(PORT_SPI) |= _BV(PIN_MOSI) | _BV(PIN_SS) | _BV(PIN_SCK);

   SPCR = _BV(SPE) | _BV(MSTR) | _BV(CPHA);//fosc/2 16MHz/2
   SPSR = _BV(SPI2X);
   SPSR; SPDR;
}


используется только линия MOSI

[Сериг]

Trigger спасибо, вечером опробую.
ARV да не хочется использовать для таких целей spi, слишком много ресурсов требуется... Хотел сколотить минимальную функцию, которая позволила бы работать с этими диодами.
Опробовал нупы, что-то сдвинулось, однако все равно не работает корректно. Пробовал уменьшить количество нупов - бестолку

[Сериг]

Я уже думаю микроконтроллер переводить на 16 МГц, но это, похоже, не факт, что исправит ситуацию. Уже и так и сяк пробовал уменьшать задержки. Есть мысль написать все в тупую, просто подряд отправку 8 бит для каждого цвета, без цикла сдвига на один...

[ARV]

не хочется использовать для таких целей spi

ну и зря

[OKF]

Конечно зря. Как раз таки при SPI используется минимум ресурсов контроллера. Вообще, если возможно аппаратное решение, на кой использовать программное!