Hадежный контроллер нужен........



Hello, Michael Zaichenko! You wrote in conference fido7.ru.embedded to Dmitry Orlov on Sat, 05 Aug

2006 02:43:41 +0400:

DO>> Hадо. Только что это обсудили, лень еще раз приводить те же DO>> аргументы. Hа

DO>> фоне IAR (даже не принимая во внимание качество кодогенерации) gcc DO>> выглядит недоделанной поделкой. Скверно документированной и DO>> решающей только часть задач, решаемых пакетом от IAR.

MZ> Качнул на днях свежий ВинАвр. дабы сравнить с иаром. MZ> Документация на компилятор и библиотеку есть поставке, в формате MZ> ПДФ.

Да, появилось, это прогресс. Еще год назад не было. Правда это все равно документация на gcc вообще, а не на конкретный AVR'овский компилятор.

MZ> У кейла тоже в пдф.

MZ> Есть 4 примера проектов, один там даже с жк диплеем. MZ> Все компилятся и собираются без ошибок :)

Тоже наметился некоторый прогресс. Хотя конечно 4 примера - мало.

MZ> Решил портануть несколько живых проектов. MZ> Как оказалось, ничего сложного в мейк фалах нет :)

Нет, но нет и альтернативного способа покидать исходники в проект в IDE.

MZ> С учетом халявы - очень даже гуд.

С учетом халявы - любая халява гуд.

MZ> И последний вопрос - какая гуевая среда разработки имеет кнопку, MZ> аналогичную команде make clean? MZ> Уж очень эта фишка мне понравилась.

Не знаю, а надо очень?

dima

formatting link

Reply to
Dmitry Orlov
Loading thread data ...

Hello Dmitry.

Sat Aug 05 2006 01:18, Dmitry E Oboukhov wrote to Dmitry Orlov:

DO>> В каком низу? Критично ко времени там только то, что касается UART'а. DEO> а блин, это старая, времен 86РК терминология DEO> верх - прерывания DEO> низ - основная программа

Странно. Ведь прерывания - это как раз нижний уровень. Может, постараешься пользоваться общепринятой терминологией? :)

Dimmy.

Reply to
Dimmy Timchenko

Hello Arcady.

Sat Aug 05 2006 03:08, Arcady Schekochikhin wrote to Dmitry E. Oboukhov:

AS> И самый лучший компилятор для x86 несомненно интеловский.

А где его брать?

Dimmy.

Reply to
Dimmy Timchenko


Hello, Dmitry E. Oboukhov! You wrote in conference fido7.ru.embedded to Dmitry Orlov on Sat, 05 Aug

2006 01:30:35 +0400:

DEO>>> не проще ли было задаться начальным сопротивлением и и КТС?

DO>> Если ты посмотришь на зависимость сопротивления NTC от температуры, DO>> то обнаружишь там экспоненту (реально там более сложная DO>> зависимость, иногда ее

DEO> а она у них у всех экспонента, а описывается простой формулой - DEO> сложение и умножение или сложение и деление в зависимости от того DEO> положительный ТКС или отрицательный

Ну опиши и сделай по-своему. Еще интересней и полезней будет. Я же не настаиваю на том, что у меня единственно верное решение.

DO>> Я о топологии силовой схемы, а не о том сколько там ключей и на DO>> какой частоте они работают. DEO> а я всю топологию и рассказал :)

Хотелось бы подробней.

DO>> Полмегаватта - это 100% трехфазная схема. DEO> конечно :)

DO>> Вот меня и интересует как в ней сделан PFC. Есть любопытный патент, DO>> называется Vienna rectifier или как-то так, в котором описывается DO>> такой трехфазный PFC. DO>> Правда подробностей алгоритма управления в тех материалах, что я DO>> видел не раскрывались. Впрочем мною тут двигало чистое любопытство, DO>> у нас мощности до киловатта.

DEO> а ну в принципе вариантов может быть множество от полного инвертора DEO> в качестве выпрямителя (это будет чисто синусоидальное потребление) DEO> и дросселей на входе

