вопрос по инициализации Cirrus EP9307 Опции

[merk0]

Нужна помощь по инициализации этого процессора.
Я не очень знаком с архитектурой ARM, но есть задача, в которой к данному процу подключены две флешки (Intel J3), для организации 32 разрядной флеш-памяти.
У меня есть исходники инициализации от платы EDB9315, но там стоит одна 16-рязрядная флешка.
в исходниках есть код для чтения 32 разрядной флешки(это определяется по 7 биту в регистре SysCfg 0x8093009C) куда бит ставится кодом начального загрузчика(он там проверяет куда память подключена, и обнаружив ее, в 32 режиме, ставит этот бит).
функция чтения флешки(ее кода производителя и типа девайса), проверяет этот бит и работает с флешкой либо 32 рязрядныи способом, либо 16-ти.
Читаю при это я довольно странные данные. Тип девайса вроде верный - 18H, но тип флешки - 89H(Intel), тогда как производитель - Micron(должно быть вроде 2сH).
Также похоже есть проблема с реальной шириной шины для этой пары флешек. Она похоже 16 разрядная(есть предположение).
Вопрос тут такой.
Нужно ли каким-то образом задавать при инициализации проца ширину шины для флешки(она сидит на CS6), или она (как видно по коду, что я имею) просто определяется по, фактически, ширине шины SDRAM???(чип селект 0).
Сразу предупреждаю, что схему разрабатывал не я, я не электронщик, а скорее программист.
и память и флешка по базовому адресу 0x60000000 отмаплены на их-же физ адреса, насколько я понимаю этот арм.

Короче - кто знает как правильно к EP9307 прикрутить 2 флешки, получить 32 битную флешку таким образом и что нужно делать при инициализации если такай 32 разрядная "флеша" стоит?

[aaarrr]

Для нормальной работы 32-бит шины нужно соответствующим образом проинициализировать SMCBCR6.

[merk0]

Для нормальной работы 32-бит шины нужно соответствующим образом проинициализировать SMCBCR6.

гм...как это я пропустил этот пункт в гайде...StaticMemory Controller.
а я все читал следующий в гайде контроллер - SDRAM, SyncROM, SyncFLASH controller.

вопрос чайника - на схеме устройства две флешки MT28F128J3 просто прилеплены адресами на адресную шину проца, а данные с них идут на шину данных проца: одна флешка - первая половина 32-рязр слова, другая - вторая половина 32-разр слова... и заведен на них чипселект 6.
какой вообще контроллер в этом проце отвечает за такую схематику? почему это static memory?
поскольку я чайник, я думал что это типа SyncFlash.
спасибо за инфу!

[aaarrr]

какой вообще контроллер в этом проце отвечает за такую схематику? почему это static memory?
поскольку я чайник, я думал что это типа SyncFlash.

MT28F128J3 - это обычная асинхронная флеш. И подключена она к SMC.

[AlexN]

Читаю при это я довольно странные данные. Тип девайса вроде верный - 18H, но тип флешки - 89H(Intel), тогда как производитель - Micron(должно быть вроде 2сH).

Насколько я помню, J3 флешь от микрона по идентам откликается (представляется) интелом. Короче, полный абсолютный аналог.

[aaarrr]

У них есть оба варианта. У микросхем с микроновским ID есть буква M в названии.

[merk0]

Огромное спасибо. Буду еще вопросы задавать.

[AlexN]

Огромное спасибо. Буду еще вопросы задавать.

если не секрет, на фига Вам 32бит шина на флешь? Это экзотический вариант. Стандартноо все делают 16бит. На ОЗУ - без вопросов. А вот флешь - не понятно.

[HardJoker]

если не секрет, на фига Вам 32бит шина на флешь? Это экзотический вариант. Стандартноо все делают 16бит. На ОЗУ - без вопросов. А вот флешь - не понятно.

Объем в два раза больше

[merk0]

скорее всего они поставили и впрямь для увеличения размера флешки.

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

*lp32 = (CMD_READ_ID_CODES<<16) | CMD_READ_ID_CODES; // на обе половины 32-шины данных выставляем команду чтения уида, то есть команда идет в оба чипа. lp32 - указатель на базовый адрес флешки на 32битное слово.

