Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Работа с i2c устройствами в Linux
Форум разработчиков электроники ELECTRONIX.ru > Cистемный уровень проектирования > Операционные системы > Программирование
wolfman
Здравствуйте.
Необходимо отладить I2c-шные корки в ПЛИС, т.к. ничего кроме Raspbery PI 2 нет, решил использовать её как мастер, наваял простенький код на Питоне.

На этапе отладки тестового софта использую eeprom и SFP модули.

Все бы хорошо, но есть проблемы: не читает данные из eeprom(типа AT24C256), точнее читает, но только один и тот же байт данных.
При этом из всевозможных SFP модулей данные читаются нормально.
В eeprom, если я правильно понимаю, используется страничный доступ, как его задействовать?
Если можно на пальцах, т.к. я ни разу не программист.

Код
#!/usr/bin/python
import smbus
import time

DevAddr = 0x55

bus = smbus.SMBus(1)

print "I2C: Read from Device 0x%02X" % DevAddr
for DevRegAddr in range (255):
    try:
        ret = bus.read_byte_data(DevAddr, DevRegAddr)
    except IOError, err:
        print "error reading device 0x%02X" % DevAddr
        exit(-1)
    print "%X" % ret
Ruslan1
Цитата(wolfman @ Nov 19 2015, 16:27) *
В eeprom, если я правильно понимаю, используется страничный доступ, как его задействовать?
Если можно на пальцах, т.к. я ни разу не программист.

Так в документации смотрите. Гуглится по строке поиска "AT24C256". Там смотрите раздел что-то вроде "RANDOM READ".
Там на картинке просто все нарисовано (в атмеловской документации это "Figure 5. Random Read"): сначала пишите туда адрес, а потом читаете данные.
Страницы- это при записи массивов актуально, не при чтении и не при записи отдельных байтов.
Что именно непонятно?
wolfman
Делал так, толку ноль. И мне нужно читать фактически массивом.
Ruslan1
Цитата(wolfman @ Nov 19 2015, 18:09) *
Делал так, толку ноль. И мне нужно читать фактически массивом.

Если Вы реализовали именно ту картинку, которая в документации, а "толку ноль" -то что-то нужно менять.
Кстати, а как Вы определили что "делали так"? давайте картинку с логического анализатора, они обычно автоматом дешифрируют байтики, очень удобно смотреть. Ну или хоть осциллографом возьмите и перерисуйте ручками, там всего-ничего длина посылки.
Чудес не бывает- если диаграмма именно та, но не работает, то или микросхема плохая или адрес не тот или все-таки нужно звать программиста.
wolfman
С программистами сложнее, посему и ваяю сам. Диаграмки завтра. И когда писал, подумал, что может действительно не так писал(домой приезду, проверю). С SFP, нормально читается, там фактически таже eeprom, вот что смущает.
krux
Цитата(wolfman @ Nov 19 2015, 19:38) *
С SFP, нормально читается, там фактически таже eeprom, вот что смущает.

не совсем.
в SFP-модулях не предусмотрено настраиваемой адресации, как в обычном i2c, т.е. вы не можете повесить на одну i2c шину несколько SFP-модулей.
поэтому одного адреса A0, как для SFP, любым другим i2c устройствам недостаточно.
смотрите внимательно временные диаграммы для общения с EEPROM.

wolfman

Ну почему же, в случае конкретной eeprom, я корочу ножки адреса на "землю" и получаю адрес 0x50(A0).
С другими устройствами будет по другому, тут согласен. Как раз разбираюсь с такой i2c коркой, которая позволяет выходить на Авалон с разной шириной данных.
krux
ок.
смотрим внимательно на даташит для AT24C128/256, на страницу 11.
Нажмите для просмотра прикрепленного файла

1) Fisrt word address
2) Second word address
вы их посылаете?

зы. в SFP их не посылают, ага.
wolfman
krux
Хорошо.

Хм, возможно понял почему не работает, завтра проверю.
krux
Цитата(wolfman @ Nov 19 2015, 21:01) *
krux

Вот такая команда
Код
bus.write_byte_data(DevAddr, DevRegAddr, value)
разве не это делает?
Или надо по другому?

ХЗ
фиг знает, что конкретно функция "bus.write_byte_data" из вашей библиотеки делает.
не видя исходного кода - невозможно сказать.

по факту - ждём осциллограмм.
без них обсуждение в тупике
wolfman
Спасибо всем откликнувшимся, я действительно не правильно формировал запросы к eeprom,
точнее не правильно использовал функции чтения/записи.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.