Считать лог. Опции

[Jenya7]

я логирую данные во внешнюю память.
размерность памяти 8 бит. каждая запись 16 бит то есть каждая запись берет 2 байта. текущий адрес записи я храню в глобальной переменной - param1.logNum.
и тут я задумался над оптимальным алгоритмом - считать последних n записей. причем мне эти записи надо послать пакетами по 18 байт каждый пакет.
Кое что я набросал.

Код

void BLUENRG_SendLog(void)  //send n deltas from the last
{

    uint32_t chank = 18;  //DELTA_SIZE * AVAILABLE_BUF_SIZE;
    uint32_t last_log_addr = param1.logNum * DELTA_SIZE;
    uint32_t packet_size;
    uint32_t tx_num=0;
    uint32_t current_addr = last_log_addr - (chank * tx_num);

    //check if the overflow occurred
    while (current_addr > START_LOG_ADRESS)
    {
               packet_size = chank;

               uint8_t buf[packet_size];

               LOGGER_Readlog(current_addr, packet_size, buf);

        SendBuf(buf);

        tx_num++;
        
        current_addr = last_log_addr - (chank * tx_num);

        
    }
    // send the rest of data ???

}

Но мне это не нравиться. Может лучше отсчитать и начать с младшего адреса? Проще и не надо проверять ушел ли я за границы начального адреса.

Сообщение отредактировал Jenya7 - Oct 19 2015, 07:24

[CrimsonPig]

я логирую данные во внешнюю память.
размерность памяти 8 бит. каждая запись 16 бит то есть каждая запись берет 2 байта. текущий адрес записи я храню в глобальной переменной - param1.logNum.
и тут я задумался над оптимальным алгоритмом - считать последних n записей. причем мне эти записи надо послать пакетами по 18 байт каждый пакет.
Но мне это не нравиться. Может лучше отсчитать и начать с младшего адреса? Проще и не надо проверять ушел ли я за границы начального адреса.

Не проще ли хранить ваши записи лога в кольцевом буфере (ring buffer), и выбирать из него данные по мере необходимости ?

[Jenya7]

Не проще ли хранить ваши записи лога в кольцевом буфере (ring buffer), и выбирать из него данные по мере необходимости ?

в принципе это и есть большой кольцевой буфер. но данные все равно надо выбрать. скажем я хочу посмотреть последние 100 записей.

[CrimsonPig]

в принципе это и есть большой кольцевой буфер. но данные все равно надо выбрать. скажем я хочу посмотреть последние 100 записей.

Ну так прочитайте их с головы кольцевого буфера, а не с хвоста
Делаем копию указателя (или индекса, зависит от имплементации) записи, уменьшаем его на нужное кол-во записей (по модулю размера буфера + отслеживание пересечения границы чтения) и читаем с инкрементом. Атомарность, проверки на переполнение\опустошение и прочие невнятные мелочи опускаем для простоты

[esaulenka]

Делаем копию указателя (или индекса, зависит от имплементации) записи, уменьшаем его на нужное кол-во записей (по модулю размера буфера + отслеживание пересечения границы чтения) и читаем с инкрементом. Атомарность, проверки на переполнение\опустошение и прочие невнятные мелочи опускаем для простоты

Если почитать-таки код в первом сообщении, там именно это и делается.
"Для простоты" там, правда, нет указания, сколько же данных у нас запросили.
И ещё, там нет кольцевого буфера (запись не вижу, а на чтение - точно нету!). Зато есть как минимум пара лишних переменных (чтоб никто не догадался).
И очень удобный формат, в котором они возвращаются - полностью всё перепутано.

Я б ТЗ стряс для начала. Сколько записей, сколько хранить, сколько считывать (считывать только так, или это только один из интерфейсов), ...
А то опять угадайка "что хотел сказать автор" с нерабочим кодом...

[CrimsonPig]

Я б ТЗ стряс для начала. Сколько записей, сколько хранить, сколько считывать (считывать только так, или это только один из интерфейсов), ...
А то опять угадайка "что хотел сказать автор" с нерабочим кодом...

Мне зачастую проще намекнуть, как надо было бы сделать по-хорошему (естественно, с моей точки зрения), чем разбираться в обрывках чужого кода и строить догадки по поводу того, что хотел автор..
Пусть делает, как хочет