finfo->ManufactureId = (uint16)(((*lp32 >> 16) & (*lp32)) & 0xFFFF);//читаем уид - то есть просто делаем and от ответов обоих чипов- должен получиться ответ одной флешки если они совпадают конечно , считаем уид 16 битным словом.

finfo->DeviceId[0] = (uint8)(*(lp32+1)); //читаем уид девайса, считаем его байтом.

в результате получаем уид производителя = 189H (!), уид девайса - 18H(это правильно).
пугает уид производителя, там лишня спереди единица(по мануалу д.б. 89H). В принципе если порезать его до байта - будет как нужно...
никто с таким эффектом не сталкивался?

[aaarrr]

finfo->ManufactureId = (uint16)(((*lp32 >> 16) & (*lp32)) & 0xFFFF);//читаем уид - то есть просто делаем and от ответов обоих чипов- должен получиться ответ одной флешки если они совпадают конечно , считаем уид 16 битным словом.

Не самый надежный вариант. А если один из ответов будет 0xFFFF?

в результате получаем уид производителя = 189H (!), уид девайса - 18H(это правильно).
пугает уид производителя, там лишня спереди единица(по мануалу д.б. 89H). В принципе если порезать его до байта - будет как нужно...
никто с таким эффектом не сталкивался?

Где-то сталкивался, кажется. Не обращайте внимание пока.

[merk0]

Не самый надежный вариант. А если один из ответов будет 0xFFFF?

имеете ввиду - правильный замаскирует неверный FFFF? Угу, согласен. Для корректности надо бы делать OR и проверять. Не обратил внимания.

Где-то сталкивался, кажется. Не обращайте внимание пока.

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

[aaarrr]

имеете ввиду - правильный замаскирует неверный FFFF? Угу, согласен. Для корректности надо бы делать OR и проверять. Не обратил внимания.

Для корректности надо каждый отдельно сравнивать.

[merk0]

еще тупой вопросик.
читаю вот rtc, нужно ли запрещать прерывания при чтении или установке регистров rtc?
по описанию, вроде, инкремент регистра данных делается железом и похоже не подчиняется прерываниям никак. то есть запрещай - не запрещай, в момент чтения может произойти инкремент, если конечно чтение-запись этих регистров не делается самим ARMом как атомарная операция.

[aaarrr]

А смысл запрещать? Регистр-то один.

[merk0]

А смысл запрещать? Регистр-то один.

ну например если в RTCLoad регистр записать нечто(оно установится в data регистр на следующем секундном тике), и читать data регистр в момент этого установления, то если операция чтения неатомарна, можно получить при чтении какую-нить ерунду. на которую надо как-то реагировать.
или не так?

[aaarrr]

если операция чтения неатомарна

Неатомарной ее придется специально делать.

Да, а смысл вообще использовать RTC? У цирруса от часов одно название, на самом деле.

[merk0]

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

[aaarrr]

Ну, воля Ваша. Я бы скорее организовал программное время.

[merk0]

вы лучше скажите, ...вот я слышал что в некоторых SOC можно отключать неиспользуемые блоки(или я это слышал не о том)... а нам не нужны например тачскрин, ac'97, ethernet. Их можно как-то отключить вообще?

[aaarrr]

Лишнее можно отключить в регистрах PwrCnt и DeviceCfg.

[merk0]

отлично!
еще вопрос в догонку...
позвонил разработчику девайса, он сказал, что ему мол кажется, что можно код пускать прям из пресловутой флешной пары, что мы обсуждали выше. то есть без копирования в озу(видимо потому они там 32-шину и сделали). Рассчитывают туда положить весь исполняемый код и пускать оттуда...
Мануал к флешке имеет какие-то загадочные тексты вроде -
Similarly, program suspend mode enables the user to suspend programming to read data
or execute code from any unsuspended blocks.

Флешка имеет команду -

