Перейти к содержанию
Поиск
    

VslavX

Свой
 Профиль  Обзор контента

  • Постов

    1 046

  • Зарегистрирован

  • Посещение

 Тип контента 

Сообщения, опубликованные VslavX

  1. Опубликовано · Пожаловаться

    Ищу кто выполнит данную работу за меньшую цену. Подробнее о том, что нужно сделать:

    стандартное ОЗУ объемом 128 кб (16 микросхем КР565РУ5) необходимо заменить компактными и современными компонентами (недорогими и доступными), предусматривая таким образом, что при подпаивании вместо стандартного ОЗУ они будут идентично его заменять (расширяя до нескольких

    мегабайт),

    Хм, задача интересная, жалко что практической реализации не заслуживает (отвечаю "токмо волею пославшей мя жены" ©- как бывший фанат PDP-11). Я бы решал при помощи FPGA и SDRAM. Некоторая проблема в 5V-tolerant FPGA - ЕМНИП, у Альтеры это ACEX1K последний такой был. Память для простоты можно взять SDR. Расширить объем - это нужны дополнительные адресные линии или механизм страниц какой нагородить - там что-то подобное EMS для шины МПИ стандартное придумали вроде (когда-то драйвер для RT-11 под такое расширение писал).

     

    когда процессор будет работать на более высоких частотах (сотни мегагерц).

    Я так понимаю, Вы и на процессор такой апгрейд заказать хотите? :biggrin: Тогда уж лучше всю схему переработать. В Сети есть открытые проекты PDP-11 на FPGA, даже с контроллерами НЖД, НГМД, и консольного терминала. (Ото народ пидипишка зацепила :))

     

  4. Опубликовано · Пожаловаться

    Вот ссылка более заслуживающая доверия, 11Куе за 6104 и 7400$ за младшенький 6062.

    Появилось валом везде этих новых Риголов 6xxx, тока цена не совсем адекватная - в районе ~$10К, за эти деньги можно уже на Лекрой с похожими параметрами (4-5Гигасемплов, 400-600МГц полоса) смотреть. Интересно, попустит их с ценой или нет - за $4-5K можно было бы пробовать.

     

  5. Опубликовано · Пожаловаться

    Разве есть выход из STOP по RTC alarm? Судя по RM0041 (таблица 11), выход из STOP только по прерыванию/событию от EXTI.

    Правильно - выход по EXTI. Если посмотрите на трассировку входов EXTI, то увидите что EXTI17 подключена именно к RTC ALARM и генерируется по вектору "position 41 at 0x000000E4". А вот секундное прерывание RTC к EXTI не подключено и поэтому по ALARM выходить из стопа можно, а по секундному - нет.

     

    Кроме того, я не понял, при чём тут LSE (32768), когда

    ИМХО, тут есть два разных тактовых домена - один это тактирование прескайлера и счетчика времени - туда же подвязаны регистры компаратора аларма, и второй домен - это PCLK - тактирование схем доступа с регистрам RTC со стороны периферийной шины. Вот и введена специальная схема синхронизации и настройки регистров. И длится эта настройка, в лучшем случае, два такта частоты тактирования регистров времени, а не PCLK. А тактирование регистров времени осуществляется от LSE (часовой кварц там висит) - с периодом порядка 30мкс. Вот и получается, что работая на 8MГц HSI надо все равно ждать 60мкс, пока регистры аларма синхронизируются и настроятся.

     

    Это я что-то не так прочитал, или вы открыли недокументированные возможности? (Мне бы просыпание из STOP по аларму RTC очччень бы пригодилось!)

    Все с алармом получилось, просыпается каждую секунду, проц жрет в сумме около 30мкА - но у меня там еще АЦП активизируется/калибруется каждый просып. Так что - нет никаких реальных препятствий (индийская документация, конечно, не фонтан, но ведь у нас форум есть :)) к выходу из стопа по аларму.

  7. Опубликовано · Пожаловаться

    Не знаю как у 1766, а LPC1768 АЦП работает без нареканий, думаю, что проблемы могут быть в софте. Возможно, у вас неправильное преобразование знакового числа.

    "Здоровых нет - есть недообследованные" ©.

    Рассказали бы что ли - в каком режиме АЦП работает, сколько каналов, какие настройки, кусочком кода поделились с народом. А то у меня на одной и той же физически плате, и с 99% одинакового С-кода, LPC2368 работает, а вот LPC1768 необъяснимые нули при измерении VBUS_USB (делитель 22k/22k) выкидывает изредка, причем только если по USB активный обмен идет. Цепляешь эту цепь VBUS на соседний канал, который спокойно до этого мониторил термодатчик - и он тоже начинает нули кидать. Помех 300МГц осциллоскопом не видно, даже триггер не срабатывает, 1000пФ стоит прямо у ноги. Как программно в DR ADC сформировать 0 - неясно ни разу, регистр же только на чтение. Физически нуля у меня там быть не может, поэтому фильтруется это дело "на раз" и на изделие не влияет, но загадка есть, однако. А я загадки не люблю.

    P.S. Кстати, надо будет еще помониторить на предмет 0xFFF, а то у меня только нижний предел проверялся.

  9. Опубликовано · Пожаловаться

    Не подойдет ли пробуждение мк от сторожевого таймера?

    IWDG пробуждение не поддерживает - только сброс, что не очень хорошо, так как хочется состояние программы и внешних портов сохранять таки. А WWDG он тактируется от PCLK1, значит все время PCLK1 должно быть активно. И уже реализован вариант на RTC_ALARM. Но все равно - спасибо за идею!

     

    Контроллеры Kinetis от Freescale пробовали? Рекомендую, STM и NXP курят в стороне. Kinetis и по цене дешевле, характеристики и функционал впечатляет.

    Да, кинетиксы впечатляют, но, по моей информации, в младших/средних моделях они не дешевле. По цене К30/40 против STM32F100 не играют.

     

  10. Опубликовано · Пожаловаться

    Есть же #ifdef

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

    1. Убирание "& 0xFF" ситуацию не исправляет - компилируется с той же ошибкой, глючит именно на unsigned char.

    2. #ifdef не поможет скомпилировать желаемое для выражений подразумевающих что макрос bx_l() имеет тип unsigned char. То есть - эти выражения все надо будет патчить в куче мест, вставляя явное приведение типа (которое Вы предлагаете выбросить из макроса). Пример - код типа: "unsigned char var1 = b0_l((unsigned long)var2);" даст предупреждение.

     

  11. Опубликовано · Пожаловаться

    Позавчера убил почти целый день - ловил место где изредка (непостоянно, в слабой зависимости от фазы луны) возникал Hard Fault. Сначала подматюкивал новый для меня STM32, но потом ситуация стала интересной. Есть такой код:

                    thumb
               public  hal_eoi_jump

