Помогите начинающему с АЦП MCP3421

[KruBoHic]

а в железе, на макетке, что получается?

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

[jump]

а если модель... того... с душком-с, то бишь, глючком-с? куда плыть будете?

[DK]

А просто через printf нельзя вывести?

И у меня есть подозрение, что t,a,b,c,d,e,g,j должны иметь тип int32

[Yurkin2007]

Ну, шо я могу сказать:
1. Если задаёте конфигурацию АЦП = 0х90, то результат будет 12-битный и микросхема выдаст только 2 байта данных при чтении: resM и resL. Если "стоп" не послан, то при дальнейшем чтении будет выдаваться только байт конфигурации.
Далее, при такой конфигурации процедура АЦП преобразования будет зациклена до бесконечности с частотой 240 раз в секунду, то есть каждые 4мс будет готов новый результат, при этом каждый раз стартовать не надо, стартует автоматически.
Далее, в Вашем случае входной диапазон напряжений от 0В до +2.047В. Для нуля результат = 0х00, для 2.047В результат = 0х7FF. Если подать вх. напряжение 2.97В, то результат всё равно будет = 0x7FF.

2. Для АЦП преобразования нужно какое-то время, МСР3421 довольно таки медленный прибор. 240 преобразований в сек - это очень медленно.
В Вашей программе после записи конфигурации MСP3421 и начала преобразования АЦП, Вы сразу же читаете результат, который ещё не готов, преобразуете и отсылаете на терминал. В бесконечном цикле без всяких задержек. Я не знаю, с какой скоростью эмулируется процессор, но чую успеет программа раз сто прочитать и отослать одни нули, пока не будет готов первый реальный результат АЦП.
В байте конфигурации для опроса готовности есть отличный бит /RDY, который падает в 0 при готовности результата, и сам(!) прыгает в 1 после прочтения готовых данных из микросхемы. После этого сидит в единичке до следующей готовности данных. Вот его и надо проверять в бесконечном цикле. Если =0, то считывать 2 байта, преобразовывать, отсылать и снова переходить на проверку /RDY .

int Result;
unsigned char config;

i2c_start(); // начало процедуры I2C
i2c_write(0xD0); // запись адреса АЦП + запрос на запись
i2c_write(0x90); // запись байта конфигурации: 12-бит,бесконечный цикл преобразований, 240 сэмплов в сек. + старт
i2c_stop(); // конец процедуры I2C   
     
while (1)
{        
  i2c_start(); // начало процедуры I2C  
  i2c_write(0xD1); // запись адреса АЦП + запрос на чтение
  i2c_read(1); // чтение среднего байта результата
  i2c_read(1); // чтение младшего байта результата
  config = i2c_read(1); // чтение байта конфигурации;

  while (config & 0x80) config = i2c_read(1); // чтение байта конфигурации до тех пор, пока результат АЦП не готов;

  i2c_stop(); // конец процедуры I2C

  i2c_start(); // начало процедуры I2C  
  i2c_write(0xD1); // запись адреса АЦП + запрос на чтение
  Result = i2c_read(1); // чтение среднего байта реального результата
  Result = (Result ‹‹ 8 ) + i2c_read(0); // чтение младшего байта реального результата
  i2c_stop(); // конец процедуры I2C

  printf("%d\n", Result);
}

PS. Если ещё немного почитать дейташит на МРС3421, то становится ясно, что результат АЦП представлен в two’s complement кодировке, и знаковый бит растянут до начала старшего байта. А это означает, что никакого побитного AND не надо делать со старшим байтом ...

[Halex07]

а если модель... того... с душком-с, то бишь, глючком-с?

"Наговариваете Вы на нашу семью..." - картинку смотрите.

В Вашей программе после записи конфигурации MСP3421 и начала преобразования АЦП, Вы сразу же читаете результат, который ещё не готов, преобразуете и отсылаете на терминал. В бесконечном цикле без всяких задержек.

Вот это верно!!! Так жить нельзя.

В байте конфигурации для опроса готовности есть отличный бит /RDY, который падает в 0 при готовности результата, и сам(!) прыгает в 1 после прочтения готовых данных из микросхемы. После этого сидит в единичке до следующей готовности данных. Вот его и надо проверять в бесконечном цикле.

