На чем писать  

543 пользователя проголосовало

  1. 1. Что чаще используете в разработках?

    • Assembler
      149
    • C
      277
    • Что-то еще
      56


354 сообщения в этой теме

gunya    0

Я в техникуме изучал асемблер для I8051,щас научился писать програмы для авр на асемблере.Хотелось бы выучить СИ,если у кавото есть книги для начинающих в СИ,дайте ссылку.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
$david$    0

начинаю осваивать писать на С . выбрал С потому что большинство примеров которые я нашёл было написано на нём , ну и само собой переносимость как ни крути это очень удобно . А вот ASM тоже бывает ООчень нужен так как бывает проще разобраться в листинге программы

без него то не куда . И кстати я так понял лучше пользоваться такими компиляторами как IAR ну и GCC то есть без встроеных библиотек чтоб без проблем потом переехать ежели чего на другой кристал или компилятор ИМХО это очень удобно

Изменено пользователем $david$

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
Skazzi    1

в универе учили за семестр все 3 микроконтроллера (ну всмысле аврку, пик и 51) и естессно только на асм. это первый язык программирования, который мне понравилсо! помню как я ненавидила писать курсачи и лабы на сотни страниц на с++, а тут все понятно, по полочкам (регистрам)) расставляеш как тебе удобно.. жаль, что мало пар было, но собираюсь изучать дальше.

  • Одобряю 1

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
pirotehnick    0

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
letni    0

хорошо знать и асм и си.. а там все зависит от поставленной задачи

асмовские вставки в си иногда очень хорошо помагают

хотя все же большее предпочтение отдаю Си, там все одинаково и для всех одинаково

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
aahz    0

когда начинал писать программы на ассемблере для старого-доброго синклера, уяснил, что сначала нужно блок-схему составить, а уж потом, программу писать. так вот, Algorithm Builder это оптимальный вариант: составляется блок-схема и ЭТО И ЕСТЬ программа. хотелось бы узнать мнение других людей по поводу работы в Algorithm Builder.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
ilmar    0

Для с51 контролера пишу на Bascom-8051(Бейсик но с небольшими своими особенностями :) ) , сейчас заказал AVR микрухи и наверно буду писать уже пожалуй на Bascom-AVR ( то же самое но с поправками на авр).