hal_eoi_jump:   cpsid   I
               ldr     R1, =sfe(HANDLER_STACK) 
               msr     MSP, R1
               mrs     R1, PSP
               orr     R0, R0, #1
               str     R0, [R1, #lpc_ctx_PC]
               str     R0, [R1, #lpc_ctx_LR]
               mov     R0, #(1<<24)
               str     R0, [R1, #lpc_ctx_PSR]
               ldr     LR, =0xFFFFFFFD
               bx      LR

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

    Этот код около года беспроблемно работал на LPC17, а вот на STM32 изредка вываливал Hard Fault, причем на инструкции куда осуществлялся возврат - точка входа режима приложения. Оказалось что из-за особенностей реализации софта на STM32 эта функция иногда вызывалась из вложенного обработчика прерываний - и сразу за bx LR следовало HF. Если вызов был не из вложенного обработчика - то все было OK. Я попробовал вызвать функцию из вложенного обработчика на LPC17 - и тоже получился Hard Fault. В-общем, имхо, ядро Кортекс считает уровни вложений - хотя странно, из документации этого не следует и вроде бы для реализации предлагаемой Кортексом схемы прерываний это не нужно.

  12. Опубликовано · Пожаловаться

    Да - в оптимизации явно глюк!

    Возможно связан с тем что в макросе лишняя операция :

    & 0xff

    и

    (unsigned char) преобразование типа к байту

     

    можно оставить что то одно!

    Да, если убрать преобразование типа (unsigned char) в макросах, то именно это место компилируется правильно. Беда в том, что этим макросам лет 20, и страшно представить сколько кода на данный момент на них основано - для 8-битных AVR, 16-битных x86 и для 32-битных ARM. Поэтому поменять макросы малореально.

     

  13. Опубликовано · Пожаловаться

    Попробовал IAR 6.30.1 для Cortex-M3, нарисовалась проблема.

    Есть такой код:

    #define	b0_l(L)	((unsigned char)((L)       & 0xFF))
#define	b1_l(L)	((unsigned char)(((L)>>8)  & 0xFF))
#define	b2_l(L)	((unsigned char)(((L)>>16) & 0xFF))
#define	b3_l(L)	((unsigned char)(((L)>>24) & 0xFF))

unsigned long IsDate(unsigned long d)
{
 if (  (b0_l(d)<1)  || (b0_l(d)>31)
    || (b1_l(d)<1)	|| (b1_l(d)>12)
    || (b2_l(d)>21)	|| (b3_l(d)!=0))
 {
   return 0;
 }
 if (d == 0x101)
 {
   return 0;
 }
 return 1;
}

    Функция просто предварительно проверяет значение даты, упакованной в unsigned long.

    При наличии ключей оптимизации -Om (или -Ohz, другую не пробовал) превращается в такое:

       \                                 In section .text, align 2, keep-with-next
    49          unsigned long IsDate(unsigned long d)
    50          {
    51          	if	(  (b0_l(d)<1)  || (b0_l(d)>31)
    52          		|| (b1_l(d)<1)	|| (b1_l(d)>12)
    53          		|| (b2_l(d)>21)	|| (b3_l(d)!=0))
  \                     IsDate:
  \   00000000   0x1E41             SUBS     R1,R0,#+1
  \   00000002   0x291F             CMP      R1,#+31
  \   00000004   0xBF3E             ITTT     CC 
  \   00000006   0x0A01             LSRCC    R1,R0,#+8
  \   00000008   0x1E49             SUBCC    R1,R1,#+1
  \   0000000A   0x290C             CMPCC    R1,#+12
  \   0000000C   0xBF3E             ITTT     CC 
  \   0000000E   0x0C01             LSRCC    R1,R0,#+16
  \   00000010   0xB2C9             UXTBCC   R1,R1
  \   00000012   0x2916             CMPCC    R1,#+22
  \   00000014   0xD205             BCS.N    ??IsDate_0
  \   00000016   0x0E01             LSRS     R1,R0,#+24
  \   00000018   0xD103             BNE.N    ??IsDate_0
    54          	{
    55          		return 0;
    56          	}
    57          	if (d == 0x101)
  \   0000001A   0xF240 0x1101      MOVW     R1,#+257
  \   0000001E   0x4288             CMP      R0,R1
  \   00000020   0xD101             BNE.N    ??IsDate_1
    58          	{
    59          		return 0;
  \                     ??IsDate_0:
  \   00000022   0x2000             MOVS     R0,#+0
  \   00000024   0x4770             BX       LR
    60          	}
    61          	return 1;
  \                     ??IsDate_1:
  \   00000026   0x2001             MOVS     R0,#+1
  \   00000028   0x4770             BX       LR               ;; return
    62          }

     

    И не работает правильно.

    На версии 5.41 компилируется в рабочий код. Вопрос такой - это я C плоховато знаю или таки глюк компилятора?

    upd: привел пример к стандартным типам (убрал typedef свои), чтобы не путались

  14. Опубликовано · Пожаловаться

    Сейчас разбираюсь с Low-Power Modes у STM32F100. Мне надо чтобы устройство спало все время в Stop Mode, просыпалось раз в секунду от RTC, выполняло ряд несложных проверок и снова засыпало. Обнаружены такие факты:

     

    - для пробуждения надо дополнительно шаманить с контроллером внешних прерываний EXTI

    - выход из Stop Mode по события от RTC _ТОЛЬКО_ по прерыванию/событию ALARM - то есть секундное событие не пробуждает

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

    - настраиваются эти регистры несколько тактов LSE (32768) - то есть относительно долго, и проц все это время в Run Mode , то есть жрет энергию

     

    Таким образом, обычная тонзилэктомия на STM32 превращается в сложную проктологическую операцию.

     

    P.S. ИМХО, библиотечка от ST содержит ошибку в RTC_GetCounter() - что будет если 32-битный RT-счетчик тикнет между моментами считывания его 16-разрядных половинок и будет перенос в его старшие 16 разрядов?

     

     

  15. Опубликовано · Пожаловаться

    хмм, собирался на "супердешевые" киты с STM32 поглядеть... и призадумался, однако не погонюсь за журавлем в небе а да приступлю к киту на LPC2368 тем более, что он на столе %-). Возможно UART c DMA одновременно мне и не понадобится но MAC ethernet и/или USB с наличием встроенного DAC, как раз подойдут.

    А вот Ethernet MAC, судя по документации, у STM32 лучше чем у LPC17 (скорее он ближе по возможностям к новому EMAC LPC18) - он сам может IP/TCP/UDP суммы считать, но практического опыта с EMAC STM32 у меня пока нету. А из LPC лучше уже смотреть на LPC17 - как более новые архитектурно, менее жрущие и более быстрые, мне 17-ые нравятся намного больше чем 21/23/24-ые. По ножкам на 99.9% совместимы с LPC23 - есть вероятность, что можно просто чип в ките заменить, если будет такое желание.

     

  16. Опубликовано · Пожаловаться

    Очередные 5 копеек.

    ИМХО, DMA у STM32F1xx реально убог. Там что, про gather-scattering буферов не слышали? Дескрипторы и цепочки из них, спрашивается, где? Вот же ж, мне сейчас прийдется писать программную эмуляцию. Или я чего-то таки недопонял в "индийском" документе?

     

  17. Опубликовано · Пожаловаться

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

    Даташит не поможет. Тут "Reference Manual" читать нужно, качество сего документа - так себе, "индийское".

    И я всегда конструкторам давал некоторую свободу - вот мне нужен SPI, берите любой из имеющихся, тасуйте ножки исходя из топологии конкретной платы. Соответственно программные модули написаны так что работают с любым аналогичным блоком. И LPC тут позволял не особо задумываться - все блоки равноценны. А теперь надо вот для STM выполнять перекрестный анализ. Причем убогость архитектуры просто необъяснима - кто мешал ST матрицу/мультиплексор запросов DMA сделать? А OR всех запросов от источников - это сказка просто, биты управления получаются размазаны по нескольким периферийным модулям. Да у меня еще и тактирование модулей отключается - код шерстения этих всех регистров просто тупо раздувается.

     

  18. Опубликовано · Пожаловаться

    Добавлю еще 5 копеек - у STM очень странный роутинг запросов на DMA - каждый канал жестко привязан к своему набору периферии. И получается что каналов-то DMA много - аж 12, но например SPI1 и UART3 одновременно использовать DMA не могут, такой вот туповатый дизайн.

     

  19. Опубликовано · Пожаловаться

    Разрабатываем новое устройство, в котором необходим Ethernet. Устройство основано на LPC2366. Сейчас выбираю PHY.

    Пока остановился на двух вариантах:

    KSZ8031 - новый, с кучей фич, маложрущий, малоногий, сам генерирует 50Мгц для RMII.

     

  20. Опубликовано · Пожаловаться

    Так.

     

    непонятно. от LSI все пашит, а от HSE/128 нет. просто не питается. кто знает что не так?

    У меня сейчас вообще прикол получился. Я в своем коде, который отлажен на LSE, решил попробовать тактирование HSE/128. Так вот - битики SELECT_HSE в RCC_BDCR чудненько записались. И все - часики не тактируются, стоят. Вернулся на LSE и оказалось невозможно откатить битики выбора тактирования RTC в RCC_BDCR - они после аппаратного сброса оставались в HSE/128, код записи-настройки RCC_BDCR тоже отказался работать. Помогло только полное отключение питания, включая резервную батарейку. ИМХО, где-то тактовый сигнал при HSE/128 не доходит, при этом также смена настройки не происходит.

     

     

  21. Опубликовано · Пожаловаться

    Работали с SAM7S/SE/X, LPC21/23/17, сейчас делаем проект на STM32F1xx,есть такие замечания:

    - 16-битные таймеры (у LPC17 - 32-битные, используются в программах)

    - 17 штук разных таймеров, в разных моделях, 6 разных подтипов ("тут играть, тут не играть, тут рыбу заворачивали (с)")

    - разбитая на кусочки область хранения данных под батарейкой (два набора 16-битных backup регистров "несплошняком")

    - два разных контроллера USB в семействе

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

    - "сваренная из топора" периферийная библиотека, к тому же не всегда полезная даже как пример

    - нет документации по замещению встроенного заводского загрузчика

    - мутное описание ремапиннга пинов между периферийными блоками

    А так - само по себе семейство STM32 неплохое, основные претензии у меня пока к документации.

     

  22. Опубликовано · Пожаловаться

    Хорошо объяснено... Только метрикой меряться некому, поскольку основной шлюз в данном случае определён только один и он как раз в той части сети, где и роутер, через который выход в интернет.Так что, пакет "не туда" уйти не должен.

    Да, у топикстартера шлюз назначен только на одном интерфейсе. Но - интерфейсы-то назначены в общую подсеть, а физически не соединены. Видимо Windows и путает адаптеры - с точки зрения маршрутизации ведь нет никакой разницы по какому адаптеру отправить на IP шлюза. Не знаю поможет ли в таком случае метрика интерфейса. Возможно что и поможет (Инету, а вот устройство будет недоступно :)), но смысла пробовать нет - надо настройки сети приводить к соответствию физической картине.

    Я на эти все грабли уже наступал - и одну подсеть физически разбивал, в итоге, ессно, пришел к разным подсетям. Потом понадобился умный свич с port-mirroring - чтобы смотреть как девайсы между собой общаются, а не только с компом. Потом добавил еще одну сетевую карту (с третьей подсеткой) под мониторящий порт. Инет пару дней поработал и пропал. Гы, даже провайдеру звонил, пока про метрику на третьей карте не вспомнил :).

     

    В Win шлюз по умолчанию на самом деле все равно один.

    http://support.microsoft.com/kb/159168

    http://support.microsoft.com/kb/157025

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

  23. Опубликовано · Пожаловаться

    Так почему не работало?

    Потому что не могло оно правильно отмаршрутизировать на IP уровне.

    Выдаете например ping <IP-google> (зададим IP явно, чтобы не вникать в детали DNS и тд).

    Утилита ping должна отправить на указанный IP-адрес ICMP пакет echo.

    Тут вступают правила маршрутизации IP, в разных ОС детали могут отличаться, но суть примерно такая:

    - сначала IP получателя ищется в явном виде в таблице маршрутизации, если найден, то пакет будет отправлен по указанному в записи таблице интерфейсу (грубо - по указанному адаптеру ЛВС). Обычно IP адреса гугля в этой таблице нет, это не наш случай

    - затем ищется среди локальных интерфейсов подсеть содержащая нужный IP, это тоже не наш случай - разве что Вы работаете админом в гугле и его сервера в вашей локальной подсетке :)

    - если ничего явно не найдено, то пакет отправляется в путь по умолчанию - дежурному маршрутизатору или шлюзу. Это наш случай, пакет надо отправить именно на шлюз (Default Gateway)

    Этот шлюз обычно находится в локальной подсетке и ОС пытается отправить исходящий пакет на него. И тут - опа, ОС находит два интерфейса, смотрящих в одну и ту же подсетку. Кстати, подсетки могут быть разными, и в обоих может быть свой шлюз. Ситуация в этом случае сильно не отличается - ОС все равно надо выбрать куда отправляить пакет. И вот когда оно у Вас не работает - это значит что пакет (ping ICMP-echо) ушел не в тот интерфейс - в подсетку где реально нету шлюза или он не подключен в Инет (где обретаются сервера гугля).

    В этом случае надо помочь ОС сделать правильный выбор - чтобы она отдавала предпочтение нужному интерфейсу. Вот для этого служит специальная характеристика интерфейса (также может назначаться шлюзу), называемая метрикой. В Windows это закопано в свойствах сетевого адаптера->Internet Protocol (TCP/IP)->Properties->Advanced. Чем больше значение метрики - тем менее охотно Windows будет выбирать указанный шлюз/интерфейс по умолчанию. Итого - делаете две разные подсетки (разные значения маскированной части IP) и отладочной подсетке ставите метрику побольше. На обращение к отладочной плате метрика не повлияет - Вы будет обращаться по локальному IP. А вот в Инет оно будет лезть по нормальному интерфейсу с маленькой метрикой.

     

  24. Опубликовано · Пожаловаться

    О блин, плохо дело с портом на SAM7. Это придется все структуры в невыровненном режиме хранить.

    Можно хранить и в выравненном - для SAM7X можно задать начальное смещение по приему - например в 2 байта и все будет OK.

    Upd: судя по моим исходникам - в EMAC_NCFGR - поле RBOF (блин, смотрю на свои тексты как баран - давно дело было)

     

  25. Опубликовано · Пожаловаться

    Кстати, еще раз о FR. Вообще-то в линухах он вполне адекватно работает. А можете лог wireshark'а от такой сессии состряпать?

    Могу, но чуть позже - той платы под рукой нету. И оно большое - там гигабитный поток на пару секунд - под гигабайт лог, и, надо сказать, не очень адекватный, через Port-Mirroring (потому как прямой линк девайс-NAS - нету компа между ними) снималось - он немного пакеты тасует. Но факт такой - если его исходящий пакет пропадает, то невзирая на толпу ответных обычных ACK-ов с одинаковым ACKNO этот NAS сначала шлет все мегабайты что у него попросили по искази, а потом еще и виснет на 200мс с тайм-аутом. В итоге в потоке имеем простои под 200мс - неприятно. Вопрос открытый , все руки не доходят - работа с этим NAS-ом редкий случай, а с Windows оно нормально общается. Надо сказать, что QNAP все исходники выложил, и техподдержка нормальноая - если что, можно и их попинать.

     

×
×
  • Создать...