READ ARRAY Command
The device defaults to read array mode upon initial
device power-up and after exiting reset/power-down
mode. The read configuration register defaults to asynchronous
read page mode. Until another command is
written, the READ ARRAY command also causes the
device to enter read array mode. When the ISM has
started a block erase, program, or lock bit configuration,
the device does not recognize the READ ARRAY
command until the ISM completes its operation,
unless the ISM is suspended via an ERASE or PROGRAM
SUSPEND command. The READ ARRAY command
functions independently of the VPEN voltage.

я правильно понимаю, что прицепив флешку с статическому контроллеру, запрограммировав ее всякими там командами записи, а потом переведя в режим - read arraу, она прикинется простой такой ромкой, и оттуда можно исполнить код непосредственно?

[aaarrr]

Правильно понимаете.

У цирруса есть родная утилита для загрузки флеш, в том числе Micron/Intel. Не очень удобная, прямо скажем, но должна работать.

[merk0]

У цирруса есть родная утилита для загрузки флеш, в том числе Micron/Intel. Не очень удобная, прямо скажем, но должна работать.

если вы имеете ввиду download.exe c нулевым и первым загрузчиком(что потом грузнут редбут во флеш), то они у меня есть, я их и использовал как "заимствованный код". там пришлось некие вещи переписать. А консольную прогу(вместо download.exe) я написал свою. протокол полностью поменял. это позволило совбодно работать через компорт на 115200(раньше вроде не тянуло в силу плохого исходного протокола, и переполнения фифо у порта проца(скорее всего)) теперь бывший первый загрузчик, у меня сильно помощнел, превращаясь в прикладную и тестовую программу. В него я теперь и добавляю всякие инициализации и прочий HAL(потому и задаю вопросы).
Дело в том что плат несколько и нужна как тестовая прога(чтобы проверять их работоспособность), так и собснно прикладная прога.
Работаю над этим делом я один, задача очень раскиданная по "предметныи областям", а денег почти не платят. Если б знал - не стал и браться бы

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

[aaarrr]

Да, код у них - говно редкостное.

Для себя написал загрузчик, живущий в FIFO EMAC'а - хотя бы стартует быстро.

[merk0]

я хотел загручик записать в eeprom флешку. пока правда не сделал этого.

[merk0]

вопрос - у меня какие-то баги...есть подозрение, что это в силу возможности переупорядочивания команд arm-gcc при оптимизации.
как мастера пишут в softlock регистры этого проца?
можно это делать на си безопасно(то есть сделав и разлок регистра, и запись значения на си), или стоит это делать асмовой вставкой.
вот не могу вспомнить(если это вообще есть), как заставить gcc локально не переупорядочивать команды.

[merk0]

вопрос с порядком команд снимается.
это я пускал uart3 глядя в куд что лежит в этом download у цирруса на сайте.
в инициализации уарта1 у них ошибка.

должно бьть так. с комментом(тут те же самые команды, но для уарта3)

Код

//тут важен порядок!!! лишь по записи в HIGH регистр, в реальности пройдет запись в LOW, MID части
// то есть запись в HIGH всегда должна быть последней!!!
out(UART3LINCTRLLOW, wBaud); //пишется делитель,  в мануале формула есть
out(UART3LINCTRLMID, 0); //обнуляем, туда писать в данном случае не нужно
out(UART3LINCTRLHIGH, (BIT6|BIT5|(ffifo_on<<4))); //ставим 8бит размер символа, бит - юзать фифо или нет -  четвертый бит регистра

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

такое вот очередное наблюдение за качеством кода от цирруса

[aaarrr]

SoftLock можно безопасно писать на C - порядок volatile-обращений компилятор менять не имеет права.

Порядок записи регистров UART'а описан в даташите. Это явно лучший источник информации, хотя и в нем есть косяки

[merk0]

aaarrr,
- а вы какую ос ставили на этот проц?
- есть ли либа типа хала для этого проца, чтобы какие-то стандартные вещи с ним делать более абстрактно?
- какие тулчейны вы с ним использовали(используете)? Я пока все далаю все под winarm.

Сообщение отредактировал merk0 - Mar 9 2009, 09:56

[aaarrr]

Пробовал Линукс, сейчас использую FreeRTOS со своим набором библиотек периферии. Работаю исключительно под RVDS.

[merk0]