К сожалению си знаю плохо :( , неплохо знаю паскаль, но жаль для МК такие языки не встречаются :(

На Асме писать пожалуй конечно хорошо, и код маленький и проц менее загружен, но для этого надо знать полностью архитектуру соответствующего контролера. А я больше любитель , чем профессионал, и поэтому изучать каждый МК времени не хватит :(

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
Sergyk    0

Бесполезный спор!!!!!!! Сначала ставиться задача под нее выбирается камень,а потом основываясь на задачи и типе камня выбирается язык и составляется алгоритм!!!!!

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
Migray    5

Сначала ставится ЗАДАЧА, потом составляется АЛГОРИТМ, ну и только после этого можно что-то сказать о камне.

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

На голом асме большой проект с математикой сложно написать.

Среда программирования - на вкус, наверно.

Я предпочитаю IAR, в силу ее универсальности, т.е. она работает практически с любым МК.

Да и возможности отладки там хорошие.

Хотя для западных стран эта среда стоит денег.

P.S. Не вижу большой разницы между Си и Паскалем.

Организация циклов и структура программы одинакова.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
Goodefine    95
Сначала ставится ЗАДАЧА, потом составляется АЛГОРИТМ, ну и только после этого можно что-то сказать о камне.

Зачастую алгоритм сильно зависит от возможностей применяемого камня. Поэтому после ЗАДАЧИ идет ТЕХНИКО-ЭКОНОМИЧЕСКИЙ РАСЧЕТ из нескольких итераций, в котором участвуют подходящие камни с оценкой затрат на программирование оных. Меньше флэша - стоимость камня меньше, затраты на программирование (степень детализации алгоритма) больше, и наоборот... Поэтому, АЛГОРИТМ и выбор камня скорее параллельные процессы...

P.S. Не вижу большой разницы между Си и Паскалем.

Здесь была обширная дискуссия по этому поводу...

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

Зато реализующий код существенно длиннее

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
Migray    5
P.S. Не вижу большой разницы между Си и Паскалем.

Здесь была обширная дискуссия по этому поводу...

Потому я и не появляюсь больше на электрониксе, слишком много пустой болтовни.

Компиляторов Паскаля для МК не много, не для всех камней есть, и с этим основные проблемы.

Но в свое время, примерно в 92-м году изучал Паскаль и Си для персоналок, потом естественно Дельфи и Билдер, без проблем могу написать прогу на том, что в данный момент стоит на компе. Большой разницы не вижу, если чесно.

Для МК специально не сравнивал, просто лениво.

Собственно из-за лени и выбрал IAR (Си), дабы не изучать еще что-то, если придется менять проц.

Если-бы увидел столь-же всеобъемлющий компилятор с Паскаля, возможно работал-бы в нем.

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

Зато реализующий код существенно длиннее

Ну ни кто не мешает объявить новый тип, правда придется для каждой переменной отводить по байту.

Можно даже в программе написать "True" и "False" вместо "1" и "0"

Кстати многие МК могут работать с битами на уровне команд, и для них хороший Си компилятор сформирует оптимальный код, без использования масок.

А вообще, возвращаясь к теме, для новичка хорош тот язык, на котором есть куча примеров, а для профессионала - сам выберет, в зависимости от желания :)

Учиться все равно придется постоянно :)

Изменено пользователем Migray

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
Kolyanych    0

Я использую CodeVisionAVR и симуляторы VMLAB PROTEUS - очень удобно.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
Migray    5

Алгоритм работы проца естественно зависит от его возможностей.

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

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

Тут Goodefine прав, итераций может быть немало.

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

Возможно мы недопоняли друг друга, будем считать эти 2 этапа, железо/алгоритм взаимосвязанными.

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

1. - Смотрим, что есть для данного конкретного железа.

2. - Шеф сказал - пишем все на ххх - значит все :(

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
rtfcnf    1
2. - Шеф сказал - пишем все на ххх - значит все :(

А мы раз шефу на фразу «пишем на …» Ответили да пошел ты

Те, кто уволились так и пишут на IAR

Да и те, кто остался то же пишут на IAR

:D:D:D

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
Зачастую алгоритм сильно зависит от возможностей применяемого камня...

Но все же в большей степени от применяемого компилятора (видели бы вы кучу бесполезного кода от применения стандартных библиотек и макросов, натыканных языками высокого уровня). Поэтому я предпочитаю писать исключительно на ассемблере, хотя год назад для меня он был "темный лес". Теперь удается "сжать" чужую "пляску" в несколько раз(!). Вот только что "причесал" одну прошивку (после дизассемблирования). Код уменьшился с 13,8кБ до 5,5кБ при полном функциональном соответствии.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
p486    6

когдато писал на паскале. теперь 90% всего кода пишу на Си.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Программирование не люблю последнее время:)

Не смотря на это неплохо владею асмом, пишу под авр, пользуюсь одним из самых старых - АВР макроасм в.1.3.

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

Ну если любитель станет перед вопросом ужимать код или доплатить 0,5$ за большее кол-во флеша, то выбирается, как правило, второе. А для владеющих асмом остаются широчайшие возможности полного использования ресурсов, а флеша в 64кб хватит на несколько недель извращенной фантазии...

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

Каждому свое и спорить что лучше, двольно бессмысленно...

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
gvl    1

Это мнение касается только АВР - и не только...

Вопрос ("Кто на чем чаще пишет для Avr и не только?"), конечно, важный!

Но не самый главный при разработке устройств - к нему мы ещё вернёмся.

Конструктору(радиолюбителю, разработчику...) Програмно-Аппаратных Комплексов(ПАК) важны некоторые "тонкости проектирования" с использованием МикроКонтроллеров(МК). Итак попробуем разобраться...

В начале, рассматриваются общие вопросы, такие как выбор МК(как базового типа), возможности наращивания(расширения) функциональности разрабатываемых устройств на его основе и т.д.- легче работать с одним МК, который в результате узнаётся до корочки, чем прыгать по разным типам(ещё 5 лет назад мной сделан выбор - mega128(тогда это было круто, но этот выбор оказался правильным...)).

Далее разбивается задача на аппаратную и программную части. Чем больше будет решаться задача аппаратной частью - тем меньше остаётся для программной части (в этой части xmega здорово помогает).

После этого изучается вопрос минимального времени ответа устройства на внешние события.

Если это порядка 100..200мс - то лучше программировать на ЯзыкахВысокогоУроня(ЯВУ)- не забивать себе голову всякой ерундой(всё и так получится и, что будет сказано ниже, Вам это не нужно), а если критичное время АПК составляет, например, 1мс (при опросе других mega128, связью контроля на PC, командами на нижний уровень по иерархии RS485 ... ), то,конечно, Вы мой "слушатель и вниматель" (идея упёртости - зачем мне знать другое, если это можно сделать и на том, что я знаю и мне это лучше известно...? - mega128 - "Это же просто..."), потому,что если Вы не ушли на другой МК(xmega,ARM..) - Вы поймёте, почему никто в мире Widows не использует ассемблер..., а только Си(особенно) и прочие!

(

Тут необходимо немного отвлечься от предмета разговора и однозначно ответить на "больной вопрос о Паскале".

Паскаль - потокобезопасный! Это означает только одно - если Вы хотите сделать надёжное приложение(программу) в крачайшие сроки (без всяких прибабахов), то он Вам помощник уже на этапе составления(компиляции) программы - убережёт от многих ошибок уже на стадии написания исходников - типизация данных, проверка типов и т.д. И не путайте Delphi с ObjectPascal!

Дальнейшее продолжение Object Pascal - OBERON(Никлаус Вирт и его последователи) - он доступен в понимании и его описание есть на многих русско-язычных сайтах(engl даже для ARM7(2005)). OBERON набирает обороты, а Delphi - это отряд без командира...

)

Продолжение следует...

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
gvl    1

А зачем эта тема? Что-бы незнающим головы морочить?

Милостивый, погодите, продолжение последует!

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
Goodefine    95
А зачем эта тема? Что-бы незнающим головы морочить?

...

Ааа... Ну просветите незнающих... Походу, истинный путь только Вам известен...

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Что-то мне не нравится второй абзац данной статьи. Мне видится какой-то подтекст. К чему она призывает "незнающих"? Не заморачиваться с познаниями? Не развиваться как специалистам, изучая разнообразные типы МК? Это очень похоже на речь конструктора, но не радиолюбителя. Хотя если второй, почти всегда бывает первым, то первый далеко не всегда бывает вторым.

Извини, gvl, но я тебя, честно, не понял. Значит, "зачем забивать себе голову всякой ерундой", достаточно познать элемент 2И-НЕ и ты уже "цифровик"? Ведь на нем (2И-НЕ) можно собрать большой набор схем различного направления. Вот только габариты могут быть огромные (как ресурсы, сжираемые Windows). Все-таки, для правильного выбора МК, радиолюбитель должен знать все типы, из которых будет выбирать тот или иной для своей, конкретной схемы. Опять же не все радиолюбители в домашних условиях (не путать с производственными возможностями конструктора) могут позволить приобресть себе, перечисленные тобой, типы МК. Просто их нет в продаже, в их местности. Вот поэтому на форуме есть всякие МК (кто что нашел). И чем больше человек их познает, как я думаю, тем лучше. Больше у "корифеев" будет конкурентов. :) И это хорошо.

  • Одобряю 1

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
gvl    1

Goodefine “А оно надо?...”

Конечно надо! Сам был в этой ситуации и не мог получить ответ на вопрос “На чем программировать?”. На этом форуме – тоже не увидал. Встречный вопрос – он же ответ: “Почему количество просмотров этой ветки так велико?”.

Геннадий

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

"Зачем забивать себе голову всякой ерундой" - наверно фраза не доскональная, но в общем верная. Например, зачем разбираться в организации работы SPI в каждой конкретной ситуации или как сделать обработку квадратурного датчика с частотой 150 кГц...

МК – это инструмент для достижения поставленной задачи – чем лучше Вы владеете инструментом – тем больший круг задач Вы сможете решить (мастерство не утаишь!). Если Вы знаете досконально несколько МК – честь Вам и хвала.

Так вот, если Вы радиолюбитель-конструктор, Вам надо досконально знать тот(те) МК, который(е) Вы выбрали как базовый(е). Надо знать возможности МК и пути решения задач - помочь будет некому.

  • Не одобряю 1

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
Goodefine    95
...Конечно надо! Сам был в этой ситуации и не мог получить ответ на вопрос “На чем программировать?”. На этом форуме – тоже не увидал...

И не увидите. Тем более не дадите. По той простой причине, что однозначного, верного ответа на нет. И не только на этот вопрос...

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Создайте аккаунт или войдите в него для комментирования

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

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!

Зарегистрировать аккаунт

Войти

Уже зарегистрированы? Войдите здесь.

Войти сейчас


  • Похожие публикации

    • Автор: Alexey104
      Всем привет!
      Возникла следующая проблема:
       
      Есть две ардуины 'Mega2560'. По несчастливому стечению обстоятельств данные платы попали в руки одному чуваку, который, вернув их, заявил, что они перестали работать после того, как он "чисто ради интереса" поковырял на обеих некоторые фьюзы. Есть у меня такой китайский usbasp v2 программатор:
      Подключив данный девайс к ICSP-пинам первой платы, удалось без проблем восстановить на ней загрузчик через стандартную Arduino-IDE, после чего работоспособность платы полностью восстановилась. Но вот при попытке сделать то же самое со второй платой, получаю это:
      Такое же сообщение получаю при попытке зашить загрузчик в неподключенную к программатору ардуину, то есть программатор вообще не видит МК. Плата прекрасно работала до того, как вышеупомянутый товарищ покрутил настройки фьюзов.
       
      Что я пытался предпринять:
      Замыкал пины JP3 программатора, отвечающие за понижение скорости, подключал к ардуине 5V от внешнего источника при прошивке загрузчика, - не помогло.
       
      Поиском пользоваться умею, аналогичную тему тут находил, но там проблема была в том, что парень неверно подключал программатор к контроллеру. В моём же случае всё подключено верно, повторюсь, что загрузчик первой платы этим же программатором был восстановлен успешно.
      Буду рад любым советам касательно того, как восстановить работоспособность платы.
       
       
       
    • Автор: Ru_s
      Здравствуйте. Подскажите пожалуйста, возможно ли на attiny13 реализовать такую штуку. Мне в процессе работы программы нужно поменять режим работы таймера/счетчика с fast PWM на обычный счёт, отсчитать длительный промежуток времени и опять вернутся в режим ШИМ. Т.е. я подаю на ногу сигнал ШИМ и когда он в максимальном значении, я его отключаю, и тупо подаю на ногу высокий лог. уровень. В это время Т/С по идее свободен, и мне надо посчитать время работы выхода на максимальном лог. уровне, при достижении какого-то значения времени нужно перевести т/с обратно в ШИМ. Возможно ли это? И как приблизительно это реализовать
    • Автор: ShimkoMax
      Здравствуйте. Требуется вывести данные температуры и влажности на экран. С LCD дисплеем разобрался, осталось разобраться с SHT21. Постоянно выводит 0 на дисплей:
      Main.c:
      #define F_CPU 8000000UL #include <avr/io.h> #include <avr/interrupt.h> #include <util/delay.h> #include <stdio.h> #include <stdlib.h> #include "globals.h" #include "LCD_lib.h" #include "twi.h" // I2C #include "sht21.h" int main(void) { I2C_Init(); _delay_ms(100); LCD_init(); char buffer[20]; roomAdrInit(); SHT21_reset(); while(1) { SHT21_reset(); LCD_sendString(itoa((int)get_temperature(), buffer, 10), 4, 0, 0); _delay_ms(1000); } } twi.c:
      #include <avr/io.h> #include "twi.h" void I2C_Init(void) { TWSR = 0; TWBR = 0x20; TWCR = (1<<TWINT) | (1<<TWSTA) | (1<<TWEN); } void I2C_StartCondition(void) { TWCR = (1<<TWINT)|(1<<TWSTA)|(1<<TWEN); while(!(TWCR & (1<<TWINT))); } void I2C_StopCondition(void) { TWCR = (1<<TWINT)|(1<<TWSTO)|(1<<TWEN); } void I2C_SendByte(uint8_t data) { TWDR = data; TWCR = (1<<TWINT) | (1<<TWEN); while(!(TWCR & (1<<TWINT))); } unsigned char I2C_ReadByteAck(void) { TWCR = (1<<TWINT) | (1<<TWEN) | (1<<TWEA); while(!(TWCR & (1<<TWINT))); return TWDR; } unsigned char I2C_ReadByteNak(void) { TWCR = (1<<TWINT) | (1<<TWEN); while(!(TWCR & (1<<TWINT))); return TWDR; } sht21.c:
      #define F_CPU 8000000UL #include <avr/io.h> #include <util/delay.h> #include <stdlib.h> #include <stdio.h> #include "twi.h" #include "sht21.h" void SHT21_reset() { unsigned char reg[1]; reg[0]=SHT21_reset_cmd; I2C_StartCondition(); I2C_SendByte(SHT21_i2c_write); I2C_SendByte(*reg); I2C_StopCondition(); _delay_ms(100); } uint16_t checksum(unsigned char data[],uint8_t byte, uint8_t check) { uint8_t crc=0; uint8_t bytectr,bit; for (bytectr=0; bytectr<byte;bytectr++) { crc^=(data[bytectr]); for (bit=8;bit>0;bit--) { if(crc&0x80) { crc=(crc<<1)^polynomial; } else { crc=crc<<1; } } } if (crc!=check) { return 0; } else { return data; } } void write_user_register() { unsigned char reg[3]; reg[0]=user_register_write; reg[1]=0x44; I2C_StartCondition(); I2C_SendByte(SHT21_i2c_write); I2C_SendByte(*reg); I2C_StopCondition(); } uint16_t read_value(uint8_t reg) { char data[4],crc; uint16_t result; data[0]=reg; I2C_StartCondition(); I2C_SendByte(SHT21_i2c_write); I2C_SendByte(reg); I2C_StartCondition(); I2C_SendByte(SHT21_i2c_read); data[1] = I2C_ReadByteAck(); data[2] = I2C_ReadByteAck(); crc=I2C_ReadByteNak(); I2C_StopCondition(); result=(data[1]<<8) | data[2]; checksum(result,4,crc); result &= 0xFFFC; return result; } float get_humidity() { //char buffer2[4]; uint16_t hum_value = read_value(humidity_hold_mode); return -6 + 125.0 / 65536.0 * hum_value; //dtostrf(rh,5,2,buffer2); _delay_ms(100); } float get_temperature() { //char buffer1[4]; uint16_t temp_value = read_value(temperature_hold_mode); return -46.85 + 175.72 / 65536.0 * temp_value; //dtostrf(tc,5,2,buffer1); _delay_ms(100); }  
    • Автор: GeloMik
       
      Я новичок в программировании AVR контроллеров, хотя знаю +/- C++.
      Проблема заключается в том, что я не могу написать прошивку к своему маленькому проекту. Используемый мною контроллер - ATTiny45. У него на борту имеется 1 АЦП с выходом на 4 ноги. Нужно, чтобы фактически одновременно брался замер с 3, 4 и 5 порта по АЦП, и при появлении 1 на одном из них МК должен подать 5В на 1 или 2 порты. Источник АЦП AREF. 
      Сюда прикреплю схему самого робота, если кого не затруднит помочь написать прошивку, буду очень благодарен 

  • Сообщения

    • На глаз не скажешь, нужно смотреть по току. Ещё по фото непонятно, там под каждый диод идёт 4 площадки, это для охлаждения или в одном корпусе 2 светодиода.
    • каждому железу - свое решение по управлению. Вы же не удивляетесь, что мощные полевики с огромным входным сопротивлением, требуют драйвера с низким Rвых. Ну вот и для управления биполярниками, желая получить хороший результат, совершенно необходимо пропорционально токовое управление и отрицательное смещение базы. Дополнительная токовая обмотка, состоящая всегда (другого не видел) из двух витков, совместно с обмотками в цепях баз, образуют своеобразный трансформатор тока. Ток базы (ток управления) оказывается пропорциональным току коллектора. Открытый ключ насыщен. При запирании к базе прикладывается отрицательное напряжение, ускоряющее запирание. Отрицательное напряжение получается за счет базовой R-C-VD цепочки. В ATX данной цепи (резистор 300кОм б-к) не бывало   
    • Как то главный инженер докопался до дежурного на подстанции: "Чего это у тебя стакан на подоконнике? Пьёшь?!?" (а стакан обычный, гранённый), он: "Да, пью - воду из колодца, стакан через окно и поставил на подоконник!". А на подстанции реально колодец возле соседнего окна... Инженер: "Ты это, убери стакан с подоконника, а то солнце через стекло окна и стакан сфокусируется на полу, и подожжёт ленолеум - сгорит же вся аппаратная!". Мы все и попадали со смеху...
    • вы извините из какой берлоги выползли? APNOT = APPLICATION NOTE (применение) IR = International Rectifier - производитель тех самых мосфетов и драйверов к ним http://irf.ru/html/library.html
    • нате вам https://www.olx.ua/obyavlenie/radiostantsiya-sony-little-john-icb-600-IDB2pVY.html#d62d3efbba
    • Продам отличный цифровой осциллограф RIGOL DS1102e. Состояние нового (потертостей и царапин нет), пользовался мало и аккуратно, не ронял, не грел, не морозил, повышенной влажности не подвергал, все время стоял в комнате. Не разбирал, присутствует заводская пломба. Даже коробка сохранилась. В комплекте отдаю два почти новых щупа 100 МГц (не родные, у родных испортил колпачки-захваты, могу отдать и их). Продаю, т.к. пользуюсь им мало плюс на работе есть целый зоопарк приборов. Основные характеристики: 2 канала. Полоса - 100 МГц. Макс. частота дискретизации: 1Гвыб/с (реальное время), 25 Гвыб/с (эквив.режим). Макс.память: 1М точек. Входной импеданс 1МОм. Цифровые фильтры. Курсорные и 20 автоизмерений. Интерфейс: USB Device/Host, RS-232, P/F Out  Цена видится 13000р, но возможен разумный торг. Возможна доставка почтой, либо ТК. Прибор находится в г. Ростов-на-Дону.