Я посматриваю из любопытства на подобные решения, особого разнообразия вариантов не вижу. Это или полный мост на IGBT или вот еще этот патент.

DO>> Сколько же у вас там индуктивность и напряжение? Как такое вообще DO>> может быть? DEO> индуктивности милигенрями измеряются (единицы) DEO> а напряжение на выходе корректора 800-1000В, на входе 380В :)

Ну так откуда тогда 1200 ампер за 500ns?

DO>> И зачем защиту от токовой перегрузки отвязывать оптроном?

DEO> а она и не отвязана. это я время прохождения сигнала защиты от DEO> ключа к ключу посчитал. DEO> если у нас ток прется (а он обычно так и прется) через пару ключей DEO> (или даже через три), то по защите одного надо вырубать все. DEO> а это кроме как оптронами (ну или оптоволокном) никак друг с другом DEO> не сочленить :)

Трансформаторами еще можно сочленить.

dima

formatting link

Reply to
Dmitry Orlov

То есть кроме Си ты ничего не знаешь и знать не хочешь? В чем там разбираться то - почти паскаль. Вот то же самое на Си - можно легко видеть что это почти 1-в-1 -

// Print 3 digit decimal with leading "=" static __attribute__((fastcall)) void printi(byte i) { byte d = 100;

tty('='); for (;;) { // division is code consuming - make without! byte c = '0'; while (i >= d) { i -= d; c += 1; } tty(c); if (d == 100) d = 10; else if (d == 10) d = 1; else return; } }

// convert string to number static __attribute__((fastcall)) byte stoi(byte i) { byte b = 0;

for (;;) { byte c = str[i];

c -= '0'; if (c > 9) return b; b <<= 1; // b * 2 c += b; b <<= 2; // b * 8 b += c; // (b * 8) + (b * 2) + (c - "0") } return b; }

А конструкция типа tty = "=" - это не абракадабра, а очень красивая фича языка JAL - доступ к переменной по записи/чтению (или сразу оба) компилятор делает в виде вызова специальной функции - очень элегантно реализуются всякого рода теневые (буферизованные) регистры.

В чем "есть смысл"? Не понял фразы.

Reply to
Arcady Schekochikhin

DO> Hет никакой связи. Я же уже дважды объяснил почему число в таймере надо DO> подбирать. От момента возникновения прерывания до начала его обработки DO> проходит некоторое время это время всегда одинаковое, потому подбор в твоем случае связан только с тем что если "разделить" твое прерывание, то до обработки прерывания по передаче данных у тебя сперва должно обработаться прерывание по приему данных. вот тут задержка получается существенная и всякий раз разная (в зависимости от того по каким веткам пробежало)

вот я и говорю надо отделить логику низкоуровневого управления от выдачи сигналов на выводы.

ты просто слушать не хочешь, хотя я уже это 10 раз повторил. так бы и на PIC можно было 4800 реализовать ;)

DO>>> Этого я совершенно не понял. Ты про обработку команд, вводимых с DO>>> терминала? я ответил на этот вопрос уже два раза я про выдачу/распознавание битов данных и битов старт/стоп/четность вот ниже ты и отквотил

DEO>> нет про низкоуровневую реализацию RS232 старт-бит данные (от 5 до 9 DEO>> бит) бит четности два стоп-бита DO>

DO> Так где же, кроме прерывания это делать? можно и в прерывании, если тебе кажется что кроме как там негде ;) но тогда в прерывании это делать _после_ того как очередной бит будет выдан на ногу и принят с неё :)

DEO>> парсить/собирать в кучу эти данные если в основной программе, а в DEO>> прерываниях только двигать, то в прерываниях можно будет не DEO>> заботиться о подборе значений таймера :) DO>

DO> Hапиши на С, я так не понимаю. А не заботиться нельзя, даже если в DO> прерывании я только ножкой дергаю. может быть и напишу, но вроде я внятно объясняю вот на человеческом языке алгоритм для варианта как ты хочешь, "все в прерываниях" (хотя в прерываниях вовсе не нужно этого делать)

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

короче доработка напильником:

твоя void interrupt sys_int(void) {

добавляем строки static bit inbuffer=0; // тут могут быть начальные static bit outbuffer=0; // значения другие - тебе виднее

сразу после T0IF = 0; добавляем строки

inbuffer=TRx; TTx=outbuffer;

а дальше весь твой же код как он есть, но все обращения к TTx и TRx замени на обращения к inbuffer outbuffer.

что мы получили?

  1. мы получили что время от выставления флага переполнения таймера 0 до выставления сигнала на ножке TTx и принятия сигнала с ножки TRx всегда одинаковое. как бы там программа дальше не работала
  2. вследствие п. 1 мы можем вверху программы определить BAUD_RATE, а строку TMR0 = 133; определить через макрос исходящий из FOSC и BAUD_RATE. и HИКАКИХ подборов.

теперь то что о дальнейшей оптимизации:

теперь мой код что я добавил назовем вводом-выводом, а твой (модифицированный как я описал выше) назовем логикой работы RS.

так вот я говорю, что если немного поднапрячь мозги и избавиться от циклов ожидания которые у тебя есть внизу (надеюсь уже не будем придираться к этому термину ;) ), а написав нормальный менеджер процессов внизу (хоть тупой перебор функций например) мы можем логику работы RS перенести вниз. (скорость такая маленькая что это запросто)

да деление уже использовать нельзя будет (хотя если часть логики оставить все же наверху - перейти к сдвиговым регистрам то можно дооптимизироваться и до возможности применять деление), но т.к. процессорное время будет использоваться более рационально вполне вероятно мы сможем и BAUD_RATE поднять раза в два. два раза скорее всего и PIC вытянет с нормальным подходом :)

PS: а если ты еще перепишешь strtoi по тому же принципу как я переписал твою printi то получишь еще одну такую же (если не больше) экономию в объеме и скорости выполнения :)

PPS: ну что, если не разобрал свой макет на котором это собрано попробуешь доделать в соответствии с моим рекомендациями?

DO> Для этого из tputch вызывается idle. вот я и говорю сделать классический событийный вид, а не ставить костыли :)

DO> Во-первых, никто никому и ничего не должен. Процессы должны получать свое DO> время, они его и получают. И никакого хаоса и путаницы нет и в гораздо DO> более DO> сложных программах. ты где-то выше сказал фразу "для того чтобы получить нормальный Апликейшн нотес", а уж коль взялся за такого уровня задачу, изволь таки не открещиваться или прекратим разговор :) в AN код должен быть прост и понятен у того кто читает не должно быть продираний сквозь дерево функций с циклическими завязками как у тебя. алгоритм должен быть четко виден.

Reply to
Dmitry E. Oboukhov

А что там в GCC может быть такого AVR-специфичного? Ну ключей немного - так они и в info описаны.

Reply to
Arcady Schekochikhin

DO> Hу так откуда тогда 1200 ампер за 500ns? ну вот смотри, дроссель у тебя = бесконечности возьмем классический понижающий регулятор.

выходной ток через дроссель - непрерывный (он равен же бесконечности)

а транзистор и обратный диод коммутируют выходной ток, не так ли?

то есть если выходной ток 1200А, то и фронты тока будут величиной 1200А, а если транзистор (диод) включаются/выключаются за 500нс, то и фронты будут 500нС х 1200А.

ну и то же самое в инверторе с небесконечной индуктивностю. ее небесконечность обычно дает уход от вышеприведенного идеального случая к фронтам с бОльшим током :)

DO> Трансформаторами еще можно сочленить. емкость у трансформаторов обычно сильно выше емкости у оптронов (а уж тем более у фиберов), а потому с помехами на трансформаторах часто хуже бывает (в сложной, многопотенциальной системе)

Reply to
Dmitry E. Oboukhov

NM>

NM> О! NM> Ты сделал под 13? читай внимательнее немного :) он меня убеждает сделать, только я не вижу зачем. я пока ему выдал коментариев массу на то что им сделано, он правда местами слушать не хочет, но я думаю это можно преодолеть :)

а тупо портировать с архитектуры на архитектуру - зачем? тем более тот код что там есть ;)