вопрос. а есть какие-то особенности работы с портом HGPIO, конкретно - пятый бит. У нас на железке это сигнал разрашения некоего напаянного устройства, что должно зажигать на себе светодиодики.пишу в HGPIO[5](сконфигурировав как выход) единицу-ничего не происходит(разрешение устройства по единице). Читаю бит порта обратно - единица стоит.
или с железкой проблема...или я что-то с этим портом неверно сконфигурировал.
я просто конфигурировал его как пин-выход, и прописал туда 1.

[aaarrr]

У порта H каких-то особенностей нет. Ставите HonIDE в DeviceCfg, и спокойно работаете.

[merk0]

а у ep9307 такого бита нет - HonIDE.
у него нет IDE интерфейса.

[aaarrr]

У него есть такой бит
Т.е. интерфейса нет, а бит (11 бит DeviceCfg) есть, и он работает.

[merk0]

поиск HonIDE по доке - ep9307 user guide ничего не дает.
визуальный осмотр битов регистра DeviceCfg - тоже ничего не дает.
там правда есть три неназванных бита, b11, b10, что должны быть установлены в 1,
и b5 в нуль.
один из них я есть искомый бит?

Т.е. интерфейса нет, а бит (11 бит DeviceCfg) есть, и он работает.

сильный ход со стороны разработчиков! вот поди пойми, что это связано с H портом.

а чтение пинов сконфигурированных на вывод дает варианты
1.всегда нуль
2.всегда соотвествует записанному в пин
3.соответсвует реальному напряжению на ноге порта.
вот какой?

я взвел эти биты в DeviceCfg
несколько пинов в H сконфигурированы как выход
пишу в H порт 0xFF, читаю обратно - имею нуль.

[aaarrr]

вот какой?

Третий:

Reading a data register returns the value on the corresponding GPIO pins.

Правда, выходы никогда не читал.

[merk0]

у меня читаются стойкие нули из HDR.
из регистра HDDR(направления) читается верно - те биты что аутпуты - там единицы.
щас буду читать DeviceCfg, что там стоит...

ураа! заработало!
короче была бага у меня, была нарисована макра установки бита по некоторому адресу. а я ею временами неверно пользовался, типа ставил биты в локальном слове. а потом это слово выводил в регистры проца.
вообщем она ставила биты не в слове, а адресу в слове, рассматривая его как поинтер.
то есть конфиги были частично неверны.

[merk0]

вопрос по uart3.
инициализировал я его, запустил. на loopback он работает, то есть читает сам себя- я просто пишу а uart3 символы, потом читаю их, и вывожу через uart1(этот работает правильно) на консольную прогу в писюк.
но читать устройство, по схеме присоединенное к ногам его, он не хочет. это устройство активно, мигает свтодиодиками, по паспорту должно стоять по умолчанию либо в 4800, либо в 9600, 8 бит символ, один стоп-бит, без четности. уарт3 так и выставлен(пробовал обе скорости). не читает.
варианты - проблемы хардверные - с самим устройством(это gps модуль - может в него нужно сначала команды какие-то посылать? но разработчик божится, что оно должно на 9600 сразу стоять, и гнать данные в своем протоколе), с разводкой присоединения его к пинам уарт3...

или что-то софтверное, то есть у меня. могут ли быть какие-то подводные камни в инициализации этого порта, если он таки на loopback себя читает?

[aaarrr]

А если на UART3 подать сигнал с UART1 или компьютера? Никаких подводных камней при работе с UART3 нет.

[merk0]

ну уарт3 особо ничего не подашь. он наглухо разведен на gps-приемник. если только на ноги самого приемника проводки крутить. но я дома работаю, да и плата мелкая. испорчу.
пока ковыряю протокол приемника, может он просто не хочет отвечать, пока ему что-нить не скажут?

[aaarrr]

Осциллографом посмотрите тогда. Внутренний loopback практически ничего не покажет в плане ошибок настройки скорости и протокола.
Еще можете поставить заведомо большую скорость (115200, например). Если UART ничего не принимает, то с большой вероятностью на вход ничего не приходит.

[merk0]

