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



Hello, Dmitry E. Oboukhov! You wrote in conference fido7.ru.embedded to Dmitry E. Oboukhov on Fri, 04 Aug 2006 21:26:33 +0400:

DEO>> 12 - прием, 12 передача,

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

Что такое коллизии фронтов?

DEO> кстати ща гляну как там с колизиями фронтов в твоей программе.

Глянь. Только у меня этот код работает не только в демонстрационном, но и в одном вполне боевом проекте (в тестовом оборудовании).

DEO> а про ПЛИС - дорого получается данная задача, неподумавши это я про DEO> ПЛИС. реализуемо, но дорого (по сравнению с CPU разумеется а не

Ясно, что реализуемо. На ПЛИС можно реализовать процессор, а на нем задачу, только это мягко говоря другой уровень и цен и разработок. У меня на все про все ушло около недели (от объявления конкурса до публикации результатов). Разумеется не рабочего времени.

dima

formatting link

Reply to
Dmitry Orlov
Loading thread data ...

DT>>> IAR тоже поделка? DEO>> угу DEO>> я смысла вообще в IDE-шных замедлялках времени разработки не вижу. DEO>> пока блин разберешься к чему прислонить то или иное окошко голову DEO>> сломаешь, нафига оно надо? AVB>

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

Reply to
Dmitry E. Oboukhov

Hello, Dmitry! You wrote to Alexey V Bugrov on Fri, 04 Aug 2006 18:26:30 +0400:

DO>>>> Последнее, что меня волнует, это DO>>>> наличие gcc. DEO>>> gcc это лучший на сегодня имхо компилятор. остальные по сравнению с DEO>>> ним - поделки :) AVB>>

AVB>> Лучший для какой архитектуры? Hапример для x86 данное утверждение AVB>> весьма спорно. DEO> эхотаг прежде всего разумеется

DEO> да и для x86 он лучший.

С какого бодуна, она стал "лучшим" для х86 ?!

Лучший. и наиболее употребимый для х86, на сегоднешний день - это MSVC, как бы не любить Борланд Билдер или что-то другое.

DEO> и не надо вспоминать MSVC, мне плевать как он там switch оптимизирует, DEO> его ну никак не применить для компиляции распространенных например DEO> прокси-серверов, веб-серверов итп. а наиболее распространенные сервера DEO> компилятся опять же тем же gcc. что уводит нас от мнимой эффективности DEO> оптимизации switch, к реальности.

А кого интересует на х86, оптимизация свитча?!

With best regards, Alexander Torres. E-mail: snipped-for-privacy@yahoo.com [ Жамству бой !]

Reply to
Alexander Torres

DO> Скорость в подобных местах дело десятое, это индикация, которая всяко DO> быстрее человека работает. А вот уменьшение объема - дело полезное. Хотя DO> если деление все равно используется где-то еще, то может получиться и DO> наоборот, надо будет проверить. у тебя пока делит - напрочь процессы внизу останалвиваются в принципе пока их немного можно и наплевать :)

DEO>> код прерывания мне не понравился, хреново когда программа где-то в DEO>> середине привязывается к конкретным числам навроде TMR0=133 DO>

DEO>> я бы определил BAUD_RATE вверху в дефайнесах а остальное бы DEO>> макросами бы перевычислилось. DO>

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

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

DO> Я по такой методике все свои управляющие программы пишу. Тут оно DO> выродилось, DO> а обычно у меня там основной конечный автомат сидит. Я же не с нуля писал, DO> а DO> взял какой-то предыдущий проект и стал править. а что не взять классическую событийную модель?

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

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

DEO>> в принципе программа даже в таком виде что есть просто на AVR DEO>> перенесется (ну за исключением специфики по инициализации ресурсов DEO>> типа таймеров и AЦП) DO>

DO> Так собственно и задумывалось, с твоим printi она компилируется в DO> Total ROM used 945 words (92.4%) DO> Total RAM used 56 bytes (87.5%) DO> С использованием деления - DO> Total ROM used 991 words (96.9%) DO> Total RAM used 54 bytes (84.4%) а ну и размер разумеется

еще const припиши к массиву, он в rom уйдет, код инициализации выкинется и возможно поменьше байтов будет :)