NM> Пришли, если можно. А я прошью, и закончим эту бодягу. Если хочешь - можешь NM> прислать токо hex, только, чтоб плату не резать желательно ноги разложить NM> так: NM>

NM> /* Pin (num) Name Description */ NM> /* PB0 (5) Out Triac gate */ NM> /* PB1 (6) Tx UART Tx pin */ NM> /* PB2 (7) Rx UART Rx pin */ NM> /* PB3 (2) NC Tts Analog input. 100k NTC connected from +5V */ NM> /* to Tts pin and pulled down with 5.61k */ NM> /* PB4 (3) NC */ NM> /* PB5 (1) Reset */ NM>

NM> У меня почти все уже работает, только на rx контроллер не реагирует. NM> негативные импулься на ножку приходят, и события (в симуляторе) NM> накапливаются правильно, но тут я немного застрял.

объясни мне, в чем ценность данного девайса? я просто не вижу места где я его мог бы применить :)

Reply to
Dmitry E. Oboukhov

AS> То есть кроме Си ты ничего не знаешь и знать не хочешь? В чем там разбираться то - почти AS> паскаль. Вот то же самое на Си - можно легко видеть что это почти 1-в-1 - а JAL ты чем в МК собираешь? я не интересовался просто :)

Reply to
Dmitry E. Oboukhov

DO>> на ПЛИС RS232 выражается в два сдвиговых регистра (прием-передача) с DO>> логикой (в принципе они и в процессорах реализованы так же), RM> Ты с SPI не перепутал? Еще к этим регистрам добавь счетчики с запуском от RM> стартового бита и кучку триггеров для различных ситуаций. То есть триггеров RM> это займет побольше, чем просто на два регистра. да про прием то я не подумал (писал уже) передача - простой сдвиговый регистр (который двигает все включая старт/четность/данные/стоп

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

RM>

DO>> ну и остается ввод аналоговых данных (пока не прикидывал) и одно из DO>> самых ресурсоемких - делитель чинхрочастоты до частоты передачи по RS. DO>> (тут на ПЛИС выгоднее будет 115200бод реализовать чем 2400) RM>

DO>> (12+12+8+8)*1.2=48 макроселов - в долларовую 3064 впихивается. RM> Очень хочется поверить. Будь добр, слепи такое и выложи где-нибудь. Или мне RM> мылом пришли схемку/текст, на чем оно там у тебя будет. Я бы с RM> удовольствием поучился, потому что в моем представлении- не влезет. это моя ошибка, в маленькую ПЛИС не влезет оно :)

PS: вот так всегда, напишешь ошибку один раз, потом извиняться за нее тысячу раз придется :)

Reply to
Dmitry E. Oboukhov

 X-Virus-Scanned: amavisd-new at bezeqint.net

Hello, Dmitry E. Oboukhov! You wrote in conference fido7.ru.embedded to Dmitry Orlov on Sat, 05 Aug

2006 11:20:11 +0400:

DO>> Да видеть-то можно что угодно, а нормальной документации, как и DO>> нормальной готовой среды разработки в gcc как не было, так и нет. DEO> вот среда разработки то как раз наоборот существенно лучше DEO> GNU-utils :)

Это не среда, это утилиты какие-то.

DEO> а какой документации тебе не хватает? по gcc такой ее талмуд что DEO> читай не перечитаешь :)

Конкретного описания копмилятора и линкера под целевую платформу. Не вообще, а только то, что нужно.

DEO>>> плохости IDE в том что при переходе с типа на тип надо постоянно DEO>>> разбираться а как оно там делается, а где оно тут.

DO>> С типа чего на тип чего?

DEO> контроллеров или компиляторов.

Ну тех же контроллеров IAR в 20 раз больше поддерживает. А чего между компиляторами все время скакать?

DEO> если я поменяю компилятор hi-tech на например gcc (как в свое время DEO> я проделал), то у меня только пара строчек в Makefile поменяется, а DEO> если я потом уйду на вообще, скажем техасовский проц то еще пара DEO> строчек.

