Помогите советом. I2C, Мож кто сталкивался. Опции

[SasaVitebsk]

У меня есть в устр-ве шина I2C. На ней сидит мастер - atmega640(I2C софтовый) пару микрух памяти 24с512 и atmega48(I2C аппаратный слэйв). Всё это подпёрто резисторами 3.9кОм. Общая протяжённость шины составляет ~30см.

Изначально работал побайтно с 24с512 и блоком с mega48. Всё работало суперустойчиво. Сутками. Ни единого сбоя. С какого-то момента я попытался значительно повысить скорость на чтение (а заодно на запись) с 24с512. Для этого я ввёл буфер на 32 байта и начал писать/читать блоками по 32 байта. В принципе всё работает, но периодически возникают сбои. Я выяснил. Сбои возникают как при чтении, так и при записи. Их характер - случайный и хаотический. Создаётся ощущение, что сбои - результат помех. Увеличение задержек - не дало результата.

Может кто сталкивался с чем-нибудь подобным и может подсказать? Пока не знаю куда рыть.

[mrcashe]

Подскажите спецы кто как работает в Си. Можно работать с массивами и указателями. Что эффективней?

Я стараюсь работать только с указателями. При программировании для МК это несколько экономит ресурсы. Допустим, есть некая структура:

Код

typedef struct { int id; void * p; } some_struct_t;

и есть некая константа, задающая размер буфера (читай: массива):

Код

enum { some_buffer_size = 20 };

Разместим сам буфер:

Код

some_struct_t some_buffer[some_buffer_size];

Теперь вариант перебора с применением индекса:

Код

int i;
for (i = 0; i < some_buffer_size; ++i) {
        printf("%i %p\n", some_buffer[i].id, some_buffer[i].p);
}

Перебор с применением указателя:

Код

some_struct_t * p;
for (p = some_buffer; p < some_buffer+some_buffer_size; ++p) {
        printf("%i %p\n", p->id, p->p);
}

Как видим, в первом случае индексирование выполняется дважды за цикл, т.е. всего 40 раз! А что есть индексирование? Это умножение(!) индекса на размер элемента массива и суммирование его с указателем на массив. Конечно, в случае массива символов размер элемента массива == 1, так что можно просто прибавлять индекс к адресу массива, но в случае массивов с размером элементов в 5 байт придётся именно умножать.
Во втором же случае размер элемента массива просто прибавляется к текущему значению указателя, что может быть на порядок (а то и 2 порядка) эффективнее.
С другой стороны, если не требуется итерация по всему буферу, а нужен именно произвольный доступ к элементу с определённым индексом, то можно с одинаковым успехом воспользоваться обоими методами, как и показал sensor_ua.

Массив имеет длину и её можно узнать.

Это что-то новое. Размер массива в Си, вообще говоря, невозможно узнать динамически. Соответственно, код, сгенерированный компилятором, не имеет возможности детектировать выход за пределы массива. Если Вы имеете ввиду sizeof() , то он возвращает размер объекта в байтах, что обычно не то, что нужно в повседневной жизни. Более того, полагаться на этот оператор просто опасно. В различных компиляторах он может выдавать различные значения благодаря различному выравниванию элементов. Если массив размещается статически, то всегда заводите константу, содержащую его размер и пользуйтесь только ею для задания и определения размера массива. Если массив размещается динамически, то определите переменную (а ещё лучше - функцию) для определения его размера. Для изменения размера определите соотвествующую функцию.

[defunct]

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

Как уже отметил sensor_ua, не надо заводить никаких констант.
Гораздо безопаснее применять макрос
#define COUNT( arr ) ( sizeof( arr ) / sizeof( (arr)[0] ) )

Как видим, в первом случае индексирование выполняется дважды за цикл, т.е. всего 40 раз!

для процессоров таких как AVR, компилятор соптимизирует операции индексирования. (добавит неявный указатель на структуру)

Для процессоров с индексной адресацией, абсолютно не важно сколько раз происходит индексирование:

MOV eax, [ebx + esi * x + offset]

[zltigo]

Для процессоров с индексной адресацией, абсолютно не важно сколько раз происходит индексирование:
MOV eax, [ebx + esi * x + offset]

Справедливости ради x может быть только степеню двойки , ну и такты кушает такая адресация.
Ну а с оптимизацией, действительно дело обстоит в большинстве случаев действительно хорошо.