Hello Arcady!
07 Aug 06 12:59, you wrote to Nicolas Minakov:AS> // interrupt service routine variables AS> volatile byte txd = 0; // transmitted data AS> volatile byte rrx = 0; // receveing data Hу и кто же будет реализовывать volatile byte txd[TXSIZE] и volatile byte rrx[RXSIZE]? Будем получать байт, а затем, пока пережевываем предыдущий, будем глухи и немы?
Anatoly
X-Virus-Scanned: amavisd-new at bezeqint.net
Hello, Slav Matveev! You wrote in conference fido7.ru.embedded to Dmitry Orlov on Mon, 07 Aug 2006 17:36:42
+0400:SM>>> Килобайты текстового файла, куда уж более осмысленно?
DO>> Это вообще кошмар. Конфигурирование превращается в написание DO>> программы, которую надо скомпилитровать, найти и понять DO>> ошибки, исправить, опять скомпилировать. Самому следить, DO>> чтобы комментарии соответствовали тексту. Плюс еще нужен DO>> редактор с интерпретаром синтаксиса этого конфига, иначе там DO>> ничего не видно.
SM> для того что бы понять синтаксис вида parameter = value SM> не надо иметь выдающихся умственных способностей.
Надо их иметь чтобы понять что происходит когда написал вместо этого parameter = vaIue (тест на внимательность), чтобы знать, что такой параметр и такое значение вообще существуют.
SM>>> чем удобно? что шаг вправо, шаг влево - побег, прыжок на SM>>> месте - провокация.
DO>> Именно этим.
SM> ну значит у тебя все проекты имели единственный выход: SM> main.exe
Точнее hex. Нет, не единственный и я тоже пользуюсь и make'ом и другими подобными средствами. Я уже много раз объяснял чем удобна IDE. Впрочем и в IDE нет никакой проблемы сделать из одних и тех же сорцов разные проекты с разными результатами.
SM>>> убийственная аргументация. "я этого не знаю, я этого не SM>>> умею, поэтому это - говно".
DO>> Hемного не так. Если для двух вещей одна требует для своего DO>> использования дополнительные знания и умения, причем из DO>> весьма далекой от основной деятельности области, а другая DO>> нет, то первая - говно.
SM> какие именно навыки нужны из далекой области?
Знание входного языка всех этих утилит, шелла, умение их связывать. Куча весьма и весьма грамотного народа понятия не имеет о том что такое cmd.exe, не говоря уж о других шеллах.
SM>>>>> раза <send> строчкой ниже и запустить на выполнение SM>>>>> собраный проект, это нельзя считать "средой SM>>>>> разработки"?
DO>>>> А один раз нажать F9 и для того и для другого не будет DO>>>> удобней?
SM>>> f9 на клавиатуре отсутствовало.
DO>> В 86 году (20 лет назад)? Hу так в утиль ту клавиатуру.
SM> подозреваю что давно сдана. но f9 от этого на ней не SM> появилась.
Появилась на более новой (которая 20 лет назад уже была).
DO>>>> Такая же, как между телевизором и жменей радиодеталей.
SM>>> походу дела "пастернака не читал..." ?
DO>> Причем тут Пастернак?
SM> ты пытаешься с говном мешать вещи, которые видел один раз, SM> издалека, на картинке.
Отнюдь. Не вещи, а подход к ним, который я видел много раз.
dima
X-Virus-Scanned: amavisd-new at bezeqint.net
Hello, Anatoly Mashanov! You wrote in conference fido7.ru.embedded to Arcady Schekochikhin on Mon, 07 Aug 2006 21:16:32 +0400:
AS>> // interrupt service routine variables volatile byte txd = 0; AS>> // transmitted data volatile byte rrx = 0; // receveing AS>> data
AM> Hу и кто же будет реализовывать volatile byte txd[TXSIZE] и volatile AM> byte rrx[RXSIZE]? Будем получать байт, а затем, пока пережевываем AM> предыдущий, будем глухи и немы?
Может ты реализуешь? Или опять найдется сотня отговорок, объясняющих почему языком молоть время и деньги есть, а простую программку написать - нету.
dima
Hello, Dmitry! You wrote to Alexander Torres on Mon, 07 Aug 2006 15:08:42 +0400:
AM>>>>> И в результате получаются чудовищные тормоза, избавиться от AM>>>>> которых DO>>>>
DO>>>> Окстись, какие тормоза? Ты решаемую задачу еще помнишь? Это DO>>>> делается для прежде всего ручного ввода пары чисел. Кому нужна эта DO>>>> скорость? DEO>>> это задача на AN и делать ее надо правильно AT>>
AT>> Ты бредишь, что в общем-то, естественно для новичков в эхе. DEO> ПHХ
Юноша, не хамите. С 2-х недельным сроком пребывания в эхе - это весьма чревато.
AT>> Hо я совершено не понимаю - для чего это делать? Задача оптимизации AT>> этого примера - вторична, а вот первичную - никто не хочет. DEO> первичная пока не решена (ошибки не поправлены)
Наважно. Девайс давно работает. Есть чего показать своего - показывай, нету - упхнись.
With best regards, Alexander Torres. E-mail: snipped-for-privacy@yahoo.com [ Жамству бой !]
Hello, Dmitry! You wrote to Anatoly Mashanov on Mon, 07 Aug 2006 20:52:06 +0400:
DEO> одна работает на 4МГц, DEO> соответственно ее максимальная скорость получается 9600, вторая на DEO> 10МГц, максимальная скорость получается 19200.
DEO> вот и вся разница PIC-AVR :)
Ээээ, когда-то давным давно, я делал девайс на 2-х pic16f84 (таково было желание заказчика, я бы конечно взял другой кристалл), на 4Мгц с RS232C на
9600. Один чип принимал пейджерный сигнал (POCSAG) и передавал его наружи и на второй чип. Второй чип принимал 9600, записывал его во внешнюю еепром, читал из этой внешней еепром и выдавал в центроникс. Первый чип я совершенно бессовестно содрал со всем известной югославской аппликухи :) Разумеется, адаптировав ее под свои цели, зао на втором в общем-то, крутилось одновременно 3 задачи...With best regards, Alexander Torres. E-mail: snipped-for-privacy@yahoo.com [ Жамству бой !]
DO>> на сегодня, например, такая архитектура у AT91 (ARM) DO>> вектора прерываний расположены начиная с адреса DO>> 0FFFF0080h AM>
AM> Hеправда. В AT91 лежит ядро ARM7DTMI, у которого вектора расположены в AM> адресах 0-1F. А то, что в AT91 разные внешние устройства, в том числе AM> контроллер прерываний, отображаются в верхнюю часть адресного AM> пространства, к векторам прерываний не имеет отношения. В ARM9, если я AM> правильно помню, расположение векторов не отличается от ARM7.
см AT91SAM7S64 вполне допускаю то что я далеко не все контроллеры просмотрел и они могут быть разные
мне вот интересно скушает ли IAR структуру в начале rs232.c?
кто может попробуйте
AM>>>>>> И в результате получаются чудовищные тормоза, избавиться от AM>>>>>> которых DO>>>>>
DO>>>>> Окстись, какие тормоза? Ты решаемую задачу еще помнишь? Это DO>>>>> делается для прежде всего ручного ввода пары чисел. Кому нужна эта DO>>>>> скорость? DEO>>>> это задача на AN и делать ее надо правильно AT>>>
AT>>> Ты бредишь, что в общем-то, естественно для новичков в эхе. DEO>> ПHХ AT>
AT> Юноша, не хамите. С 2-х недельным сроком пребывания в эхе - это весьма AT> чревато. какой поп такой и приход мне совершенно безразлично сколько ты в этой эхе провел от тебя я кроме хамства ничего пока и не слышал поэтому иди куда послали AT> Hаважно. Девайс давно работает. Есть чего показать своего - показывай, показал, специально убил сегодня пару часов после работы
AT> нету - упхнись. ПHХ
AS>>> // interrupt service routine variables volatile byte txd = 0; AS>>> // transmitted data volatile byte rrx = 0; // receveing AS>>> data DO>
AM>> Hу и кто же будет реализовывать volatile byte txd[TXSIZE] и volatile AM>> byte rrx[RXSIZE]? Будем получать байт, а затем, пока пережевываем AM>> предыдущий, будем глухи и немы? DO>
DO> Может ты реализуешь? Или опять найдется сотня отговорок, объясняющих почему DO> языком молоть время и деньги есть, а простую программку написать - нету. кстати у тебя там три неинициализированные переменные юзаются
static volatile byte rx_1; /* Rx One counter */ static volatile byte rx_0; /* Rx Zero counter */ static volatile byte rrx; /* receveing data */
если бы у тебя был нормальный компилятор, то он бы тебе варнинг сгенерил, а так поделка, что поделаешь ;)
Привет Dmitry!
07 Aug 06 15:58, Dmitry E. Oboukhov писал Slav Matveev:DO> на сегодня, например, такая архитектура у AT91 (ARM) DO> вектора прерываний расположены начиная с адреса DO> 0FFFF0080h
Hеправда. В AT91 лежит ядро ARM7DTMI, у которого вектора расположены в адресах 0-1F. А то, что в AT91 разные внешние устройства, в том числе контроллер прерываний, отображаются в верхнюю часть адресного пространства, к векторам прерываний не имеет отношения. В ARM9, если я правильно помню, расположение векторов не отличается от ARM7.
Всего наилучшего, [Team PCAD 2000] Алексей М. ... Закрой свой Ворд!
Hello Dmitry.
07 Aug 06 05:11, Dmitry Orlov wrote to me:DO>>>>> Да видеть-то можно что угодно, а ноpмальной документации, как DO>>>>> и ноpмальной готовой сpеды pазpаботки в gcc как не было, так и DO>>>>> нет. SD>>>> Hе, я с вас худею, мужики. В gcc не то что "ноpмальной" или SD>>>> "готовой" сpеды pазpаботки нет - в ней нет ее по опеpеделению. SD>>>> Мало С твоего позводения я большую часть поскипаю. Hасчет пpиемуществ и недостатков подхода собиpания из деталек или готового пpодукта можно будет потом побеседовать. DO> Получается, что все вpемя сpавнивается готовая DO> система с набоpом деталей для нее. Вот и веpнулись "на кpуги своя". Я пpимеpно это и имел в виду. gcc - это "деталька", котоpая может входить в какую-либо сpеду pазpаботки (см. самую веpхнюю стpочку этого сообщения). Сpеда эта может быть самособpанная, может быть пакетом включающим библиотеки и дpугие утилиты плюс любимые утилиты и pедактоpы пользователя. И может быть сделанной "под ключ" стоpонней фиpмой.
Резюмиpую: Сpеда pазpаботки может содеpжать gcc. Hо gcc сpеды не содеpжит, так как это "деталька". Логично?
Сейчас пpочитал все, думаю не убедительно получилось ;) Давай так: Ты сказал: "готовой сpеды pазpаботки в gcc как не было, так и нет". Я отвелил: "В gcc [skip] сpеды pазpаботки нет [skip] по опеpеделению". А pазговоp, какая сpеда лучше, это уже дpугая тема. Или, если обсуждаются компилятоpы, то сpеда pазpаботки не пpи делах. Хоть тепеpь более или менее ясна моя мысль?
Sergey
Hello Dimmy.
06 Aug 06 12:46, you wrote to Michael Mamaev:MM>> А нетy ее, общепpинятой. Кто-то, напpимеp, называет основнyю MM>> пpогpаммy фоном, что тоже не лишено некотоpого смысла. DT> Значит, надо говоpить "основная пpогpамма", "пpоцедуpы/функции", DT> "пpеpывания". Вопpос на засыпку: main() - это основная пpогpамма или функция? :) Или isr по вектоpу reset? ;)
Sergey
X-Virus-Scanned: amavisd-new at bezeqint.net
Hello, Leha Bishletov! You wrote in conference fido7.ru.embedded to Dmitry E Oboukhov on Mon, 07 Aug 2006 16:08:44 +0400:
LB> Долго вы с этой константой носитесь, а почему игнорируете такой LB> вариант:
LB> TMR0 += 256 - сколько_тактов_наш_период;
Я уже раз 10 говорил. Потому что в момент перезагрузки таймера ты не знаешь сколько он уже успел насчитать тиков с момента переполнения, вызвавшего прерывание. Мне проще всего оказалось просто подобрать, меряя частоту скопом.
dima
DEO> одна работает на 4МГц, DEO> соответственно ее максимальная скорость получается 9600, вторая на DEO> 10МГц, максимальная скорость получается 19200. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ сорри тут описка на 10МГц максимальная скорость 24400 :)
Hello, Anatoly Mashanov! You wrote in conference fido7.ru.embedded to Dmitry E Oboukhov on Mon, 07 Aug 2006 20:38:48
+0400:AM>>> И в результате получаются чудовищные тормоза, избавиться от DO>> там всего-то нормализовать менеджер процессов в функции main DO>> - убрать тупые циклы ожидания и система сможет начать DO>> работать асинхронно:
AM> Ага. С задержками в десятые доли секунды на каждую передиспетчеризацию. AM> Плавали, знаем. Потому и говорю: Windows не заслужила право AM> называться Операционной Системой.
Причем тут Windows? И почему ей не называться ОС?
DO>> прием сам по себе передача сама по себе :)
AM>>> У меня в одном дивайсе имеется буфер на 8 байт. AM>>> Соответственно,
DO>> буфер разумеется должен быть, но коль процессор у него DO>> озадачивается выполнением длительных команд (например когда DO>> он передает он ни на что не реагирует, когда он переводит DO>> числа в строки и строки в числа опять в таком же состоянии, DO>> когда он тупо ждет когда доработает АЦП, работающее насколько DO>> я понял на 62Кгц, то есть частота преобразования ~ 6кГц - DO>> опять сравнимо с тактом, он опять же ни на что не реагирует.
Ну это товарисч просто не разобрался. Прерывания работают, соответственно и uart работает, команды принимаются. А больше ни на что реагировать в этой программе и не надо.
AM> - значит, программист точно не читал ничего, кроме Дюма, и не AM> имеет никакого понятия ни о прерываниях, ни о многозадачных AM> системах. Если проц передает (Даже если он передает через AM> программу) - регулярно срабатывают прерывания по таймеру, и в
Конечно, тем более, что uart там программный по прерываниям от таймера.
AM> них можно сделать все экстренное. Перевод чисел в строки - это
Там все экстренное и делается.
AM> одна операция деления (Hу потрясающая задержка) в фоновом AM> процессе, прерывания продолжают работать. Когда он тупо ждет,
Конечно.
AM> когда доработает АЦП - ему никто не мешает вызывать обработчик AM> команд в цикле ожидания.
Незачем. Цикл короткий, ничего срочного при этом произойти не может.
DO>> DO тут кричит что мол ему фиолетово что сколько работает, что DO>> если
AM> МHЕ не фиолетово. У меня частота прерывания 20 кгц (Это 250
У меня 2400*3 При тактовой в 4MHz (4 такта на команду).
AM> циклов команд между сигналами прерывания), и потеря одного
Соответсвенно 1M/(2400*3) = 138 команд.
AM> прерывания абсолютно фатальна.
Ну у меня нет, хотя и неприятна. Но прерывания и не теряются.
AM> При этом дивайс ухитряется программно растянуть этот интервал до 1000 циклов, а AM> в фоне времени вообще хватает на все.
Естественно.
DO>> понадобится он сюда весь math.h притащит, а я говорю что
DO>> math.h сюда тащить не надо, потому что уже сейчас проблемы с DO>> потерей данных имеются.
AM> Значит, обработка считывания с компорта сделана неоптимально.
Он просто не понял.
AM> math.h может делать свое черное дело хоть секунды в фоне,
Именно, никого это не волнует.
AM> заглатывание данных с компорта может делаться в прерываниях по AM> таймеру.
Это и делается, пока есть место в буфере (а оно там как раз на одну команду). Да, пока она не выполнится и система не скажет OK, места для следующей нет, но оно и не нужно.
dima
AT> В любом случае - лучшего для данного применения нет. пинать надо hi-tech. отправлять им листинг и спрашивать, "пачиму ворнинги не генеряццо?!" тем паче что купленной лицензией кто-то тут хвалился
AT> А Вы лучше закончите свой рассказ про 500кВт PFC - что за топология, что за AT> ключи ? Какие параметры достигнуты. Очень интересно. а я общую топологию описал.
делали два конвертера, один с полным мостом в выпрямителе (на IGBT FF3600) и дросселями в переменке. частота ШИМ небольшая, 1.2КГц, дроссели в переменке получаются большими. и система дорогой. тополония такая: дроссели - выпрямитель (параллельно диодам IGBT) - инвертор (FF2400)
второй вариант делали 120-градусное потребление. тут успехи получше :) топология такая - выпрямитель - повышающий конвертер - инвертор.
систему выпрямитель - повышающий конвертер (он же корректор) сделали блочной, как я уже говорил на IGBT с наилучшим соотношением цена/ток. блоки работают в параллель на общий инвертор (FF1200 или FF2400) в блоках регулирующий элемент - пара SKM400.
все блоки работают на частоте 5КГц (есть варианты до 10), система спроектирована так, что повышающие модули можно добавлять. основная фишка в том что управление ими централизованное, потому ПЛИС'а сдвигает фазы управления всем корректорам так, что во входном дросселе получаются приведенные пульсации равные сумме частот. то есть на входе получается 120градусный ток, полочка которого образуется "пилой" на частоте 30-45КГц.
общие потери в первом случае 9-10кВт на 500кВт мощности во втором 10-11кВт. дросселя мотали лентой 0.5мм х 150мм
все, по моему все рассказал :)
Hello, Dmitry! You wrote to Alexander Torres on Mon, 07 Aug 2006 23:01:40 +0400:
AM>>>>>>> И в результате получаются чудовищные тормоза, избавиться от AM>>>>>>> которых DO>>>>>>
DO>>>>>> Окстись, какие тормоза? Ты решаемую задачу еще помнишь? Это DO>>>>>> делается для прежде всего ручного ввода пары чисел. Кому нужна DO>>>>>> эта скорость? DEO>>>>> это задача на AN и делать ее надо правильно AT>>>>
AT>>>> Ты бредишь, что в общем-то, естественно для новичков в эхе. DEO>>> ПHХ AT>>
AT>> Юноша, не хамите. С 2-х недельным сроком пребывания в эхе - это весьма AT>> чревато. DEO> какой поп такой и приход DEO> мне совершенно безразлично сколько ты в этой эхе провел DEO> от тебя я кроме хамства ничего пока и не слышал DEO> поэтому иди куда послали
Юноша. не хамите! Вы помоему не поняли куда Вас послали :)
AT>> Hаважно. Девайс давно работает. Есть чего показать своего - показывай, DEO> показал, специально убил сегодня пару часов после работы
AT>> нету - упхнись. DEO> ПHХ
Я надеюсь, модератор это тоже увидит?
P.S. А упхнуться придется по любому.
With best regards, Alexander Torres. E-mail: snipped-for-privacy@yahoo.com [ Жамству бой !]
Hello, Dmitry! You wrote to Dmitry Orlov on Mon, 07 Aug 2006 23:04:04 +0400: DEO> кстати у тебя там три неинициализированные переменные юзаются
DEO> static volatile byte rx_1; /* Rx One counter */ DEO> static volatile byte rx_0; /* Rx Zero counter */ DEO> static volatile byte rrx; /* receveing data */
DEO> если бы у тебя был нормальный компилятор, то он бы тебе варнинг DEO> сгенерил, а так поделка, что поделаешь ;)
В любом случае - лучшего для данного применения нет. А Вы лучше закончите свой рассказ про 500кВт PFC - что за топология, что за ключи ? Какие параметры достигнуты. Очень интересно.
With best regards, Alexander Torres. E-mail: snipped-for-privacy@yahoo.com [ Жамству бой !]
AM>>> Hеправда. В AT91 лежит ядро ARM7DTMI, у которого вектора AM>>> расположены в адресах 0-1F. AM>
DO>> см AT91SAM7S64 AM>
AM> The AT91SAM7S64 is a low pincount Flash microcontroller based on the 32-bit AM> ARM7TDMI RISC processor.
страница 164
адрес
0xFFFF F000 офсеты 0x80 - нулевой вектор 0ч84 - первый итдне я конечно досконально не разбирался. я пока что поглядел на ноги процессора куда какие распихивать и тестовую платку развел (светодиодиками помигать), вот жду когда изготовят. А ну и компилятор еще скомпилировал :)
пока на них ничего не пробовал, но думаю к концу недели платы будут готовы, а на следующей уже поиграюсь :)
Приветствую Вас, Dmitry!
Однажды 05 Авг 06 в 20:26, Dmitry E. Oboukhov писал(а) к Dmitry Orlov...
DO> так вот и M$ делает, потому и венда такая дырявая DO>
DO>
А что должно было быть-то? Может надо было что-то дополнительно отключить, подкpутить?
Втоpая ссылка - какой-то фоpум. Мне ничего не понятно там...
С уважением, Виталий.
... -|O|-
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.