Reply to
Dmitry E. Oboukhov

DEO>> 99.9% программ которыми я пользуюсь невозможно скомпилить на MSVC DEO>> а если и возможно то на это надо столько усилий вложить сколько никому DEO>> в голову не придет AVB>

AVB> Это проблемы пейсателей. Правильные программы собираются любым AVB> компилятором. а эти программы и собираются кучей компилеров, интеловским например итп вот MSVC не в кассу :) да и нет его кроме как под виндой нигде практически

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 Fri, 04 Aug

2006 21:51:00 +0400:

DEO> кстати смотрю в код trm.c

DEO> printi можно жутко оптимизировать по скорости, выкинув нафиг DEO> деление.

По скорости - не актуально, а вот по объему - да. Принимается.

DEO> void printi(byte value) DEO> { DEO> byte digits[]= { 100, 10, 1 }; DEO> byte ch; DEO> byte i=0;

DEO> for (i=0; i<3; i++) DEO> { DEO> ch='0'; DEO> while(value>=digits[i]) DEO> { DEO> ch++; DEO> value-=digits[i]; DEO> } DEO> tputch(ch); DEO> } DEO> }

DEO> в максимуме получается 1+9+9 вычитаний, что всяко меньше вычислений DEO> i%= и d/= :) на 16-разрядных числах сей алгоритм существенно быстрее работает DEO> чем перевод 16-рязрядного int в 5-строку с помощью деления.

Скорость в подобных местах дело десятое, это индикация, которая всяко быстрее человека работает. А вот уменьшение объема - дело полезное. Хотя если деление все равно используется где-то еще, то может получиться и наоборот, надо будет проверить.

DEO> код прерывания мне не понравился, хреново когда программа где-то в DEO> середине привязывается к конкретным числам навроде TMR0=133

DEO> я бы определил BAUD_RATE вверху в дефайнесах а остальное бы DEO> макросами бы перевычислилось.

А это число не вычислением, а подбором получено. То есть первое приближение конечно посчитано, а на сколько успевает убежать таймер пока от начала прерывания до этого места управление доберется считать сложно - проще подогнать по скопу.

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

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

DEO> в принципе программа даже в таком виде что есть просто на AVR DEO> перенесется (ну за исключением специфики по инициализации ресурсов DEO> типа таймеров и AЦП)

Так собственно и задумывалось, с твоим printi она компилируется в Total ROM used 945 words (92.4%) Total RAM used 56 bytes (87.5%) С использованием деления - Total ROM used 991 words (96.9%) Total RAM used 54 bytes (84.4%)

dima

formatting link

Reply to
Dmitry Orlov

Hello, Dmitry! You wrote to Alexander Torres on Fri, 04 Aug 2006 22:53:20 +0400:

DEO> 99.9% программ которыми я пользуюсь невозможно скомпилить на MSVC DEO> а если и возможно то на это надо столько усилий вложить сколько никому DEO> в голову не придет

Это проблемы пейсателей. Правильные программы собираются любым компилятором.

WBR, AVB

Reply to
Alexey V Bugrov

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

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

2006 21:53:41 +0400:

DO>> Условия объяснять мне не надо, как мне и не нужен результат, я знаю DO>> как это делается, более того, я сел и сделал на том, с чем работаю. DO>> Hе хочешь свои слова подтверждать делами - не надо, я не настаиваю. DEO> программа будет в AVR функционировать практически без доработок, DEO> это и макетировать не надо

DEO> смысл собирать схему в чем состоит? убедиться что работает?

Конечно. Ты знаешь другой способ?

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

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

DEO> какие утверждения бездоказательны по твоему?

Например про большую производительность AVR. Я легко в это поверю, но не после бессмысленных сравнений, а после того, как увижу указанный алгоритм программного UART'а, работающим на 4800 (причем без кварца, на внутреннем rc).

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 Dmitry Orlov on Fri, 04 Aug

2006 22:37:51 +0400:

DO>> программа работает я не знаю. Я даже не настаиваю на макете именно DO>> на целевом чипе. Лишь бы при переносе на целевой работоспособность DO>> сохранялась.

DEO> я уже сказал, данная программа практически без изменений пойдет на DEO> AVR, особо если не настаиваешь на компиляции на целевом чипе, то DEO> смысла вообще не вижу. разве что программу по своему переписать а смысл?

