afad

Да, с внешним коммутатором должно получиться. Не хотелось ставить дополнительные элементы, но, придется. Будем пробовать. Если не дергать SHP и(или) SHD, то АЦП не работает, на выходе код не меняется.

Кто-нибудь знает, возможно ли использовать ADC, предназначенный для оцифровки сигналов с CCD матрицы, использовать как "обычный" АЦП для оцифровки непрерывного сигнала? Проблема в том, что данный АЦП измеряет сигнал данных относительно некоторого референсного уровня, для чего в АЦП подаются 2 сдвинутых друг относительно друга тактовых сигнала. По фронту одного сигнала (CHP) фиксируется референсный уровень, а по фронту второго (CHD) фиксируется уровень сигнала данных относительно референсного уровня. Попытки как-то исключить фиксацию референсного уровня пока не дали результата. Кто-нибудь пытался использовать данный АЦП как "обычный"?

Проблема решена. WDT при инициализации находился в Power Down. Сбросил бит и все заработало.

LPC1313 не заводится противосбойный таймер. Вроде все правильно инициализирую. void WDTInit(void) //Инициализация WDT {LPC_WDT->TC = 500000; //Once WDEN is set, the WDT will start after feeding LPC_WDT->MOD = 0x03; //WDEN+WDRESET LPC_SYSCON->WDTCLKSEL = 0x00; //Источник - Int-RC // LPC_SYSCON->WDTCLKSEL = 0x01; //Источник - main-clk (и так не работает) // LPC_SYSCON->WDTCLKSEL = 0x02; //Источник - WDT-RC (и так тоже не работает) LPC_SYSCON->WDTCLKUEN = 0x0001; //Установить источник клока LPC_WDT->FEED = 0xAA; LPC_WDT->FEED = 0x55; } После этого читаю счетчик (L=LPC_WDT->TV;), показывает значение 0х000000FF (значение по умолчанию), значит счетчик не записывается и не тикает. То же самое делал для LPC1768 - все работало, в чем проблема - не понимаю. PS. И в LPC1343 тоже WDT не включается. Значит дело не в микросхеме, а в программе.

Вопрос снят. В файле системной инициализации для частоты 100 MHz (был готовый файл) были выключены UART2 и UART3 (соответствующие биты в регистре PCONP были =0). Установил правильно PCONP и все заработало.

Есть плата с LPC1769, максимальная частота ядра для этого микроконтроллера - 120 MHz. Работал при частоте 72 MHz, все работало отлично. Увеличил частоту ядра до 100 MHz и стал виснуть. Выяснено, что виснет при попытке работать с UART2 и UART3. Причем виснет на этапе инициализации регистров этих UART-ов. Т.е., например, записываем: UART3->IER = 0x00; и все повисло. При этом, если работаем с UART0 и UART1 - нет проблем. Понизить частоту клока указанных UART-ов (задается в регистре PCLKSEL1) не привело ни к чему, по прежнему виснет. Вот и непонятно, чем UART2 и UART3 отличаются от UART0 и UART1. И как работать с UART2 и UART3 при частоте ядра 100 MHz?

Делал для LPC1768, работающего на частоте 100 МГц, без особых ухищрений на С получилось записывать 4 Мегаслова в сек (чтение элемента массива из памяти и запись его в gpio, формирование импульса WR, инкремент указателя массива, и так по циклу). Возможно можно как-то оптимизировать, или написать на асме, вероятно можно увеличить скорость в несколько раз, но мне не нужно было, поэтому не заморачивался.

Да, идея интересная: http://www.microtransat.org И вот еще: http://www.popmech.ru/article/3632-ro-47-botiki/

Да, получилось, спасибо!

Собственно в этом и вопрос, на выходе Quartus получается .pof или .sof файл, для заливки программатором. А я хочу .hex формат, чтобы заливать в FPGA из микроконтроллера. Есть такие установки (Assembler setting): "Generate Hexadecimal (Intel-Format) Output File (.hexout) for Target Device - Off" А как включить "ON", непонятно, вроде все перерыл, нигде не включается. Или плохо искал??? MAX по умолчанию генерил .hex-файл вместе с .pof, а QUARTUS не хочет.

Попробуйте попробовать прочитать по адресу 0x00 число, должно быть 0x01, что означает, что микросхема фирмы Spansion. Не записываться может по причине того, что блоки памяти залочены, нужно сделать unlock. Я так думаю. Сейчас под рукой нет такой микросхемы, проверить не могу.

Нужен программатор PIC18F14K50, попроще, что-то типа ПониПрог. Нужно разово записать готовую программку. Поискал в интернете, вариантов много, есть простые, программируют через LPT, но именно эту микросхему не прошивают. Может кто видел?

Время - да хоть из какого. Но в RMC еще есть дата и признак достоверности данных. Вот пример расшифровки пакета, правда для другого модуля: $GPRMC,133147.000,V,5647.7429,N,03416.6492,E,,,190908,,*14 $GPRMC – заголовок 133147.000 – 13:31:47 – время. V – данные не достоверны (A – данные достоверны). ... 190908 – 19.09.08 – дата. 14 – контрольная сумма. Или пример пакета, когда данные достоверны: $GPRMC,133910.000,A,5647.7429,N,03416.6492,E,000.0,212.7,190908,009.6,E*65 А разве поправку можно ввести? А я по незнанию на микроконтроллере пересчитывал :-(

Докопался, можно указать 64-битный адрес 0х00000000, тогда передача будет по 16-битному адресу. Но вот что непонятно. Когда одно конечное устройство - все работает отлично (передача происходит раз в полминуты, остальное время конечное устройство спит). Включаю второе устройство, одно из устройств (может быть любое) работает нормально, от второго сообщение может приходить примерно 1 раз из 5-10. Вероятность одновременной передачи сообщений минимальна. Причем это происходит, если конечные устройства на некотором удалении от координатора, когда близко - такого нет. В чем может быть проблема???

Аналогичная задача. Делал широковещательную передачу, когда одно конечное устройство - работает, при включении нескольких конечных устройств некоторые посылки теряются. Сделал передачу конкретному координатору (с указанием 64-битного адреса), с подтверждением ACK - вроде заработало. Использовал пакет API 0x10, но там задается 64-битный адрес координатора (я так понял - это серийный номер, который нельзя изменить) и 16-битный адрес. Но допустим координатор сломался, его заменили (вместе с модулем), соответственно 64-битный номер сменился, и что, перешивать все конечные точки? Или как-то можно сделать НЕ широковещательную передачу (с подтверждением ACK) используя только 16-битный адрес??? В команде API 0x10 нужно указывать и 64-битный адрес и 16-битный, вот в чем проблема. В продолжение темы. Хм... Указываю 64-битный адрес 0x00000000 - сообщение приходит к координатору. Указываю 16-битный адрес не 0х0000 (у координатора всегда 0x0000, я так понял) - сообщение тоже приходит к координатору. Не понятно - это широковещательная передача или нет?