не понял

Разве что по части поддержки внешней памяти комманд... Что ИМХО не есть большим недостатком. Внешняя память данных у AVR в наличии (мега8535 к примеру), особой урезанности набора комманд не чувствуется по сравнению с 8051 (программил под оба). Немного меньший набор комманд AVR (ибо RISC) с лихвой компенсируется скоростью - 1 комманда на такт, а не на 4 такта (в классическом ядре - 12 тактов).



Нет. Это - попытка упростить написание прикладного ПО, для сравнительно больших проектов (для мигалки из 3 лампочек ОС - явно избыточна ). + гибкость по части расширения/модернизации этих проектов. Ценой увеличения кода и потери в скорости.
Как пример - допустим, тот же "умный свич" с веб-интерфейсом. Докрутить к нему SNMP к примеру, если прошивка писана с нуля на С (а еще "лучше" - на асме), если TCP-стек кастрирован по максимуму и тесно переплетается собссно c кодом HTTP-сервера - ибо так сделал кодер для уменьшения размера кода и впихивания в конкретный кристалл - задача явно не из легких Если же все это сделано с пользованием общего "ядра" с основными функциями - и разработка, и доработка будут проходить куда быстрее и проще.

+ ко всему - если нет желания пользовать всю ОС, никто не мешает из нее выдрать модули поддержки сетевых протоколов



Почему же скорость передачи невысокая? десяток-другой килобит выжмется при желании ИМХО. А контроль коллизий, потерь пакетов и т.д. - вещь просто необходимая. И изобретать велосипед здесь ИМХО не нужно - если сеть предусматривает один "главный хост", то реализовать Token Ring или нечто подобное (не обязательно 100% идентичное по части структуры пакетов - взять только идею), если же сеть предусматривает как минимум несколько равноправных девайсов - реализовывать ethernet-подобный протокол (ИМХО он более правильный для такого случая).
А что налепливать сверху - IP, или свое что-то - уже 2й вопрос... Для сети из 3 девайсов можно и примитивный самодельный протокол слепить, для более-менее большой сети - ИМХО предпочтительнее TCP/IP реализовать, преимуществ по сравнению с самоделкой много...

раздел называется
" Общая информация о проектах
Прочтите эту информацию! Тут говорится о том, как стать участником проекта, каковы правила и условия работы над проектоами и т.п. важные сведения. " ???

хотелось бы всётаки увидеть открытый раздел для этого .


Eugene , всёже на приведённых вами сайтах информации о МК очень мало . для вас лучше почитать ДШ , к тому же я считаю что программист должен писать программы для МК на асме . С# на МК , как я считаю , для программиста семечки , и не стоит ими увлекаться .

нет, не только! на этом форуме была дискуссия - тут не место, скажу лишь кратко: современное 51-е семейство превосходит 8-разрядные PIC и AVR по максимально достижимому быстродействию, по встроенной периферии, по системе прерываний с приоритетами и т.п.

что касается FreeRTOS - очень сомневаюсь лишь в одном: что с использованием ее получится сделать "умный" выключатель лампочки на tiny2313 или даже atmega48 (а я вообще мечтал о тини13 или хотя бы тини25)- а значит, стоимость девайса станет бассмысленно высока - это убъет саму идею сделать "умный дом" своими силами - разве что китайцы снова слямзят идею и наплодят дешевки...

Читать незарегистрированные пользователи смогут?
Вероятно некоторые захотят присоединиться в процессе.

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

Про это, вроде как, я писал, ну да ладно.. Господа! Давайте или ближе к теме, или молча, договорились?

NiTr0: Я тоже считаю что контроль коллизий необходим, но к примеру в протоколе Х10 он небыл реализован.
LINKS_234: Ну datasheets почитать - это само собой! Просто на С код получается компактней чем на асме, из за этого и выбор пал на него. А про C# на МК я, если честно, и не слышал.