проверял на 115200, молчок. видимо gps модуль сильно умный. джет какой-нить команды в себя. пытаюсь запустить ему команду инициализации

[merk0]

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

...
заработало! после посылки команды инициализации в приемник, порт заговорил.
эффект присутствия осциллографа. оказывается порт приемника выставляется в 4800, но молчит, если туда не записать команду.

все оказалось хуже. на приемнике еще и непропай.
он правильно работает, если его еше и пальцем к плате прижимать
..это столько я бился с этим портом!!!

[merk0]

вопрос.
в железке для общения по i2c используются пины EECLK и EEDAT проца.
эти пины вроде есть пины G[0], G[1].
дабы настроить пины в инициализации i2c драйвера я делаю следующее
PGDDR |=3 //ставим два младших бита в регистре направения G как выходы
EEDRIVE |=3 //ставми эти же биты в регистре драйверов EECLK и EEDAT. они д.б. с открытым стоком.
далее просто пишем и читаем(не переводя G[0]G[1] как входы) биты G[0],G[1] в программной реализации i2c.
не нужны ли еще какие-то танцы с бубнами в данном случае?


кстати правильно ли я понимаю, что в случае если порт стоит как "открытый сток", запись единицы - размыкает выходной ключ, и напряжение тянется вверх резистором. а если записать нуль - ключ замыкается - и напряжение падает в нуль?

[aaarrr]

не нужны ли еще какие-то танцы с бубнами в данном случае?

Нужны, если используется external boot - тогда на EECLK должен быть pull-down, и открытый сток уже не катит.

кстати правильно ли я понимаю, что в случае если порт стоит как "открытый сток", запись единицы - размыкает выходной ключ, и напряжение тянется вверх резистором. а если записать нуль - ключ замыкается - и напряжение падает в нуль?

По идее, да.

У меня почему-то используется EEDrive = 0. Ну, с SCL все понятно, т.к. external boot, а вот зачем SDA в режиме эмуляции открытого коллектора - не помню, хоть убей

[merk0]

У меня почему-то используется EEDrive = 0. Ну, с SCL все понятно, т.к. external boot, а вот зачем SDA в режиме эмуляции открытого коллектора - не помню, хоть убей

ну там по стандарту i2c обе линии - монтажное И.
sda видимо потому монтажное и, - чтобы читать например акноледж на посланный байт. тогда в 9 такте мастер делает высокий потенциал на SDA(закрывает свой ключ), а приемник открывает ключ и потенциал становится низким. мастер воспринимает это как подтверждение.

а у вас EEпины используются для I2C?
тогда почему EEDrive=0, в доке написано что для открытого коллектора должна быть единица.

[aaarrr]

Вы меня не поняли. SDA у меня является открытым коллектором, но сделано это не при помощи установки бита в EEDrive, а вручную. SCL вообще тянется пушпулом, но у меня нет периферии, которая умеет затягивать клок.
Почему я сделал так, а не иначе - не помню.

[merk0]

нашел какие-то мутные непонятки с этими пинами в связи с реализацией I2C
1. проц является мастером и потому дает клоки. также его эти две ноги стоят в положении открытый коллектор.
2. попытка изменить пины 0,1 в регистре G приводит к читке регистра, изменению бита и записи обратно в регистр. Но при чтении регистра порта читаются не значения туда прописанные, а значения стоящие на ногах проца(которые могут отличаться от прописанных в порт, в силу монтажного И). таким образом например запись в первый бит(DATA) регистра G, может привести к сбросу в нуль значения записанного в бит 0 (CLOCK)(потому что клок удерживался слейвом в это время на нуле).
то есть нужно иметь локальную переменную(якобы регистр порта), все битовые работы делать с ней, а потом, просто писать в порт эту перемнную(байт), физически не читая его.

[aaarrr]

А что у Вас на I2C висит? Может, не стоит и напрягаться?

[merk0]

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

int ext_rtc_ping()
{
int lb;
i2c_start(); //Start Trasfer
lb=i2c_write (( DS1399_addr<<1) | 1); //Read Data
i2c_stop();
return (lb);
}

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

Сообщение отредактировал merk0 - Mar 17 2009, 23:18

[aaarrr]

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