Нет. Основная проблема - это не пара необязательных опций компилятора, а линкерные скрипты. IDE здорово облегчает процесс их создания.

DEO>>> к большинству IDE внешние редакторы подключаются криво и DEO>>> неудобно,

DO>> Их и подключать-то не надо, открываешь файл и редактируешь. DEO> а зачем тогда IDE?

Посмотри обсуждения за последний месяц на groups.google.com. Тебе не надо - не пользуйся. А я - хочу, чтоб IDE было. Буду я им в конечном счете пользоваться или нет. Чтоб были хэлпы, пошаговые тьюториалы, эвалюэшн борды, примеры - все как у людей.

DEO> в том же Quartus IDE любит открыть редактор сама при компиляции

Я не знаю кто такой квартус.

dima

formatting link

Reply to
Dmitry Orlov

 X-Virus-Scanned: amavisd-new at bezeqint.net

Hello, Dmitry E. Oboukhov! You wrote in conference fido7.ru.embedded to Alexey V Bugrov on Sat, 05 Aug

2006 11:21:32 +0400:

DEO>>>>> я смысла вообще в IDE-шных замедлялках времени разработки не DEO>>>>> вижу. DEO>>>>> пока блин разберешься к чему прислонить то или иное окошко DEO>>>>> голову сломаешь, нафига оно надо? AVB>>>> Зачем в иаре пользоваться IDE? Я не пользуюсь и никаких AVB>>>> проблем. AVB>>>> Именно что мейкфайл все прекрасно собирает из него же и шьется. DEO>>> а чем хорош iar'овский компилятор?

AVB>> А чем плох? DEO> в линуксе например не работает. DEO> для меня например это существеннейший фактор

А в линуксе оркад и пикад не работают и куча всего остального. Мой бывший сотрудник на новой работе вообще в осциллографе и копилирует и прожигает. Под виндой, понятное дело.

dima

formatting link

Reply to
Dmitry Orlov

DO>>> Да видеть-то можно что угодно, а нормальной документации, как и DO>>> нормальной готовой среды разработки в gcc как не было, так и нет. DEO>> вот среда разработки то как раз наоборот существенно лучше DEO>> GNU-utils :) DO>

DO> Это не среда, это утилиты какие-то. DO>

которые в сумме и есть среда. очень очень гибкая.

вот пример, расскажи как ты будешь решать его IAR

допустим тебе нужна таблица

200 значений f=(A,B,C,x) где A, B, C - постоянные которые ты планируешь выбрать в процессе отладки а таблица собственно ставит в соответствие f и x

функция будем считать что не приводится к простовычислябельному виду, а содержит скажем логарифмы и синусы.

расскажи мне как будет выглядеть твоя работа на очередной итерации где надо поменять A,B,C и провести новый эксперимент? в IAR

DO> Hу тех же контроллеров IAR в 20 раз больше поддерживает. А чего между DO> компиляторами все время скакать? а того, что когда натыкаешься что один компилятор тебе почему-то не подходит берешь другой. например ошибку нашел или оптимизатор у другого лучше итп

DO> Hет. Основная проблема - это не пара необязательных опций компилятора, а DO> линкерные скрипты. IDE здорово облегчает процесс их создания. не вижу я облегчения

Reply to
Dmitry E. Oboukhov

AVB>>> А чем плох? DEO>> в линуксе например не работает. DEO>> для меня например это существеннейший фактор DO>

DO> А в линуксе оркад и пикад не работают и куча всего остального. Мой бывший DO> сотрудник на новой работе вообще в осциллографе и копилирует и прожигает. DO> Под виндой, понятное дело. под вайном Оркад работает, а пикад я со времен 4-й версии забросил

Reply to
Dmitry E. Oboukhov


Hello, Arcady Schekochikhin! You wrote in conference fido7.ru.embedded to Dmitry Orlov on Sat, 5 Aug 2006 08:09:00

+0000 (UTC):

AS> Dmitry Orlov wrote:

AS>>> когда я пример переписывал на JAL то деление и умножение выкинул AS>>> (умножение требует много места для вызова а так оно по прежнему AS>>> используется) и конвертеры чисел получилсь такие -