подразумевался обычный С . я просто не знаю в чём разница между С , С+ и С++ .
лично мне в высокоуровневых языках для МК не нравится то , что нельзя контролировать программу и данные . как компилятор захочет , так и переведёт всё на асму. если бы я знал асму , то плюнул бы уже на этот С - бог с ним , с объёмом кода , главное компактная прошивка и полный контроль МК .

Что совсем не является достоинством протокола.
Хотя в протоколе token ring к примеру (и других с одним привелегированным хостом) - контроль коллизий не нужен. Потому что им неоткуда взяться, и потеря пакета ни к чему катастрофическому не приведет.

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

были же ещё самодельные переговорные устройствам по сети

всё новое хорошо забытое прошлое

Понятно были, только кто искать будет.
Лень.
Вот Вы например даже на соседнюю страничку не удосужились посмотреть прежде чем такую свежую мысль выдавать.

Привет Всем.

Задача: мониторить по силовой сети состояние оборудования: датчики температуры, давления, скорости потока и т.п., опрашивая всё это раз в секунду. Вся информация с датчиков сбрасывается в МК, на выходе которого в общем можно организовать любой интерфейс. Всё осложняется тем, что канал должен быть однонаправленным, а значит с контрольными суммами или прочим защитным кодированием. Есть типовые решения Powerline, например MAX2981, MAX2991. Но это заточено под большие скорости передачи (Ethernet сети), а стоимость велика. Поиск в google даёт ссылки только на готовые модемы и устройства, вроде бытовых счётчиков.

Собственно вопрос. Есть объективные подозрения, что те же MAX не будут работать в промышленных сетях, когда на стороне 0,4-0,6 кВ стоят тиристорные преобразователи, синхронный/асинхроный привод и, как результат, целое семейство гармоник, наводок и т.п.

Может, кто-нибудь сталкивался с такой задачей? Если да, то как наиболее правильно в смысле цена/надёжность к ней подступиться?

Какая протяженность трассы передачи.

Протяжённость линии до 2 км.

В данном случае всего два вариата (в смысле денег)
1 радиоканал
2 если есть возможность протяжки кабеля RS485
По поводу стоимости ETH мне HTTP сервер обошолся ENC28J60-120р
Atmega168 -110р и мс34063 2шт по 18р(переферию я не учитываю,дачик давления стоит как два таких сервера)

я делал по 220
скорость была около 50 байт в сек, но это по максимуму
дальность - до 2 км

делал на нашей микросхеме 1446 дальше не помню
Проц - были версии и под PIC, и под AVR

схема - типовая, из даташите на м-му, только выходной каскад там слёзы. Все переделывали, и транс надо мотать другой

Была версия и под "рассыпуху": включить - выключить / есть тон, нет тона
она получилась надёжнее даже

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

За КР1446ХК1 спасибо. Об отечественых решенииях не знал.
Насчёт "рассыпухи". Макет я собрал модулятор->развязка->развязка->демодулятор. Разница между нулём и единицей около 4кГц. На стороне приёмника частоту меряю на входе ICP MК. На столе всё работает, на производстве - нужно собирать статистику о пятистах замерах длительности чтобы с вероятностью 0,5 гарантировать 0 или 1. По времени неэкономно, а о точности я молчу. Пробовал на разных частотах 20-100 кГц, результат одинаковый.

я как делал:
сделал развязку от сети, спектроанализатором (простеньким) глянул "картинку эфира"
увидел, что помехи меняются от времни суток (бытовой сектор)
выделил группы, где уровни помех выше - их не использовал для вещания
Затем гнал в сеть сигнал, по всему дому проверил (частный дом) - это на рассыпухе BA1604 (она же NE567)

нашу 1446 я не советовал бы использовать: они их выпускают под заказ - я с ними переписывался
ко всему, м-ма не вылизана, это написал её разработчик на одном из форумов. Также он сказал о своем увольнении.

ищите типовую TDA5051, хотя она устарела...

моуг прислать всё, что есть - 45 мб