Ну, совсем по стандарту вряд ли возможно сделать просто на GPIO. Мастер-то хоть один будет?

Можете проверить на этом. Не соответствует спецификации, зато точно работает.

CODE

//******************************************************************************

__inline void i2c_force_scl(void)
{
PGDR &= ~SCL;
}

__inline void i2c_release_scl(void)
{
PGDR |= SCL;
}

__inline void i2c_force_sda(void)
{
PGDR &= ~SDA;
PGDDR |= SDA;
}

__inline void i2c_release_sda(void)
{
PGDDR &= ~SDA;
}

__inline u_int i2c_read_sda(void)
{
return (PGDR & SDA);
}

//******************************************************************************

int i2c_ini(void)
{
// HW
EEDrive = 0x00;
PGDR &= ~SDA;
PGDR |= SCL;
PGDDR &= ~SDA;
PGDDR |= SCL;

return 0;
}

u_int i2c_write_byte(u_int data)
{
u_int a;

for(a = 0; a < 8; a++)
{
i2c_force_scl();
i2c_qp_dly();
data <<= 1;
if(data & (1 << 8)) i2c_release_sda();
else i2c_force_sda();
i2c_qp_dly();
i2c_release_scl();
i2c_hp_dly();
}

i2c_force_scl();
i2c_qp_dly();
i2c_release_sda();
i2c_qp_dly();
i2c_release_scl();
i2c_hp_dly();
if(i2c_read_sda()) return 1;
else return 0;
}

u_int i2c_read_byte(u_int ack)
{
u_int a, data;

data = 0;
for(a = 0; a < 8; a++)
{
i2c_force_scl();
i2c_qp_dly();
i2c_release_sda();
i2c_qp_dly();
i2c_release_scl();
i2c_hp_dly();

data <<= 1;
if(i2c_read_sda()) data |= 1;
}
i2c_force_scl();
i2c_qp_dly();
if(!ack) i2c_force_sda();
else i2c_release_sda();
i2c_qp_dly();
i2c_release_scl();
i2c_hp_dly();

return data;
}

void i2c_start(void)
{
i2c_force_scl();
i2c_qp_dly();
i2c_release_sda();
i2c_qp_dly();
i2c_release_scl();
i2c_qp_dly();

i2c_force_sda();
i2c_hp_dly();
}

void i2c_stop(void)
{
i2c_force_scl();
i2c_qp_dly();
i2c_force_sda();
i2c_qp_dly();
i2c_release_scl();
i2c_qp_dly();
i2c_release_sda();
i2c_qp_dly();
}

void i2c_qp_dly(void)
{
u_int a = 0x80;
while(--a) __asm{nop};
}

void i2c_hp_dly(void)
{
u_int a = 0x100;
while(--a) __asm{nop};
}

//******************************************************************************

[merk0]

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

[aaarrr]

Так пройдитесь по всем адресам, если не уверены. Их же всего 128.

А не отключают ли часы I2C интерфейс при разряженой батарейке? У кого-то из далласов такая фича была.

[merk0]

за код спасибо, щас посмотрю его глазами.. он для пинов - открытых коллекторов? если нет - то работать не должен.

У кого-то из далласов такая фича была.

гм..а вот это надо проверить...

[aaarrr]

Нет, открытый коллектор только на SDA. Работать должен в любом случае.

[merk0]

а у вас EEdrive = 0;
то есть по даташиту - это не open drain. Это драйвер от вашей схемы?

__inline void i2c_force_sda(void)
{
PGDR &= ~SDA;
PGDDR |= SDA;
}

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

[aaarrr]

Да, у меня сделана программная эмуляция open drain на SDA (ну да, через бит направления порта), и использован обычный выход SCL.

А про отключение интерфейса я малость напутал - это в DS1307 он отключается, когда VCC становится меньше 1.25 * Vbat

[merk0]

Да, у меня сделана программная эмуляция open drain на SDA (ну да, через бит направления порта), и использован обычный выход SCL.

