jhoo

AP-686 Intel® FlashFile System Selection Guide Правда документ староват - '98 года AP-686

Может быть поздно. Но, http://www.thesycon.de/

Что такое пустые пакеты SEND_ACK и GET_ACK? Просто usb пакеты нулевой длины (ZLP)? Какая стоит win? Для первых экспериментов лучше отключить кеширование. Правильно ли контролируешь отработку этапов CBW-DATAIN-CSW? Даже если предположить что размер данных совпадает с размером bulkin, то это не согласуется с командой RBC_READ_CAPACITY_10=0x25, для которой формат данных READ_CAPACITY_DATA равен 8 байт, а размер CSW 13 байт. Лучше отлаживать все команды по отдельности, например через usbio. Я делал так: подключал обычную usb флешку и с помощью сниффера записывал все команды, котрые использует винда. А уж потом из программы usbio отправлял бинарные файлы с командами и данными. Тогда сразу видно будет кто виноват.

Чип - AT91SAM7S256, mass storage class. Означает, что прибор не всегда готов для связи с пк, а загоняется в него вручную пользователем

Вышли пожалуйста сюда [email protected]

Решили проблему так: Режим связи прибора с ПК по usb происходит "по кнопке", а не в любой момент времени. Прибор перед тем как включить pulup на D+ проверяет линию VBUS, если есть +5В то включает, иначе находится в ожидании. А разъем поставили 2РМххх.

Вот именно к этому варианту я больше и склоняюсь. От примера не отказался бы. Сканирование устройств можно делать через функции SetupDiXXX по известному GUID устройства (его я знаю), их можно открывать функциями CreateFile(), значит можно использовать DeviceIoControl() и запихивать в буфер scsi-запрос. Вопрос: какой IOCTL code нужно указывать? В исходнике программы diskid32.exe diskid32 при сканировании шины использовался код IOCTL_SCSI_MINIPORT. Может ч/з него? Пока проверить не могу. И вообще будет ли работать такая схема если кто-то уже делал.

Такой способ рассматривался и он плохо подходит для установки времени по ряду причин. К сожалению у меня нет этого исходники. А в чем там суть?

Использую исходники atmel mass storage, прибор представляется как дисковый накопитель. Нужно иметь возможность считывать и записывать в прибор специфическую информацию (например установка даты/времени). Поскольку весь обмен идет через команды scsi, то можно ли для моей задачи применить зарезервированные номера команд? Или это надо делать через WRITE BUFFER(3Bh) и READ BUFFER(3Ch) и через них использовать свой протокол обмена? Какие способы отправки scsi команд в устройство можно использовать вообще? Кто-то работал через интерфейс aspi, или же не стоит с ним связываться.

Действительно, проблема была в overrun error. Нужно было отлавливать это событие.

