juvf

ааа...... shortcut! стормозил (( Спасибо!

а от куда вы узнали про v-e? Нажал V - Выскочило контекстное меню. Нет там команды с горячей клавишей E. Пришлось перечитывать всю тему за 2013 год, чтоб найти V-E. Тоже касается и V-B. Где можно получить список горячих клавиш?

а при чём тут scmRTOS?

Вам сюда мне хватало сделать контроль переполнения памяти..... определял функцию vApplicationStackOverflowHook, в которой отмигивал лампочкой номер задачи. Очень мощно помогает эклипсовый плуг StateViewer. Всё можно. См. по тойже ссылке Список макросов трассировки.

нужно написать GUI программу с возможностью программирования Cyclon-a под Windows. Есть идея запустить Altera Nios2 Command Shell и вызвать в нем батник с командами конвертирования, прошивки, проверки и т.п. Захватить вывод, проанализировать его и показать пользователю результат работы. Как из программы можно сделать вызов Command Shell, передать туда команду, выполнить её и захватить вывод команды? ну или что почитать? где копать?

Да, спасибо! То, что нужно.

Eсть Cyclon III + EPCS. Как прочитать прошивку из EPCS? Есть команда чтение элфа, nios-elf-readelf, но она читает только эльф. А как прочитать ещё и конфигурацию, sof, pof, а лучше сразу jic?

Недавно тоже писал отладчик прерывания EXTI0 и EXTI1. А почему такой сброс флага PR? если в обработчике нужно сбросить ВСЕ прерывания по EXTI, то можно EXTI->PR = EXTI->PR; а если нужно сбросить ТОЛЬКО прерывание EXTI0, то нужно EXTI->PR = 0x01; Иначе вы рискуете потерять одно прерывание. Допустим пришло 2 прерывания, 1 и 0. PR стал равен 0х03. В сбрасываете регистр PR, кодом EXTI->PR|=0x01;. эквивалент этого кода EXTI->PR = EXTI->PR | 0x01; или EXTI->PR = 0х03 | 0x01; т.е. произойдёт сброс битов 0 и 1. а код "0х03 | 0x01" даст 0х03, поэтому операция "|" бессмысленна. Или я что-то не понимаю?

//Sensor.h class Sensor { public: Sensor(); virtual ~Sensor() = 0; virtual bool isValid() const = 0; }; //Sensor.cpp #include "Sensor.h" Sensor::Sensor(){} //SensorFreq.h #include "Sensor.h" class SensorFreq : public Sensor { public: SensorFreq(); ~SensorFreq(); virtual bool isValid() const; }; //SensorFreq.cpp #include "SensorFreq.h" SensorFreq::SensorFreq() : Sensor() { } SensorFreq::~SensorFreq() { } bool SensorFreq::isValid() const { return true; } ну и main //main.cpp #include "Sensor.h" #include "SensorFreq.h" int main() { SensorFreq asd; while(1) { //какойта код } } ps вывод компилятора из реального кода, там посложнее, но сделал тестовый, как выше - тоже самое, не может создать объект класса SensorFreq, т.к. не перегружена функция isValid().

Сделал абстрактный класс Sensor в котором есть пара чисто виртуальных функций. В отнаследованном класе переопределил эти виртуальные функции. Линкер пишет Error[Pe604]: array of abstract class "SensorFreq" is not allowed: D:\juvf\work\led\ledIar\Pwm.h 16 pure virtual function "Sensor::isValid" has no overrider pure virtual function "Sensor::getLiters" has no overrider overrider Не может линкер связать 2-х слов найти определяния перегруженных функций. Почему? Может какую галку в IAR нужно снять/выставить?

У нас официальный АД9 саммер. Пришло официальное предложение обновиться до АД13 по СПЕЦИАЛЬНОЙ цене, действующей ТОЛЬКО ДО 31 марта 2013. Ну и обзор что мы будем с этого иметь: что-то про шрифты гостовскуие.... редактирование пинов прямо в схеме.... в АД 9 в 3Д режиме автоматически можно повернуть плату "Вид сверху" и "Вид снизу", остальные виды руками крутить. В 13-ом добавили ещё виды справа, слева,..... уже вооружился обновится, как увидел цены.... СПЕЦИАЛЬНОЕ ПРЕДЛОЖЕНИЕ для владельцев АД9 обновление до АД13 будет стоить ВСЕГО лишь 119000 рублей, ЭКОНОМИЯ при этом 13000. И за что 100 т.р. отдавать? чтобы вид спереди в 3Д можно будет не руками выставить, а одной кнопкой? И все подобные нововведения-фичи из разряда "рюшечки и оборочки". (((

не нужно ни когда использовать int, short, long и т.п., по крайней мере когда пишешь для мк. Нужно использовать типы из <stdint.h>, такие как uint8_t, int16_t, int32_t. Будет тогда идентичный результат вычислений. тогда даже избежишь проблем при запуске программ написанных для win32 собранных(запущенных) в win64 ps Даже с чаром проблемы. хоть чар он и в африке 8 бит. но я обычно использую char = signed char. Но, например в иар, по умолчанию стоит галка, что чар есть беззнаковый.

Не могу автоматически измерить параметры ШИМ. Подключены 2 канала (2 провода) к 2-ум пинам процессора, к TIM3_ch3 и к TIM3_ch4. На них поступает ШИМ. Решил для начала померить ШИМ в канале 3. Код //настроим порты входа GPIOB_CRL_bit.MODE0 = 0;//Вход GPIOB_CRL_bit.CNF0 = 1; GPIOB_CRL_bit.MODE1 = 0;//Вход GPIOB_CRL_bit.CNF1 = 1; RCC_APB1ENR_bit.TIM3EN = 1; // подадим клоки TIM3_PSC = 552; TIM3_ARR = 0x7fff; TIM3_CCMR2_bit.IC3S = 1;//подадим на IC3 сигнал с входа TI3 (Tim3_CH3) TIM3_CCER_bit.CC3P = 0;// захват по нарастающему фронту TIM3_CCMR2_bit.IC4S = 2;//подадим на IC4 сигнал с входа TI3 (Tim3_CH3) TIM3_CCER_bit.CC4P = 1;// захват по спадающиму фронту TIM3_SMCR_bit.TS = 0x5;// триггер Filtered Timer Input 1 (TI1FP1) TIM3_SMCR_bit.SMS = 0x4; //Reset mode TIM3_CCER_bit.CC3E = 1; TIM3_CCER_bit.CC4E = 1; TIM3_CR1_bit.CEN = 1; Нету захвата. В даташите схема таймера. Тригер может быть запущен только с IC1 и IC2. Но судя по схеме, вроде есть возможность канал TI3 перенаправить в TI1 чтобы получить TI1F_ED или TI1FP1. Не могу понять, для этого нужно ещё какие-то биты прописывать? или TI3 по умолчанию прицеплен к TI1 через XOR? ps Ну и если 2-ой ШИМ физически подан на ногу TIM3_CH4. Я так понял что автоматическое измерение праметров ШИМ не получится с это ноги?

Добавил в систему ваш ftdi. Собрал BSP. В проекте Ниоса (в Eclipse) нету ftdi_uart_regs.h, не добавляется он в проект при компиляции. Как вы эту проблему решаете? Руками в проект добавить этот ашник?

если назначить stdout как jtag_uart, то printf работает нормально, шлёт в терминал ниоса "hello world!". Добавил в NIOS UART. Переназначил в BSP ediotr-e stdout на мой уарт. printf перестал работать. Тишина на уарте. Почему printf не работает с не jtag-uart-ом?

Да речь не от том. Андроид на ядре Линукс. Это факт. И что там пятое колесо у телеги и андроиду на линукс фиолетово - это заблужение.

+1

Вводная: Нужно, допустим раз в секунду, оцифровать входные сигналы с 3-х каналов АЦП. Вроде как инжективная группа тут поинтереснее, т.к. есть 4 независимых регистра результата конвертирования. Накидал инит пока для одного канала, для пробы. Пока буду руками запускать преобразование. void initADC() { //Настройка портов. Такты уже разрешены на порт А. Тактирование альтернативных функций разрешено GPIOA_CRL_bit.MODE0 = 0; // Analog mode GPIOA_CRL_bit.CNF0 = 0; // Input mode //Настройка АЦП RCC_APB2ENR_bit.ADC1EN = 1; //Разрешаем тактирование АЦП ADC1_CR1 = 0; ADC1_CR2 = 0; ADC1_JSQR_bit.JL = 0; //последовательно 1 преобразование ADC1_JSQR_bit.JSQ1 = 0; // PA0/ADC0 ADC1_SMPR2_bit.SMP0 = 0x7; ADC1_CR2_bit.JEXTSEL = 7; // ручной старт инжективной группы ADC1_CR2_bit.ADON = 1; //Включаем АЦП //каллибровка ADC1_CR2_bit.RSTCAL = 1; while(ADC1_CR2_bit.RSTCAL == 1); ADC1_CR2_bit.CAL = 1; while( ADC1_CR2_bit.CAL == 1 ); } После инита в рабочем коде делаю ручной старт командой ADC1_CR2_bit.JSWSTART = 1; Конвертирования не происходит. ещё раз .... ещё..... :smile3046: Опять наверно где-то скрытый битик забыл..... перерыл даташит - всё вроде правильно. Случайно сделал команду ADC1_CR2_bit.JSWSTART = 0; И О ЧУДО!!! Запустилось преобразование.... правда в регулярной группе и результат лёг в ADC1_DR. Ну хоть результат похож на правду. Сделал ход канём, добавил в инит ADC1_CR1_bit.JAUTO = 1; //автостарт инжективоной группы, после регулярной И получил то что хотел. Т.е. делаю старт регулярной группы путём записи 0 в JSWSTART, после регулярной запускается инжективная. Почему так? Где-то я бит пропустил или камень попался неисправный? В ератах вроде нету такой баги. ps smt32f100c8t6

Неее.... Ну говорю же первый опыт, первое знакомство с хиперлинксом. Хиперлинкс - вообще отдельная планета. Реальную плату не моделировали. Моделировали даже не схему а отдельную цепь. Нарисовали цепь: Источник-резисторДорожка-виа-резисторДорожка-виа-терминатор+приемник. Ну какбы подрозумевал что на время передачи терминатор подключится. :laughing: Видать она у нас на опытных образцах и заработала, причем вроде из 7-ми плат на одной так и не пошла ддр - списали на непропай бга. А в серии на каждой 2-ой не пошла. В серию платы заказывали в др канторе, стек изменили, чуть тоньше платы получились. Ну допустим нету в CycloneIII ODT и нужно ножку на микросхеме ODT затянуть в "1" (или в "0"). В прикреплении Э3 демокита . В схеме ODT идет на порт Cyclon-a, но если там нет одт - достаточно же ногу памяти подтянуть на "1" и не мучится с трассировкой этой цепи, тем более она идет на две мк.сх., да ещё с терминацией, да ещё с выравниванием. в SOPSбилдере указывается для какой ПЛИС будет собираться НИОС. Билдер собрал контроллер с ногой ODT. Даже не было тени сомнения, что ОДТ нету. ps Всетаки, а почему в ките ODT от памяти завели на циклон? c3_f780_host.pdf

))) Ага, потайная компата. *ЗАПЕСАЛ* Спасибо. Проблема решена А если обе переферии включены?

Не могу ШИМ выдать на порт. Использую ТМ1 канал 4 (PA11) //настроим порт PA11 RCC_APB2ENR_bit.IOPAEN = 1; // Разрешить тактирование PORTA RCC_APB2ENR_bit.AFIOEN = 1; // Тактирование альтернативных функций GPIO. GPIOA_CRH_bit.MODE11 = 2; // Output mode, max speed 2 MHz. GPIOA_CRH_bit.CNF11 = 2; //Alternate function output Push-pull //настроим таймер ТМ1 для генерации шим сигнала RCC_APB2ENR_bit.TIM1EN = 1; //включение таймера TIM1_PSC = 22; // 22118400 / 22 период ~ 1 мкс TIM1_CCER_bit.CC4E = 1; //разрешим канал 4 TIM1_CCMR2_bit.OC4M = 6; //110b PWM mode 1 TIM1_CCR4 = 0x8000; TIM1_ARR = 0x9000; TIM1_CR1_bit.CEN = 1; // On TM1 После такой инициализации в дебагере вижу что счетчик таймера считает 0...0х9000. Но на ноге РА11 стоит 0. Почему на РА11 нет ШИМ? ps Порта РА11 имеет две альтернативные функции USART1_CTS / TIM1_CH4. Как сделать чтобы порт был TIM1_CH4? Как сделать чтобы порт был USART1_CTS?

Ну вот не заметили. :laughing: Вообще в нашей канторе это был первый опыт с DDR. И ни кого рядом, кто уже её щюпал. Моделировали так, что на конце линии есть терминация 50 Ом. Т.е. в моделировании не было динамической терминации. просто линиия и на конце терминатор. За основу был взят кит на томже циклоне3, на котором ддр с данными аш в 72 бита (5 микросхем). Мы же упростили сделав 32 бита на 2-х микросхемах. На ките на шине данных не было внешней терминации. Ну не стали изобретать велосипед, доверились киту. Ну целиком плату, да ещё плату с реальной полученной трасировкой, мы не моделировали. Моделировали отдельный цепи до трасировки. А как можно было на этапе моделирования понять, что в циклоне3 нет ODT? Немного доки недокурили по работе ддр и про ODT в циклоне3. :laughing:

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

Это уже религия. )) Ещё раз спрашу: Почему ос+DRAM менее надёжнее чем oc+SRAM или чем чем суперлуп+DRAM? Вам уже др учасники форума объясняют, что ос или суперлуп - в конечном счете одно и тоже. что schedule или что организация многозадачности в суперпуле - это одно и тоже. И ни как не связанно с ОЗУ. Я вас призываю опираться на здравый смысл и научиться думать своей головой. Какие факты? Если бы была бы такая машинная команда, например с мнемоникой "ramJamp a,b;". И всё ртос используют эту команду, но эта команда ненадёжно работает с DRAM, а в суперпуле ни кто эту команду не вызывает - вот это был бы факт. Есть подобные факты? Код ос, например FreeRTOS, присутствует впроекте в виде исходников на си. код задач также написан на си. компилятор собрал исполняемый код. почему он на DRAM будет работать хуже менее надёжно? А то, что ti не поставило в какойто чип контроллер ддр или что нет порта RTOS на чип - это ни чего не значит. В мосгорсуде используют бумагу "снегурочка". Но это не значит что "SvetoCopy" ненадёжна. Позвоните в ti и спросите "Почему нету ддр в таком чипе? Потому что ртос менее надёжна на ддр?" Если они скажут - "да, Применять операционные системы с исполнением из динамического ОЗУ в задачах управления ", ну вот тут будет пища, и то это не будет факт, это будет только мнение ti. Сделайте эксперемент: запилите какойнить девайс.... напишите несколько задач и загрузите задачи вычислениями, пусть ПИ считают, да передают друг другу массивы большие. и запустите сие чудо на DRAM разных типов, например ddr, ddr2, ddr3, ... и при чем разных производителей..... каждых типов по 3-5 производителей. напишите программу с ос и без ос. и потестите. И причем для чистоты эксперемента пусть будет около 3 RTOS ну и 3 неRTOS. ну и потом всё тоже самое, только на статическом озу. - ну вот будет вам детальное исследование и факты. ну из моей практики: около 12 лет крутится ос в системах, где ошибка=человеческая жизнь, круглые сутки на DRAM, в некоторых местах ещё на 386 компе - ни каких сбоев. Ща ртосы внедрил в проекты, тоже в такие системы, где связанно с жизнями - все работает и ни каких сбоев. Вот вам факт.

вывод за уши притянут.