А не опасно так эмулировать opendrain??? если SDA - обычный драйвер - то что будет если проц его выставил в в единицу(то есть замкнул ключ на питание - если там выходные драйверы такие), а слейв коротнул свои ключом эту линию на нуль? и будет типа КЗ. чот исключено если таки выходы стоят в честном opendrain.
аналогично и на scl.

scl по теории, при затяжке низкого уровня слейвом, точно привдет к кз, если выход scl проца - обычный.
или я не так вижу железо вообще?

[aaarrr]

А не опасно так эмулировать opendrain??? если SDA - обычный драйвер - то что будет если проц его выставил в в единицу(то есть замкнул ключ на питание - если там выходные драйверы такие), а слейв коротнул свои ключом эту линию на нуль? и будет типа КЗ.

На SDA никогда не выставляется единица - драйвер или выдает 0, или отключен.

scl по теории, при затяжке низкого уровня слейвом, точно привдет к кз, если выход scl проца - обычный.
или я не так вижу железо вообще?

Ну, далеко не все слейвы умеют затягивать SCL. В моей системе таких попросту нет.

[merk0]

На SDA никогда не выставляется единица - драйвер или выдает 0, или отключен.

а попробуйте поставить EEdrive = 2 - это будет opendrain на sda. сразу выставить sda на выход(не меняя никогда), а читку линии sda делать так;
- сначала переводим sda в высокий, потом просто читаем из пина sda.
у меня такая реализация.

с клоком - аналогично.
чтобы делать затягивание просто написано
типа так
set_clk_high(); //ставим клок в высокое состояние
while(get_clk()==0){}; //пока клок опущен другим устройстом - ждем.

Сообщение отредактировал merk0 - Mar 18 2009, 00:24

[aaarrr]

а попробуйте поставить EEdrive = 2 - это будет opendrain на sda. сразу выставить sda на выход(не меняя никогда), а читку линии sda делать так;
- сначала переводим sda в высокий, потом просто читаем из пина sda.

А смысл? По сути ничем не отличается от того, что сделано у меня. Держать выводы в различных конфигурациях неудобно, поэтому видимо я и забил на EEDrive.

с клоком - аналогично.

А вот на клоке у меня pull-down.

[merk0]

ну ладно..отличается-не отличается...главное что у меня не работает, хотя - и не отличается...

а зачем вы делаете release_sda(см коммент в коде)

u_int i2c_read_byte(u_int ack)
{
u_int a, data;

data = 0;
for(a = 0; a < 8; a++)
{
i2c_force_scl();
i2c_qp_dly();
i2c_release_sda(); // ВОТ ТУТ???
i2c_qp_dly();
i2c_release_scl();
i2c_hp_dly();

data <<= 1;
if(i2c_read_sda()) data |= 1;
}
i2c_force_scl();
i2c_qp_dly();
if(!ack) i2c_force_sda();
else i2c_release_sda();
i2c_qp_dly();
i2c_release_scl();
i2c_hp_dly();

return data;
}

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

Сообщение отредактировал merk0 - Mar 18 2009, 00:43

[aaarrr]

ну ладно..отличается-не отличается...главное что у меня не работает, хотя - и не отличается...

А мой код работает, или тоже нет?

а зачем вы делаете release_sda(см коммент в коде)

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

SDA может быть затянут мной в 0 на входе в процедуру чтения. Сразу перевести его в 1 я не могу, т.к. SCL находится в высоком уровне и это действие будет воспринято слейвом как Stop-условие.

[merk0]

А мой код работает, или тоже нет?

а я так сразу проверить не могу, нужно его под gnu-arm править. я держу ваш код пока в качестве референсного.

SDA может быть затянут мной в 0 на входе в процедуру чтения. Сразу перевести его в 1 я не могу, т.к. SCL находится в высоком уровне и это действие будет воспринято слейвом как Stop-условие.

аа ну да, похоже. у меня просто start, read_byte, write_byte так написаны, что на выходе всегда ставят клок - низкий, то есть при входе в любую функцию - он снова низкий. и только на выходе i2c_init и stop клок и дата высокие - поскольку после этих функций шина д.б. свободна.

[merk0]

!!!!!!!!!!!!!!!!!!!!

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

[aaarrr]

Да, кризис в действии. Сочувствую. Обращайтесь, если что.