Смысл в том, чтобы программа _работала_ на целевом железе, а не только компилировалась под него. Если она работает на похожем, велика вероятность, что и на целевом заработает. Кроме того, можно и переписать. Я же предлагаю задачу решить, а не просто перекомпилировать (хотя это тоже допустимо).

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

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

Если ты посмотришь на зависимость сопротивления NTC от температуры, то обнаружишь там экспоненту (реально там более сложная зависимость, иногда ее приводят в справочниках, иногда только таблицу). В архиве есть текстовый файл, который можно импортировать в exel и построить график, который эта функция реализует. Там будет видно, что КТС дело не исчерпывается.

DO>>>> 500кВт преообразователь - устройство достаточно низкочастотное

DEO>>> 40КHz, если интересно эквивалентная частота корректора мощности DEO>>> :)

DO>> PFC на полмегаватта? А по какой топологии он сделан и чем DO>> управляется?

DEO> тут все просто. ключ на 2400А (а уж тем паче на 3600А) стоит почти DEO> вдвое дороже 6-ти (9-ти) ключей на 400А. DEO> на рынке силовых приборов в каждый момент времени есть прибор у DEO> которого соотношение амперов/к цене наилучшее. (400А - в данном DEO> случае для Semikron)

DEO> ну и просто корректорный дроссель делим на 6 веток, каждая из DEO> которых работает на частоте 5КГц. Смещаем фазы друг относительно DEO> дружки (ПЛИС это делает) и получаем девайс по цене уложенный в ту DEO> же стоимость что и серийный на 2400А/3600А приборах а эквивалентная DEO> частота получается 5КГц * 6 = 30КГц (5КГц * 9 = 45КГц)

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

DEO> не совсем. даже в ПЧ с ШИМ'ом 1КГц обычно очень критичны задержки в DEO> диапазонах 1мкС. например тот же FF2400 включаясь делает фронт тока

1200А за DEO> 300-500нС.

Сколько же у вас там индуктивность и напряжение? Как такое вообще может быть?

DEO> а типичный оптрон имеет ту же задержку (500нС). DEO> оптрон вперед/оптрон назад - задержка на защиту - микросекунда - DEO> сразу лишние 2-3КА возможного аварийного тока :)

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

DEO> PS: я собственно больше силовой электроникой и занимаюсь чем DEO> эхотагом :)

Я собственно тоже.

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 Dmitry Orlov on Fri, 04 Aug

2006 22:56:07 +0400:

DEO>>>> 12 - прием, 12 передача,

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

DO>> Что такое коллизии фронтов?

DEO> это совпадения по времени внутреннего синхронизатора с внешним DEO> изменением сигнала

Это на здоровье, у меня три выборки на бит. Хотя есть и другой прием. Ловим прерыванием (естетсвенно rx должен приходить на вход прерывания) фронт стартового бита, отступаем на полбита и убеждаемся, что это старт. Дальше заряжаем таймер на длину бита и делаем по выборке в середине каждого бита. Такой алгоритм меньше грузит процессор, но требует больше аппаратуры. И таймер фактически монопольно этим занят, и ножка прерывания (а она может быть более важным занята). и алгоритм какой-то "рыхлый" получается. Но когда-то и такое делали.

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 Dmitry Orlov on Fri, 04 Aug

2006 22:56:43 +0400:

DO>> Ясно, что реализуемо. Hа ПЛИС можно реализовать процессор, а на нем DO>> задачу,

DEO> зачем так сложно? если можно просто реализовать задачу:)

Не знаю, но так часто делают. Я себе слабо представляю средства программирования ПЛИС и как на них описать такую задачу.

dima

formatting link

Reply to
Dmitry Orlov

DO>>> Скорость в подобных местах дело десятое, это индикация, которая DO>>> всяко быстрее человека работает. А вот уменьшение объема - дело DO>>> полезное. Хотя если деление все равно используется где-то еще, то DO>>> может получиться и наоборот, надо будет проверить. DO>

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

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

сорри, привычка

DEO>> это я говорил - вниз логику переносить надо, вверху осталвляя DO>

DO> Какую логику и в какой низ? логику RS232 - вниз

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

