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

Программирование ATMEL в BASCOM.

Информация о пользователе

Привет, Гость! Войдите или зарегистрируйтесь.



INA226

Сообщений 1 страница 23 из 23

1

Добрый день.
У кого есть наработки по INA226?

0

2

дык, а что там изучать? I2С и даташит в руки...
https://www.radiokot.ru/artfiles/6422/

+1

3

Ну примерно понятно.

Что делать с отрицательным током?

Dim INA226_low_byte As Byte
Dim INA226_high_byte As Byte
Dim переменная_word As Word
Dim ток As Single

      I2cstart
      I2cwbyte  Adress_INA226_w
      I2cwbyte  &H01
      I2crepstart
      I2cwbyte Adress_INA226_r
      I2crbyte INA226_high_byte , Ack       '
      I2crbyte INA226_low_byte , Nack       '
      I2cstop       '
      переменная_word = Makeint(INA226_low_byte , INA226_high_byte)
      ток = переменная_word * 0.0001

      Lcdat 5 , 10 , Fusing(ток , "#.##")

Отредактировано Menen (2020-05-18 14:33:07)

0

4

Когда то возился, Ссылка

+1

5

Спасибо! Хорошо сделано. Отрицательные значения тока не считает...

Отредактировано Menen (2020-05-18 19:17:04)

0

6

там нет понятия отрицательного тока, обычно присутствует центральная точка в значениях

0

7

Коллеги, выполнение функций считывания трёх параметров с ИНА226 из примера от Yuriy.pv занимает 304 мс при тактировании 328р кварцем 16 МГц. Это нормально?

0

8

.

Salmon написал(а):

//

Сделайте на АСМ будет быстрее.

0

9

Yuriy.pv, я без претензий к Вам. Наоборот, Ваш труд сэкономил моё время, спасибо!
Сел, прикинул. Может, и будет быстрее, конечно... Но делается 64 выборки, 1,1 мс на каждую - это уже более 70 мс на функцию. Плюс время передачи данных по I2c, хоть и небольшое. Ускорять особо нечего...
Тут вот какая проблема у меня (не знаю, может и оффтоп):
Основной цикл:
1: Отправляем ресет на датчики (2) 18В20 по 1wire;
2, 3, 4: Опрашиваем ИНА (трижды: В, А, Вт) по I2c;
5 Если изменилось значение счётчика энкодера, отправляем его на ЦАП МСР4725 по I2c;
6, 7: считываем температуры с 18В20 по 1wire;
8: отображаем полученное на LCD, подключенном через адаптер PCF8574 по I2c.
Кроме основного цикла, есть обработчик прерывания INT0: на INT0 сидит один из двух каналов энкодера. В обработчике проверяется состояние второго канала, изменяется значение счётчика и устанавливается флаг - всё максимально коротко:

Enc_int:
   Select Case Encb
      Case 0 : Dac_val = Dac_val - 1
      Case 1 : Dac_val = Dac_val + 1
      Case Else : Return
   End Select
   Set Chng_flg
Return

При использовании адаптера PCF8574, при повороте энкодера иногда показания 18В20 и ИНА226 становятся неадекватными, а восстанавливают нормальные значения на следующем цикле. Сперва решил, что обработка прерывания крашит обмен по 1wire и I2c. Датчики прошил на 9-бит режим, чтобы требовалось меньше времени на преобразование (около 100 мс).
Но прикол в том, что если LCD подключен проводами, то всё работает стабильно.
Куда копать - пока не понимаю. Есть идеи у кого-то из коллег?

Отредактировано Salmon (2021-09-01 19:32:49)

0

10

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

0

11

Вставлю свои 5 копеек ...

Case Else : Return

Вроде, вот здесь некорректно.  Выход по Return из незаконченного  Select Case.
Можно в  Case Else поставить флажок.
Нормально закончить Select по End Select, а потом обойти  Set Chng_flg.

0

12

Salmon написал(а):

При использовании адаптера PCF8574, при повороте энкодера иногда показания 18В20 и ИНА226 становятся неадекватными, а восстанавливают нормальные значения на следующем цикле. Сперва решил, что обработка прерывания крашит обмен по 1wire и I2c.

Вы же сами разрываете алгоритм работы 1W устройств (выделено стрелками):

Salmon написал(а):

Основной цикл:
1: Отправляем ресет на датчики (2) 18В20 по 1wire;
=> 2, 3, 4: Опрашиваем ИНА (трижды: В, А, Вт) по I2c;
=> 5 Если изменилось значение счётчика энкодера, отправляем его на ЦАП МСР4725 по I2c;
6, 7: считываем температуры с 18В20 по 1wire;
8: отображаем полученное на LCD, подключенном через адаптер PCF8574 по I2c.

1W такого не любят...
Практически сразу за ресетом они ждут команды (точное время не изучал), а вы в это время начинаете делать что-то другое.
Просрочив это время, они (1W) снова переходят в режим ожидания уже следующего ресета.
Возможно, опрос ИНА еще прокатывает, а вот п.5 уже не всегда...