Использую TWI для работы с еепром и ртц. Все работает как положено. Параллельно работает тамер 0, в обработчике прерывания которого выполняю некоторую работу. Вот что заметил - если прерывание таймера длится относительно долго (точный предел не знаю, у меня около 80мкс), то после выхода из него и возврата к продолжению работы с еепром TWI зависает на проверке статуса готовности принятых данных. Если длительность прерывания таймера маленькая, то все нормально. Программа выглядит примерно так: main() { //....... while (1) { EEPR_ReadData(...); } } void Timer0IRQ(void) { // что-то делаю (~80 мкс) } int AT91F_TWI_ReadData(LPVOID Data, int Size) { int Error=0; int Status,Count=0; AT91PS_TWI pTwi = AT91C_BASE_TWI; BYTE *pData = (BYTE*)Data; pTwi->TWI_MMR |= AT91C_TWI_MREAD; { pTwi->TWI_CR = AT91C_TWI_START; for(Count=0; Count<Size; Count++) { if (Count == (Size - 1)) pTwi->TWI_CR = AT91C_TWI_STOP; Status = pTwi->TWI_SR; while (!(Status & AT91C_TWI_RXRDY)) { Status = pTwi->TWI_SR; // <---------- В этом цикле происходит зависание } *pData++ = pTwi->TWI_RHR; } } return 0; } Т.е. получается что TWI не любит когда его прерывают на длительное время? Как с этим бороться, ведь теоретически прерывания могут длиться любое время.

Собственно проблема заключалась в отправке "повторного старта" после фазы записи адреса данных в микросхеме. Здесь я имел в виду адрес микросхемы, а не адрес данных. В итоге понял что можно обойтись без повторного старта, а с помощью обычного. Т.е. с помощью двух независимых пакетов - "запись адреса данных" и "чтение данных".

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

Не получается организовать random read из внешней еепром. После отправки фрейма на запись адреса памяти еепром и получения ACK не могу добиться отправки стартового условия+адрес микросхемы и далее последовательного чтения. Стартовое условие+адрес микросхемы отправляется только после стопового условия, но это условие не должно быть по протоколу Кто уже работал с i2c подскажите что еще нужно сделать.

Все,разобрался. Посмотрел атмеловский стартап (для ос использовал другой), они после обработки любых прерываний выполняли запись в EOICR. У меня же эта операция была только в обработчике PIT. Сделал так же и всё заработало. Вообщем сам виноват.

Создал простейший проект на основе примера с портом для ат91 (AN-1014.pdf) Все сделал как положено, вот пример стартовой задачи: void StartTask (void *p_arg) { INT8U i; p_arg = p_arg; BSP_Init(); #if OS_TASK_STAT_EN > 0 OSStatInit(); #endif LED_Off(BSP_LED_ALL); timer_init (); // <--- после этого цикл внизу успевает прокрутиться 1 раз while (1) { for (i = 1; i <= 4; i++) { LED_On(i); OSTimeDlyHMSM(0, 0, 0, 50); LED_Off(i); } for (i = 1; i <= 4; i++) { LED_On(5 - i); OSTimeDlyHMSM(0, 0, 0, 50); LED_Off(5 - i); } } } Системные тики идут от PIT. Все работало прекрасно, пока не потребовалась работа с другой периферий, котрая использовала прерывания - UART и таймера 0,1. После этого почему-то прерывания перестали генерироваться совсем, в т.ч. и от PIT, поэтому в ОС критится только задача OS_TaskIdle. Проверял рабочйи пример который с портом, добавляя в него работу с другими прерываниями, результат тот же. Что я сделал не так? Вот обработчик прерываний, void OS_CPU_IRQ_ISR_Handler (void) { BSP_PFNCT pfnct; #if 1 pfnct = (BSP_PFNCT)AT91C_BASE_AIC->AIC_IVR; /* Read the interrupt vector from the VIC */ if (pfnct != (BSP_PFNCT)0) { /* Make sure we don't have a NULL pointer */ (*pfnct)(); /* Execute the ISR for the interrupting device */ } #else pfnct = (BSP_PFNCT)AT91C_BASE_AIC->AIC_IVR; /* Read the interrupt vector from the VIC */ while (pfnct != (BSP_PFNCT)0) { /* Make sure we don't have a NULL pointer */ (*pfnct)(); /* Execute the ISR for the interrupting device */ pfnct = (BSP_PFNCT)AT91C_BASE_AIC->AIC_IVR; /* Read the interrupt vector from the VIC */ } #endif } который вызывается из OS_CPU_IRQ_ISR.

Спасибо за разъяснение. Альтернативные функции в принципе мне тоже не нужны. Просто нужно было знать на будущее.

Т.е. независимо от того как до этого были настроены линии запись в ADC_CHER переключит эти линии для АЦП, а запись в ADC_CHDR восстановит предыдущие настройки?

В живую пока с ним не работаю, поэтому знаю то что есть в даташите. Собственно вопросы. 1. В описании АЦП сказано, что все его входы AD0-AD7 поступают на мультиплексор после контроллера PIO, что видно на блок-схеме. А в описании самого PIO контроллера мультиплексируются только линии AD0-AD3 (это также видно и в таблице pinouts). Т.е. получается что верить нужно второму? 2. Фрагмент таблицы 11.3 "PIO Controller A Multiplexing" I/O Line PeripheralA PeripheralB Comments -------- ------------ ------------ -------- PA17______TD______PCK1______AD0 PA18______RD______PCK2______AD1 PA19______RK______FIQ________AD2 PA20______RF______IRQ0_______AD3 Как происходит подключение AD0-AD3 к PA17-PA20? Я должен сначала задействовать PA17-PA20 как GPIO на вход, а затем разрешить каналы АЦП через регистр ADC Channel Enable Register ADC_CHER, и таким образом я получу то что хочу? Или я что-то недопонял в документации? На плате я бы конечно это смог проверить, но к сожалению у меня пока ее нет.

С порядком включения конечно будут трудности. Хотя как вариант можно сначало подключать кабель к устройству, а потом к ПК, только гарантии не будет - могут включать наоборот. Или же подключать кабель при выключенном устройстве. Спасибо, BVU, будем думать дальше.

В воде устройство находиться в принципе не будет, будет использоваться нефтянниками,т.е. будет подвергаться влажности, нефтяным загрязнениям и проч. С порядоком подключения и количестве используемых линий в курсе. Если рассматривать вариант с разъемами, которые мы используем сейчас, то вопрос - чем мне будет грозить другая последовательность включения линий. Сразу скажу что устройство с батарейным питанием. Скажется ли это на некачественном обнаружении устройства при подключении к ПК? миниUsb пока возьмем на заметку.

Уважаемые, что можете посоветовать в качестве замены стандартного разъема USB в разрабатываемом устройстве. Обычный разъем не удовлетворяет требованиям по герметичности. Раньше для интерфейсов RS232 и RS485 ставили, соответственно DB9 и 2РМ14, но тут возникла необходимость поставить USB, могу ли я к такому разъему его привязать, ведь по спецификации usb-разъем имеет особый конструктив. Если нельзя, то какие герметичные разъемы можно еще использовать, или какие применяете Вы?