DO> Я говорю о том времени, которое нужно на вход в DO> прерывание - сохранение контекста и что там еще делается, можно в коде DO> глянуть. для скорости 4800 это наплевать и растереть

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

DO> Этого я совершенно не понял. Ты про обработку команд, вводимых с терминала? нет про низкоуровневую реализацию RS232 старт-бит данные (от 5 до 9 бит) бит четности два стоп-бита

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

впрочем я возможно и правда сваяю демонстрашку на эту тему, ты меня заинтересовал :)

DEO>> а что не взять классическую событийную модель? DO>

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

DO> Где ты там видел что-то ждущие функции? DO>

tputstr пока не _отправит_ строку в RS не вернет управление а на скорости 2400 - существенное время.

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

DO> Именно так и делается. Внутри idle() управление на долго не задерживается, DO> только на время выполнения кода, никаких ожиданий и замкнутых циклов. хаос полный получается система разделения времени между процессами должна быть в одном месте, сами процессы в другом у тебя все в куче перемешано, закопаешься как сложнее станет :)

Reply to
Dmitry E. Oboukhov

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

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

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

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

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

до неуправляемого выпрямителя и повышалки (это будет 120-градусное потребление, косинус близок к единице получается гармоник куча поубита напрочь)

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

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

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

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 Fri, 04 Aug

2006 23:57:44 +0400:

DO>> Скорость в подобных местах дело десятое, это индикация, которая DO>> всяко быстрее человека работает. А вот уменьшение объема - дело DO>> полезное. Хотя если деление все равно используется где-то еще, то DO>> может получиться и наоборот, надо будет проверить.

DEO> у тебя пока делит - напрочь процессы внизу останалвиваются в DEO> принципе пока их немного можно и наплевать :)

В каком низу? Критично ко времени там только то, что касается UART'а.

DEO>>> код прерывания мне не понравился, хреново когда программа где-то DEO>>> в середине привязывается к конкретным числам навроде TMR0=133

DEO>>> я бы определил BAUD_RATE вверху в дефайнесах а остальное бы DEO>>> макросами бы перевычислилось.

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

DEO> это я говорил - вниз логику переносить надо, вверху осталвляя

Какую логику и в какой низ? Я говорю о том времени, которое нужно на вход в прерывание - сохранение контекста и что там еще делается, можно в коде глянуть.

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

Этого я совершенно не понял. Ты про обработку команд, вводимых с терминала? В более "взрослых" проектах у меня там только помещение в кольцевой, а то и в однобайтовый буфер (пропало - ну и хрен с ним, в конце концов оно видно на терминале, можно и перевбить символ). Ну а тут и помещение в буфер и частично его разбор я сделал в одном месте. Получилось компактней.

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

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

DEO> а что не взять классическую событийную модель?

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

Где ты там видел что-то ждущие функции?

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

Именно так и делается. Внутри idle() управление на долго не задерживается, только на время выполнения кода, никаких ожиданий и замкнутых циклов.

dima

formatting link

Reply to
Dmitry Orlov

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

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

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

а так же редактор всегда один и тот же в котором программы пишу

к большинству IDE внешние редакторы подключаются криво и неудобно, а внутренние - сколько функциональности сделали разработчики столько и есть и ничего не добавишь даже если захочешь :-\

Reply to
Dmitry E. Oboukhov


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

2006 00:00:02 +0400:

DEO>>> 99.9% программ которыми я пользуюсь невозможно скомпилить на DEO>>> MSVC а если и возможно то на это надо столько усилий вложить DEO>>> сколько никому в голову не придет

AVB>> Это проблемы пейсателей. Правильные программы собираются любым AVB>> компилятором.

DEO> а эти программы и собираются кучей компилеров, интеловским например DEO> итп вот MSVC не в кассу :) да и нет его кроме как под виндой нигде практически

Да и не надо, вида и так свыше 90% парка х86 обслуживает. Впрочем что меня меньше всего волнует, так это компиляторы для x86. Для своих поделок (а ничего кроме поделок я для РС не делаю) мне ворованого Borland Builder'а хватает или их же Delphi, что собственно практически одно и тоже. А профессионалы прикладные программы для РС сейчас все больше на C# пишут...

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 Dimmy Timchenko on Fri, 04 Aug