Посему предлагаю выполнять п.1 после п.5

Вдогонку:

Salmon написал(а):

отображаем полученное на LCD, подключенном через адаптер PCF8574 по I2c
...
Но прикол в том, что если LCD подключен проводами, то всё работает стабильно.

Есть уверенность, что нет конфликта между устройствами I2C ?
Точнее, вы не создаете его сами ?

Отредактировано Nord (2021-09-01 22:18:53)

0

13

Salmon написал(а):

Плюс время передачи данных по I2c, хоть и небольшое. Ускорять особо нечего

Ну как нечего?

1. Чип INA226 может работать по I2C до 2.94 MHz, судя из кода, он сейчас работает в районе 400КГц и следовательно скорость обмена с ним может быть в 7,35 быстрее.
2. В коде используется программная эмуляция I2C (софтовый режим, "slow mode is used") для общей совместимости со всеми AVR. Можно взять МК с аппаратным I2C и под него всё перенастроить (например серию XMega :D , чтобы и тактовую частоту за одно поднять).
3. Код весь написан на "Declare sub", прогать удобно, но вносит дополнительную трату ресурсов МК (стек, команды, память.., а это всё время затраченное на обработку данных).

Выше Вам ответили, что если что-то не устраивает, то лучше писать самому, под конкретную задачу (без этой всей универсальности).

0

14

Спасибо всем откликнувшимся за ответы новичку, коллеги! К сожалению, я не могу отвечать чаще, чем раз в 5 часов - такие тут правила.
Отвечаю "с хвоста к началу":

RDW написал(а):

Чип INA226 может работать по I2C до 2.94 MHz

Таки да, но вот PCF8574 (управляет LCD и висит на этой же шине) - 100 кГц. Изменять скорость шины по ходу выполнения программы?

RDW написал(а):

Можно взять МК с аппаратным I2C

Нельзя (в моём случае).

RDW написал(а):

Выше Вам ответили

Я прочёл, спасибо!

Nord написал(а):

Вы же сами разрываете алгоритм работы 1W устройств

Да. Это делать нужно в любом случае: после команды на начало конверсии, народ обычно тулит Waitms 750 - это, согласно даташит на DS18В20, "максимальное время преобразования" для 12-битного режима работы датчика. Чтобы сократить это время, до запуска основного цикла, я отправляю команду на переход датчиков в 9-ти битный режим, и максимальное время преобразования сокращается до 93,75 мс.

Nord написал(а):

Практически сразу за ресетом они ждут команды (точное время не изучал), а вы в это время начинаете делать что-то другое.

Я изучал, привёл эти тайминги выше. В течение этого времени, они не ждут команды, а выполняют конверсию измеренной тем-ры. И только после этого можно отправить команду на считывание результата конверсии. Что плохого в том, что вместо Waitms (пустого цикла) МК тратит время на считывание параметров из INA226?

Nord написал(а):

Просрочив это время, они (1W) снова переходят в режим ожидания уже следующего ресета.

Такого в даташите я не увидел. Ткните носом, пожалуйста?
Другое дело, что требования даташит к таймингам сигналов во время чтения/записи довольно жёсткие. Может, именно тут и возникают глюки, если МК, не завершив считывание с датчика, переходит на обработку прерывания? Тогда почему этих глюков нет, если LCD подключен без адаптера, проводами на порты МК?

Nord написал(а):

Есть уверенность, что нет конфликта между устройствами I2C ?
Точнее, вы не создаете его сами ?

У меня уже ни в чём нет уверенности...

pavel1969 написал(а):

Вроде, вот здесь некорректно.  Выход по Return из незаконченного  Select Case.

Это работает, проблем никогда не было. Спасибо за совет. Исправлю, но связи с глюками отображения не вижу.

Yuriy.pv написал(а):

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

Абсолютно нормально. Допаял к нему простейший ФНЧ (RC-цепи) для подавления дребезга. Осциллограммы каналов чистые. О проводах: я говорил о подключении LCD, а не энкодера. LCD я подключаю либо через адаптер I2C на PCF8574 - к шине I2C, либо шестью проводами к портам МК. В последнем случае, глюков не замечено; в том и вопрос: почему?
Взял, поставил такой "костыль":
Если изменилось значение счётчика энкодера, отправляем его на ЦАП МСР4725 по I2c (п. 5), и сразу идём на п. 8 (рефрешим показания на LCD, а датчики не читаем).
Так всё работает стабильно; но, ясное дело, температура обновляется только после того, как прекратилось вращение энкодера. Терпимо, но некрасиво:
Do
   Gosub Ds18b20_start

   Call Readbusvoltage_ina226(u_in)
   Call Readshuntcurrent_ina226(i_in)
   Call Readbuspower_ina226(p_in)

   If Chng_flg = 1 Then
      Gosub Send2mcp4725 : Goto M1 'Уродливый костыль
   End If
   
   Call Ds18b20_poll(dsid1() , S1 , T1)
   Call Ds18b20_poll(dsid2() , S2 , T2)
   M1:
           Gosub Lcd_refresh

Loop

0

15

Salmon написал(а):

