Пришелец
-
Постов
186 -
Зарегистрирован
-
Посещение
Сообщения, опубликованные Пришелец
-
-
Спасибо большое
:a14:
Обновил segger - проблема осталась
Или я что-то не понял. Я так понял что штатный бутлоадер не запускаетя из под отладчика и не устанавливает ADCTRIM что и вызывает проблему.
Может в настройках какую галку нужно поставить чтобы стартовал с встроенного бутлоадера???
но ADCTRIM на самом деле как то влияет. Если руками в отладке установить(или переустановить) его значение. То ацп начинает работать.
жаль он недокументирован полностью этот регистр.
-
Добрый день!
никто не сталкивался с проблемой?:
LPC1768 - не работает правильно ADC при отладке через JTAG.
Без отладки (даже с подключенным разъёмом всё работает).
Измерения производятся циклически по всем каналам, каналы переключаются по прерыванию АЦП.
С jtag прерывания происходят но результат измерения всегда = 4095 т.е. максимальное значение.
-
Опубликовано · Изменено пользователем Пришелец · Пожаловаться
а какие примерно скорости должны быть для MMC и SD для современных карточек до 2Гб?
А должны были. Ищите источник торможения, 360Кбайт/с - это неприлично мало для приведенных условий.Проверьте, как эти карты пишутся на PC.
А сколько должно быть? примерно.
на компе:
SD 1.3 MB/sec
MMC 2.8 MB/sec
А должны были. Ищите источник торможения, 360Кбайт/с - это неприлично мало для приведенных условий.Проверьте, как эти карты пишутся на PC.
А сколько должно быть? примерно.
на компе:
SD 1.3 MB/sec
MMC 2.8 MB/sec
-
А должны были. Ищите источник торможения, 360Кбайт/с - это неприлично мало для приведенных условий.
Проверьте, как эти карты пишутся на PC.
А сколько должно быть? примерно.
на компе:
SD 1.3 MB/sec
MMC 2.8 MB/sec
-
Практика показывает, что чем больше, тем лучше.
Увы, никаких комментариев дать не могу, т.к. не использую. В своих системах применяю кэширование (Write Through, размер строки - 8 секторов) и отдельный буфер записи (16кБайт или больше). Перед записью на карту сектора в буфере сортируются, затем отправляются несколькими получившимися непрерывными блоками.
Сделал отправку по 8 кб вместо 512 байт - отличий в скорости не заметил.
ещё заметил что MMC пишет намного быстрее SD (SD 2 ГБ очень медленно)
-
Скорость SPI какая? Если не используется write multiple blocks, то о приличной скорости можно забыть.
40 МГЦ
насчёт write multiple blocks не просвятите?
какое кол-во блоков должно отправляться для эффективной записи?
или это не имеет значения?
используется fatfs - там есть многоблочная запись.
-
Я представляю себе это как какой-то обходной манёвр :rolleyes:
например перевод всей шины в SUSPEND - но это не помогает пробовал (камера потом продолжает видимо с нового кадра)
или например подстановка одного и того же номера фрейма в usb фреймы - не пробовал думаю это не прокатит.
конечно понятно что всё это будет сделано мягко говоря криво и наверное так делать нельзя.
замерил скорость записи на SD получилось 360 КБ/сек
видео может идти примерно 780 кб/сек (размер кадров 800 байт каждую мс)
придётся видимо всё же пробовать играть в догонялки с камерой.
кто что может сказать про скорость записи на карточку памяти по SPI ???
-
Просьба модераторам удалить данную тему
т.к. она ошибочно добавилась и является дубликатом существующей темы.
Спасибо.
-
Примерно так:
DSTATUS USB_disk_initialize(void) { int32_t rc; uint32_t numBlks, blkSize; uint8_t inquiryResult[INQUIRY_LENGTH]; // Host_Init(); /* Initialize the lpc17xx host controller */ // rc = Host_EnumDev(); /* Enumerate the device connected */ if (usbhost_ms) { /* Initialize the mass storage and scsi interfaces */ rc = MS_Init( &blkSize, &numBlks, inquiryResult ); if (rc == OK) { return FR_OK; } else { return (FR_DISK_ERR); } } else { return (FR_DISK_ERR); } } DSTATUS USB_disk_status(void) { return FR_OK; } DRESULT USB_disk_read( BYTE *buff, /* Pointer to the data buffer to store read data */ DWORD sector, /* Start sector number (LBA) */ BYTE count /* Sector count (1..255) */ ) { MS_BulkRecv(sector, count, buff); return RES_OK; } DRESULT USB_disk_write( BYTE *buff, /* Pointer to the data to be written */ DWORD sector, /* Start sector number (LBA) */ BYTE count /* Sector count (1..255) */ ) { MS_BulkSend(sector, count, buff); return RES_OK; } extern uint32_t MS_BlkSize; extern uint32_t MS_NumBlks; DRESULT USB_disk_ioctl ( BYTE ctrl, /* Control code */ void *buff /* Buffer to send/receive control data */ ) { DRESULT res; BYTE n, csd[16], *ptr = buff; WORD csize; res = RES_ERROR; if (ctrl == CTRL_POWER) { res = RES_OK; } else { switch (ctrl) { case CTRL_SYNC : /* Make sure that no pending write process */ res = RES_OK; break; case GET_SECTOR_COUNT : /* Get number of sectors on the disk (DWORD) */ csize = MS_NumBlks; *(DWORD*)buff = (DWORD)csize; res = RES_OK; break; case GET_SECTOR_SIZE : /* Get R/W sector size (WORD) */ *(WORD*)buff = MS_BlkSize; res = RES_OK; break; case GET_BLOCK_SIZE : /* Get erase block size in unit of sector (DWORD) */ *(DWORD*)buff = 1; res = RES_OK; break; default: res = RES_PARERR; } } return res; } -
Всем доброго дня!
Может кто сталкивался с подобной проблемой?
имеется ли возможность приостановить на стороне хоста OCHI данные от изохронной конечной точки?
(с возможностью их дальнейшего продолжения)
В применении: к получению данных с USB камеры. памяти LPC1768 не хватает для единовременного захвата кадра большого разрешения,
а записать на FLASH нужно время.
Камера имеет только изохронную конечную точку. Bulk нет.
Спасибо за любые мысли.
-
Всем доброго дня!
Может кто сталкивался с подобной проблемой?
имеется ли возможность приостановить на стороне хоста OCHI данные от изохронной конечной точки?
(с возможностью их дальнейшего продолжения)
В применении: к получению данных с USB камеры. памяти LPC1768 не хватает для единовременного захвата кадра большого разрешения,
а записать на FLASH нужно время.
Камера имеет только изохронную конечную точку. Bulk нет.
Спасибо за любые мысли.
-
как насчёт usb камеры?
-
Контрольные запросы проходят - не отвечает именно на этот
rc = Host_CtrlRecv(USB_DEVICE_TO_HOST | USB_REQUEST_TYPE_CLASS | USB_RECIPIENT_INTERFACE,
GET_CUR,
0x0200,
0x0001,
0x0022,
UserBuffer);
не отсылается последний из трёх transfer descriptor - непонятно. Ну да и ладно пока. :rolleyes:
Новый вопрос:
почему то не работают interrupt transfers (точнее понятно почему - что-то не так делаю но что ... :smile3046: )
HCCA настраиваю (т.е. записываю в массив один указатель на ED)
в HC адрес HCCA записываю.
ED настроил по аналогии с ED для bulk
TD к ED подключил
прерывание по передачи TD разрешено (control transfer работают)
поля CONTROL в TD и ED не изменяются такие же как и после их инициализации.
Может засовываю в HCCA не вовремя - есть такое предположение.
вообщем HC ничего с моим EDinterrupt не хочет делать :crying:
Может кто сталкивался с подобным?
-
LPC1768
HOST взят за основу хост от LPC (который умеет работать с флэшкой)
подключаю камеру UVC
енумерация проходит, стандартные запросы работают такие как установка адреса, установка интерфейса, установка конфигурации, чтение дескриптора.
но если пытаюсь послать TYPE_CLASS запрос то он не проходит:
rc = Host_CtrlRecv(USB_DEVICE_TO_HOST | USB_REQUEST_TYPE_CLASS | USB_RECIPIENT_INTERFACE,
GET_CUR,
0x0200,
0x0001,
0x0022,
UserBuffer);
Никто не сталкивался с этим? И ещё не посоветуете где можно было бы подсмотреть читабельные исходники host usb.
для работы с изохронными и interrupt передачами...
Спасибо.
-
SK-MLPC1766
и ещё вопросик знающим:
для декодирования MP3 хватит производительности? при частоте 100 МГц
а проблема решилась: взял пример для keil а cstartup из IAR - так работает
(правда не понял в чём дело было - ну да и ладно - не суть)
вообще nxp молодцы - примеры ПО у них хорошие
-
Спасибо - нашёл.
дааа торможууу
-
http://www.standardics.nxp.com/products/lpc1000/lpc17xx/
вам нужен User Manual
Если несложно ткните носом пожалуйста - что-то никак его там не найду :smile3046:
-
Добрый день!
запускаю тестовый пример из IARa на LPC1768
процессор запускается под jtag и переходит на вектор HardFault_Handler при попытке записи значения в регистр порта ввода вывода
настройка частоты проходит нормально.
И ещё не нашёл документации на этот процессор кроме как LPC1768_66_65_64_2.pdf
но там нет описания регистров и перифирии ...
заранее спасибо
-
сдаюсь :rolleyes:
согласен
убедили
Спасибо.
-
Опубликовано · Изменено пользователем Пришелец · Пожаловаться
про cli явно написано что после него не выполнится ни одно прерывание
про флаги индивидуальных запретов прерываний такого не написано.
после появления запроса прерывания выполняется текущая команда
так вот если этой командой окажется TIMSK=0
то запрос будет принят на обработку или нет ???
по моему это обсуждение не имеет смысла. Я на пример так и не понял чего добивается автордобиваюсь ясности в своей голове - может и не только мне а и другим это будет полезно.
-
Тогда, следуя вашей логике, надо и после CLI ставить нопы :), поскольку CLI точно так же стирает маску, как и TIMSK=0 (только в другом регистре масок - в SREG). И по своей аппаратной реализации ничем не отличается.
После CLI не надо :rolleyes:
я думаю эти два механизма по разному работают.
-
Опубликовано · Изменено пользователем Пришелец · Пожаловаться
после возврата из прерывания следующее прерывание начинает обрабатываться не сразу
это говорит о том что подготовка к переходу на прерывание существует (видимо одна команда)
если в момент обнуления TIMSK (в момент исполнения этой команды или за одну команду до неё)
начнёт обрабатываться запрос на прерывание по таймеру то он будет обработан
проще конечно не гадать а на время обнуления TIMSK запретить все прерывания cli
а потом разрешить
_CLI();
TIMSK=0;
_SEI();
наверное ... ???
время выполнения команды... по идее.. т.е. если выполняется двухтактовая команда.. на первом такте пришло прерывание.. команда довыполнится и начнется обработчик..т.е. одного nop достаточно видимо.
-
в этом протоколе можно выделить задержки которые критичны и которые некритичны
прерывания можно запрещать только на время критичных задержек.
-
Интересно какая максимальная задержка может быть между появлением запроса на прерывание и его выполнением
т.е. переходом на вектор прерывания.
например прерывания по таймеру маскируются записью в TIMSK
и далее выполняется работа которая должна происходить при запрещённых прерываниях таймера
по идее после TIMSK=0
нужно поставить несколько NOP т.к. во время этой команды уже может быть начата подготовка к переходу на прерывание
так вот вопрос сколько нопов здесь нужно?
по-моему трёх должно хватить - но может я ошибаюсь...
LPC1768 + ADC + JTAG
в ARM
Опубликовано · Изменено пользователем IgorKossak
Лишние пробельные строки, растягивающие пост · Пожаловаться
Понятно.
переставил драйвера и ПО не помогло.
но проблема действительно в этом.
если сделать резет из под jtag программно по WDT например, то АЦП нормально начинает работать.