2006 21:58:38 +0400:

DO>>>> Последнее, что меня волнует, это наличие gcc.

DEO>>> gcc это лучший на сегодня имхо компилятор. остальные по DEO>>> сравнению с ним - поделки :)

DT>> IAR тоже поделка?

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

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

DEO> простейший мейк с wildcard'ом и с опцией gcc -MMD дает возможность DEO> пересборки проектов "лехким движением руки"

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

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

dima

formatting link

Reply to
Dmitry Orlov

Hi Dmitry,

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

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

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

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

Решил портануть несколько живых проектов. Как оказалось, ничего сложного в мейк фалах нет :) Берем из директории sample мейк файл, правим 4 верхних строчки. Список исходников, имя выходного файла, название камня, тип оптимизации. Hа то чтобы с этим разобратся ушло минуты две, из них большинство на чтение списка поддерживаемых камней. Забавно, есть наверное все, кроме меги162. За что сей камень забыли, не понятно, а жаль.

15 минут ушло на думанье какие инклуды цеплять дабы оно жило и как оформлять процедуры прерываний.

Самый сложный проект не влез в камень (мега8535). Как показали эксперименты, это из за плавучки. Относительно простые проекты, где нет плавучки у gcc получились примерно на 1-2 процента длинней код чем у иара. С учетом халявы - очень даже гуд.

При этом у иара никакая оболочка. я ее использую только для нажатия кнопки билд олл. Качество генерации ворнингов у иара - _никакое_ по сравнению с гсс. У кейла на грамм лучше, но до гсс ему тоже ой как далеко. Особенно бесит когда кейл дает ошибку или ворнинг, указывая при этом главный файл, хотя проблемная строчка находится в инклуде. Значит мне надо взять в результате и просмотреть все строчки с неким номером во всех инклудах, и найти кривую. А если инклудов штук 30?

Кейловский отладчик досих пор не соображает, что код может быть в инклудах, показывая вместо них главный файл. Дизасм соответсвенно подставляет строчки тоже из главного файла. Хотя это мелочь, отладчиком я не пользуюсь, только дизасмом и то очень редко.

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

WBR, Michael.

Reply to
Michael Zaichenko

Пpиветствую, Dmitry!

DO> АЦП можно сделать меряя постоянную времени r-c цепочки. Поясни тупому инженегру, не знакомому с аналоговой схемотехникой - это как ? t=R*C или я забыл университетский курс ? Как её померять, я понимаю, но куда здесь привязывать измеряемое напряжение ? Или ты так кратко обозвал сигма-дельта АЦП ? Типа этого

formatting link
А за компаратор - входная цепь ноги ПЛИС ?

Michael Tulupov ...

Reply to
Michael Tulupov

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

// Print 3 digit decimal with leading "=" procedure printi(byte in i) is tty = "=" var byte d = 100 forever loop // division is code consuming - make without! var byte c = "0" while i >= d loop i = i-d c = c+1 end loop tty = c if (d == 100) then d = 10 elsif (d == 10) then d = 1 else return end if end loop end procedure

// convert string to number function stoi(byte in i) return byte is var byte b = 0

forever loop var byte c = str[i] if (c < "0") then return b end if if (c > "9") then return b end if b = b + b // b * 2 c = c - "0" c = c + b b = b + b b = b + b // b * 8 b = b +c // (b * 8) + (b * 2) + (c - "0") end loop return b end function

я думаю в синтаксисе легко разобраться - а разные "некрасивые заморочки" - это проблемы компилятора JAL (типа 3 сдвига на 1 сильно дешевле сдвига на 3). Если есть желающие увидать полный текс - я его посылал Дмитрию, могу кинуть и по мылу. Там все нафиг заоптимизировано по коду - хотя может быть и компиляторо-зависимо - типа такого:

function thermo(byte in Vt_hs) return byte is if (Vt_hs > 256 - 10) then return 19 end if var byte i = (Vt_hs >> 4) << 1; // /16 *2 var byte k1 = T_table[i+0] var byte k2 = T_table[i+1] var word v = Vt_hs v = v - (i << 4) k2 = (v * k2) >> 6 return k1 - k2 end function

Reply to
Arcady Schekochikhin

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.