Это делать нужно в любом случае: после команды на начало конверсии, народ обычно тулит Waitms 750 - это, согласно даташит на DS18В20, "максимальное время преобразования" для 12-битного режима работы датчика.

Ждать 750 необязательно, достаточно "слушать" шину. Будет ощутимо быстрее.
На форуме про это не раз говорили.

Salmon написал(а):

Я изучал, привёл эти тайминги выше. В течение этого времени, они не ждут команды, а выполняют конверсию измеренной тем-ры. И только после этого можно отправить команду на считывание результата конверсии. Что плохого в том, что вместо Waitms (пустого цикла) МК тратит время на считывание параметров из INA226?

Использование этой паузы для выполнения других задач решение хорошее, но если время не превысит время отклика устройств 1W.
А это время не обязательно будет 750 ms...

Salmon написал(а):

Такого в даташите я не увидел. Ткните носом, пожалуйста

Физически чипы не всегда точно выполняют требования даташита и не всегда в даташитах описаны все возможные курьезы... ;)
Обрыв диалога с 1W-устройствами на любом этапе ведет к переходу в режим ожидания стартового ресета, это выявлено практически (и мной в том числе).
Ковырялся с 1W достаточно плотно, полистайте форум.

Salmon написал(а):

Другое дело, что требования даташит к таймингам сигналов во время чтения/записи довольно жёсткие. Может, именно тут и возникают глюки, если МК, не завершив считывание с датчика, переходит на обработку прерывания? Тогда почему этих глюков нет, если LCD подключен без адаптера, проводами на порты МК?

Отключайте на это время прерывания.

Вы используете относительно медленную периферию и потаетесь достичь "световой" скорости реакции... ;)
Такого не бывает...

Подредактировал чуток, чтоб было нагляднее. ;)

Отредактировано Nord (2021-09-02 22:55:23)

0

16

Salmon, судя по описанию периферии, у вас что-то нагревательное или охладительное... ;)
При инерционности подобных устройств можно МК даже часовым кварцем тактировать. ;)

1. Включили прерывания.
2. Спокойно опросили энкодер, если есть подвижки - отключили прерывания и передали в ЦАП результат...
3. Отключили прерывания...
4. Спокойно опросили DS-ки...
5. Не менее спокойно вывели данные на дисплей...
6. GOTO п.1
Все ! ;)

Ключевые действия выделены.
Возможно, даже в вашем алгоритме это где-то пропущено... ;)

0

17

А если будут крутить энкодер когда отключены прерывания и производится опрос DS?
Лучше DS подключить к USART и тогда не придется отключать прерывания.

0

18

Пётр написал(а):

А если будут крутить энкодер когда отключены прерывания и производится опрос DS?
Лучше DS подключить к USART и тогда не придется отключать прерывания.

Если я угадал с устройством, то секунда "невидимости" энкодера некритична. ;)

0

19

Salmon написал(а):

Waitms 750 - это, согласно даташит на DS18В20

Я уже писал где то здесь. Не надо ждать 750 мс для окончания преобразования. Это происходит намного быстрее, если использовать такую конструкцию:

'Запустим преобразование
   1wwrite &H44
    Bitwait Termopin , Set
    1wreset
   1wwrite &HCC                                           
'Прочтем температуру
Где Termopin - порт подключения термометра.
Попробуйте.

+1

20

Nord
Нагревательное, коллега! :yep:  Это электронная нагрузка на 100 Вт.
Коллеги, большое спасибо за участие!
"Костыль", о котором я говорил выше, ессно, не помог - чепуху я написал.
Помогает железобетонно только отключение прерываний в подпрограмме считывания температуры.
Но, как заметил Пётр, расплатой является пропуск шагов энкодера на этом этапе.
Здесь упомянули подключение DS18B20 по USART. Это как так? Пожалуйста, поясните, кто в курсе?

0

21

Salmon написал(а):

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

Это даже не оспаривалось... ;)

Salmon написал(а):

Здесь упомянули подключение DS18B20 по USART. Это как так? Пожалуйста, поясните, кто в курсе?

Использование USART (UART) имеет смысл, если речь об эмуляции 1W-slave на устройствах, не имеющих этой функции.
Причем, не обязательно силами USART (UART).
Например - Эмуляция 1-Wire устройства ;)
При использовании МК в качестве Мастера с готовыми 1W устройствами - лишняя заморочка.

Отредактировано Nord (2021-09-05 22:35:46)

0

22

Salmon написал(а):

Нагревательное
Это электронная нагрузка на 100 Вт.

Но, как заметил Пётр, расплатой является пропуск шагов энкодера на этом этапе.

Учитывая инерционность нагрузки этими пропусками можно пренебречь...
Не атомный же реактор... ;)

0

23

Salmon написал(а):

Здесь упомянули подключение DS18B20 по USART. Это как так?

Библиотека для аппартаного модуля 1Wire на основе USART

Nord написал(а):

При использовании МК в качестве Мастера с готовыми 1W устройствами - лишняя заморочка.

Почему? Не нужно отключать прерывания.

0