А вот это при непрерывном цикле преобразования неэффективно. Тогда ему надо писать в конфиг не 0x90 - непрерывное преобразование, а 0x80 - единичное преобразование 12-ти битное, потом читать, пока не обнаружит 0 в старшем разряде конфиги, что означает - преобразование закончено и считанные в этом цикле данные достоверны. Иначе он рискует всегда получать из конфига 1 в старшем разряде и ждать достоверных данных до второго пришествия или обещанного индейцами апокалипсиса. Я нарочно включил вывод содержимого на терминал (картинка п).
Ну а топикстартеру еще и проектик во вложении.
ЗЫ Подумал, и добавил еще картинку 2 - все задержки закоментированы (убраны), а цикл в конфиг записал одиночный. Как видите, работает. Если б ТС сразу так сделал, то и этот топик нафиг не нужен был.

[Yurkin2007]

Я не понял, почему читается config=0x90 при непрерывном преобразовании. По заявлениям Микрочипа бит готовности падает в 0 при завершении преобразования и лежит в нуле, пока мастер I2C не прочитает данные. При непрерывном после окончания одного преобразования сразу же стартует следующее. Только не говорите мне, что /RDY=0 только в течении одной сотой микросекунды между преобразованиями
Вопрос остаётся открытым: как отловить момент готовности данных? Всё-таки вставлять в цикл "delay_ms(500);" как-то неспортивно ...

все задержки закоментированы (убраны), а цикл в конфиг записал одиночный. Как видите, работает.

Тут бит готовности работает, как надо ! Видимо между стартом АЦП и чтением конфига выполняется парочка процедур, типа sprintf(str_out1,...); puts(str_out1); и времени для завершения преобразования достаточно ...

[KruBoHic]

Ув. Halex07, скажите пожалуйста, почему при изминении конфигурации АЦП на 14-битный режим, значения байтов результата (HB, LB) отличаються от 12-битного, и как это можно исправить???
И как это повлияет на 16- и 18-битный режимы???

[Halex07]

Я не понял, почему читается config=0x90 при непрерывном преобразовании.

Ну, это действительно небольшой глючок модели в Протеусе. Посмотрел немного поподробнее, она при непрерывном преобразовании неадекватно реагирует на
config=i2c_read(1);
видимо авторы модели не учли повторного чтения конфигурации с наличием ACK и построили перезапуск преобразования именно при ACK=0 в этом цикле от мастера, поэтому и происходит подвисание, а при ACK=0 в этой команде читается 1 в старшем разряде конфига. В реальности, конечно, ваш код с while (config & 0x80) должен работать, если верить даташиту.

Всё-таки вставлять в цикл "delay_ms(500);" как-то неспортивно ...

Ну Вы уж палку не перегибайте, 500мс я тут вставил только чтоб строчки не так шустро летели в терминале, зрение берегу. Это ж так - тест на скорую руку. Но, согласитесь, что и гонять постоянно только одно АЦП, в программе тоже "неспортивно". У МК наверняка будет еще куча всякого обвеса, так что задержек и без делеев за глаза... Я вообще не сторонник бездумного применения Delay - это "деньги на ветер", так что они только для теста.

скажите пожалуйста, почему при изминении конфигурации АЦП на 14-битный режим, значения байтов результата (HB, LB) отличаються от 12-битного, и как это можно исправить???

"Ну, Вы блин, даете..." Чего там исправлять, Вы хоть в даташит заглядывали? Раздел 4.5 Digital Output Code на стр.8 - все есть и формулы и таблицы. 12-ти разрядный режим самый "тупой" младший бит раве 1мВ, даже пересчитывать ничего не надо, все само получается. При 14-ти битах код для того же напряжения на входе будет уже в 4 раза больше, а цена младшего бита 250мкВ. Соответственно надо менять в программе перевод в десятичный формат, да и маску для старшего байта result сдвигать влево, т.е. вместо 0x07 будет уже 0x1F, ну и т.д. А для 18-бит добавлять еще и дополнительный старший третий байт при чтении и брать из него по маске только два младших бита. Только не запаривайтесь с 18-битным режимом в CodeVision, че-то мне помнится там были большие проблемы с long в каких то версиях, да и редко нужно такое разрешение в 15мкВ - помех больше нацепляете.

[Yurkin2007]

500мс я тут вставил только чтоб строчки не так шустро летели в терминале, зрение берегу. Это ж так - тест на скорую руку. ... Я вообще не сторонник бездумного применения Delay - это "деньги на ветер", так что они только для теста.

Я так и подумал. Полностью согласен с Вами.

маску для старшего байта result сдвигать влево, т.е. вместо 0x07 будет уже 0x1F,

Насколько я понял из даташита, выходной код АЦП - со знаком, и знаковый бит растянут до MSB старшего байта. Для положительных значений просто забиваются нулями неиспользуемые биты в старшем байте. Для отрицательных - забиваются единичками. Поэтому применение маски исказит отрицательные значения АЦП преобразования. Не надо маску, надо просто сложить байты со сдвигом ...