AS>>> // Print 3 digit decimal with leading "=" AS>>> procedure printi(byte in i) is tty = "="

AS> То есть кроме Си ты ничего не знаешь и знать не хочешь?

Я и С не хочу знать, но приходится. А уж вникать в чьи-то поделки я вовсе не понимаю зачем.

AS> В чем там разбираться то - почти паскаль. Вот то же самое на Си -

Ну это тоже, что Обухов приводил, только цикл развернут.

AS> А конструкция типа tty = "=" - это не абракадабра, а очень красивая AS> фича языка JAL -

Не надо красивых фич никому неизвестного языка.

AS>>> я думаю в синтаксисе легко разобраться - а разные "некрасивые

AS> В чем "есть смысл"? Не понял фразы.

Разбираться в синтаксисе этого поделия.

dima

formatting link

Reply to
Dmitry Orlov

AS>> Dmitry Orlov wrote: DO>

MZ>>>> Документация на компилятор и библиотеку есть поставке, в формате MZ>>>> ПДФ. DO>

DO>

AS>> А что там в GCC может быть такого AVR-специфичного? Hу ключей AS>> немного - так они и в info описаны. DO>

DO> Способ описания прерываний, доступа к ресурсам кристалла. описан был еще N лет назад, когда я впервые им что-то компилировать начал

#include <avr/signal.h>

SIGNAL(имя_прерывания) { реализация }

DO> Как компилятор DO> выполняет основные вещи. Как передает параметры, как и где хранит DO> переменные. все что традиционно то традиционно. стек

DO> Как определить это. читать документацию, очевидно если это сложно, то смотреть листинги :)

Reply to
Dmitry E. Oboukhov

Hello Dmitry.

Sat Aug 05 2006 01:40, Dmitry Orlov wrote to Dmitry E. Oboukhov:

DO> Hа фоне IAR (даже не принимая во внимание качество кодогенерации) gcc DO> выглядит недоделанной поделкой.

Кстати, иаровцы почему-то прайс-лист не приводят, надо с ними общаться лично, а этого не хочется. Поэтому хотел спросить: сколько примерно стоит их EW? Ты говорил, что на работе у тебя купленный.

Dimmy.

Reply to
Dimmy Timchenko

Hello Dmitry.

Sat Aug 05 2006 11:12, Dmitry E Oboukhov wrote to Nicolas Minakov:

DEO> вот IAR может генерить ASM-листинги всех компилируемых файлов?

Может, и не только листинги, но и исходники.

DEO> а может он их в отдельный каталог класть чтобы не мусорить в каталоге DEO> проекта?

Кладёт по умолчанию.

DEO> а объектники туда-же отдельно положить, чтобы вообще чистота и уют DEO> были в каталоге проекта?

Так и делает.

DEO> а с cvs работать?

А вот этого не знаю, не пользовался.

Ещё он у меня хорошо дружит с MED-ом: редактируешь в редакторе файл, сохранил - IDE тут же перечитало, можно компилить или отлаживать. Откомпилил, исправил синтаксическую ошибку - изменённый исходник тут же подхватил MED. :)

DEO> в make добавил пару таргетов на коммит в cvs репозитарий и радуешься DEO> жизни :)

В IDE там есть, например, "Pre-build command line" и "Post-build command line". Hу а make может быть такой же, как и у тебя.

Dimmy.

Reply to
Dimmy Timchenko

DEO>>> а какой документации тебе не хватает? по gcc такой ее талмуд что DEO>>> читай не перечитаешь :) AM>

DO>> Конкретного описания копмилятора и линкера под целевую платформу. AM>

AM> В GCC нет линкера. да, кстати, ЛОЛ

мне тут недавно один товарищ (из службы техподдержки Atmel) объяснял как внутрисхемно программировать кристаллы ARM почти дословно: берем _компилятор_ IAR, тыкаем в _компиляторе_ куда-то там...

вот еще один вред от всяческих IDE - люди теряют связь с окружающей их действительностью :)

Reply to
Dmitry E. Oboukhov

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.