[TamTam 0]

Ну написал с горем пополам обработку прирывания по окончанию приема байта, процедурку копирования из буфера в eeprom, но вот вопрос ???

 

Данные приходят всегда по разному иногда в нужной мне строке символ 0х0d и 0х0а встречаються несколько раз значит обработка пришедших данныш по окончанию строки мне не подходит, думаю так

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

 

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

[TamTam 0]

не очень понял ваше изложение.

 

Может вам просто буфер создать и спокойно обрабатывать данные когда МК "свооден" ? Буфер нужного размера вам автоматически нарисует CVAVR и пример есть в задаче 5 запрещенного курса.

 

я конечно наченающий но немного соображаю,

 

Буфер у меня 32 байта а информации иной раз и все 200 приходит, поэтому в обработке прерывания по приему байта я делаю так

 

interrupt [UART_RXC] void uart_rx_isr(void)
{
char status,data;
int i=2;
status=USR;
data=UDR;
if (data != 0x0A)
   {
      if (data != 0x0d)
         {
            if ((status & (FRAMING_ERROR | DATA_OVERRUN))==0)
               {
                  rx_buffer[rx_wr_index]=data;
                  if (++rx_wr_index == RX_BUFFER_SIZE) rx_wr_index=0;
                  if (++rx_counter == RX_BUFFER_SIZE)
                     {
                        rx_counter=0;
                        rx_buffer_overflow=1;
                     };
               };
         }
   }      
   else;
   {
      while(rx_counter != 0x00)
      {
      i++;
      fraza[i]==ReceiveByte();
      }
   }
}

 

где fraza переменная в еепроме, но из затого что размер полезных данных может меняться от 4 до 190 байт мне както нужно организовать обработку этих данных, когда начать ??? данные могут идти с разной интенсивностью.

[rat 0]

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

[TamTam 0]

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

 

к сожалению не я.

 

Щас наверно более опытные товарищи подскажут, но я б сделал буфер на 200 символов во-первых.

 

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

на 200 не могу поскольку 2313 столько не имеет.

[haker_fox 61]

Может быть эта ссылка Вам поможет?

[TamTam 0]

Может быть эта ссылка Вам поможет?

 

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

[beer_warrior 0]

Идея правильная, вот пример кода который кочует из проекта в проект:

 

struct {
        volatile    BYTE    mode;
        volatile    WORD  timeout;
        volatile    BYTE    errc;
        
        volatile    WORD    tx_cnt;
        volatile    WORD    tx_len;
        BYTE*               tx_buf;
        
        volatile    WORD    rx_cnt;
        volatile    WORD    rx_len;
        BYTE*                   rx_buf;
        } UCB; //UART control block

SIGNAL(SIG_UART_RECV)
{
//wdt_reset();
SET_RX_BUSY;

UCB.timeout = 0;
UCB.rx_buf[UCB.rx_cnt] = UDR;

if(hRxProc) hRxProc();

UCB.rx_cnt++;

if(UCB.rx_cnt >= UCB.rx_len)
    {
    CLR_RX_BUSY;
    if(hRxEnd) hRxEnd();    
    UCB.rx_cnt = 0;
    }
}

 

Здесь:

SET_RX_BUSY - установка флажка занятости UART (пакет в процессе приема)

hRxProc() вызов функции для анализа пришедшего байта проинициализиоравна как NULL

hRxEnd() вызов функции обработки заполненного буфера.

BYTE* tx_buf,rx_buf указатели на объявленные глобально буфера.

 

Теперь самое интересное- UCB.timeout. Один из таймеров умеющий работать в режиме CTC,

настроен на генерацию миллисекунд, в его прерывании ин(де)крементируются счетчики задержек,

счетчики секунд и UCB.timeout который проверяеться либо в основном контексте либо в hRxProc(),

смотря по протоколу.

 

И последнее не надо складывать данные сразу в EEPPROM - он не вечен.

[WHILE 0]

Судя по 0A,0D-это модем.Действительн,в eeprom зачем постоянно складывать-рано илипоздно откажет.

А если нужно энергозависимое с большим обьемом-можно 537ру10 с развязкой по питанию и cs на диодах,а в качесте резервного источника можно конденсатор или аккумулятор-потребление минимально и количество циклов записи неограниченно.

kertisДостал,зараза :(

[vet 0]

Ну написал с горем пополам обработку прирывания по окончанию приема байта, процедурку копирования из буфера в eeprom

 

В курсе, что ресурс EEPROM AVR - 100 тыс. записей?

 

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

 

Трех стандартных AVR таймеров вполне хватит для чего угодно.

[Nanobyte 0]

Лучше применять не RAM со всеми его недостатками, а FRAM от Ramtron. Они теперь и с параллельным интерфейсом есть. При 3.3в питания число перезаписей неограничено (у них так написано в DS).

[WHILE 0]

а почем нынче fram ?

[beer_warrior 0]

Насколько я понял человек пишет во внутреннюю EEPROM, так-что FRAM в данном случае отдыхает. Я так понял речь идет о записии каких-то параметров или лога, 100 000 циклов за глаза хватит.Поэтому просто надо убедится, что да, данные заехали правильные, в полном объеме, а потом сбрасывать в EEPROM.

И еще один нюанс - писать, что во внешнюю, что во внутреннюю память надо вне прерывания - это же время.

Вот так вот выходит боком пресловутый "курс".

[otrog 0]

а почем нынче fram ?

Пару месяцев назад FM24CL64-S мне привезли по 81.81р.

вообщем:

http://www.efind.ru/icsearch/?search=FM24

[defunct 0]

Да курс то причем тут ?

 

в запрещенном курсе на стр 03.htm ясно написано

...

На пачках сигарет тоже пишут "курение опасно для здоровья". Много вы встретили курильщиков, которые бросили курить из-за этой надписи?

[TamTam 0]

Судя по 0A,0D-это модем.Действительн,в eeprom зачем постоянно складывать-рано илипоздно откажет.

А если нужно энергозависимое с большим обьемом-можно 537ру10 с развязкой по питанию и cs на диодах,а в качесте резервного источника можно конденсатор или аккумулятор-потребление минимально и количество циклов записи неограниченно.

kertisДостал,зараза :(

 

Да имено модем. Почему именно eeprom ??? да только лиш по тому что ситуация при котором может что то появиться крайне редко может возникнуть, да и лучшебы ей вовсе не возникать, а то люди потеряют баксы, а баксы это для людей святое :-))))