Форум программистов «Весельчак У»
  *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

  • Рекомендуем проверить настройки временной зоны в вашем профиле (страница "Внешний вид форума", пункт "Часовой пояс:").
  • У нас больше нет рассылок. Если вам приходят письма от наших бывших рассылок mail.ru и subscribe.ru, то знайте, что это не мы рассылаем.
   Начало  
Наши сайты
Помощь Поиск Календарь Почта Войти Регистрация  
 
Страниц: 1 2 [3]  Все   Вниз
  Печать  
Автор Тема: Задача: проблесковый маячок с сигналом SOS.  (Прочитано 97768 раз)
0 Пользователей и 2 Гостей смотрят эту тему.
v2
Помогающий

ua
Offline Offline

« Ответ #60 : 25-11-2011 21:14 » 

Вариант добавки:

Подзадача 1: (минимум)
 Необходимый базовый функционал, озвученный в начале темы.

( Представим, что наш маяк имеет канал связи (Uart + простенький протокол))

Подзадача 2: (расширения - коммуникация)
 Сбор и передача телеметрии  (ветер, температура, давление,  влажность,  освещенность, _SOS_ ) ,
  минимум - индикация состояния рабочих входов/выходов и временная метка;

Подзадача 3: (расширения - пользовательский интерфейс)
 Реализовать меню (а-ля ЖК(2х16)+4кнопки через тот же  Uart  ) посредством которого диспетчер будет иметь возможность
 просмотреть/изменить  параметры работы маяка и, при необходимости, просигнализировать (LED) потерпевшим
 о принятии сигнала бедствия.

 =>  Использование одного "долгоиграющего" аппаратного ресурса несколькими подзадачами
 =>  Ожидание и обработка ввода пользователя

Подзадача 4: (гипотетическая)
 Тяжелый фоновый  процесс - например, расчет  волнения, используя бортовой акселерометр.
 (Не знаю как, но по выч. ресурсам должен быть затратным )

  ( Если тестировать, то и "эффективность труда" микроконтроллера )
 => Значение инкремента в фоне на единицу времени  даст возможность оценить   варианты   реализации
      по производительности и  расширяемости.

ЗЫ.
Возьмусь вышесказанное  воплотить в код, используя независимые (uOS) потоки (потому как UI на "автоматах" – сложная штука).






Записан
Dale
Блюзмен
Модератор

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #61 : 25-11-2011 21:19 » 

Считаю, что для задачи более сложной, чем Hello, word, эта вполне подойдет.

"Эта" - в смысле которая с двумя мигалками и морзянкой, сформулированная в начале темы?

С другой стороны... ммм... дождуссь коментов по поводу статьи.

Это... гммм... тех самых, обещанных (не к ночи будь упомянуты)? Коллега, будем оптимистами, может, еще все обойдется. Новолуние было только вчера, следующее только через месяц, к тому времени статья может и подзабыться, если оставшиеся две части будут быстро опубликованы (есть реальный стимул поторопиться). Опять же, тема про Белоруссию - отличный громоотвод, принимает на себя основной удар, на нее все надежды. Может, еще кто из братских республик выручит? Я отблагодарю при первой возможности, честное слово. Посвящу вам следующую статью.

Ибо нефик тут словами разбрасываться. Итак всего букв 33.

Эх, ваши бы слова - да Богу в уши... Зато сколько потенциальных комбинаций! Однобуквенных фраз только 34 (с пробелом), двухбуквенных - 342, ... n-буквенных - 34n. А если учесть, что n при разбрасывании редко бывает меньше 10.000, прогноз вовсе не радует. Боюсь, во Вселенной столько атомов нет. Пропал калабуховский дом...

Добавлено через 10 минут и 40 секунд:
Вариант добавки:

Подзадача 1: (минимум)
 Необходимый базовый функционал, озвученный в начале темы.

( Представим, что наш маяк имеет канал связи (Uart + простенький протокол))

На моем прототипе есть преобразователь TTL <-> RS232, так что этот вариант легко реализуем без накладных расходов. Можем и обратный канал сделать.

Подзадача 3: (расширения - пользовательский интерфейс)
 Реализовать меню (а-ля ЖК(2х16)+4кнопки через тот же  Uart  )

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

Возьмусь вышесказанное  воплотить в код, используя независимые (uOS) потоки (потому как UI на "автоматах" – сложная штука).

Замечательно. Тогда я начну со standalone версии, а потом как развитие прикрутим к ней ОС.
« Последнее редактирование: 25-11-2011 21:29 от Dale » Записан

Всего лишь неделя кодирования с последующей неделей отладки могут сэкономить целый час, потраченный на планирование программы. - Дж. Коплин.

Ходить по воде и разрабатывать программное обеспечение по спецификациям очень просто, когда и то, и другое заморожено. - Edward V. Berard

Любые проблемы в информатике решаются добавлением еще одного уровня косвенности – кроме, разумеется, проблемы переизбытка уровней косвенности. — Дэвид Уилер.
RXL
Технический
Администратор

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #62 : 25-11-2011 22:13 » 

Собственно, выпустить все части скопом не проблема.
Записан

... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
Dale
Блюзмен
Модератор

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #63 : 25-11-2011 22:35 » 

Собственно, выпустить все части скопом не проблема.

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

А я пока потихоньку начну новую тему, благо v2 выразил желание помочь реальным делом. Эта тенденция весьма радует.
Записан

Всего лишь неделя кодирования с последующей неделей отладки могут сэкономить целый час, потраченный на планирование программы. - Дж. Коплин.

Ходить по воде и разрабатывать программное обеспечение по спецификациям очень просто, когда и то, и другое заморожено. - Edward V. Berard

Любые проблемы в информатике решаются добавлением еще одного уровня косвенности – кроме, разумеется, проблемы переизбытка уровней косвенности. — Дэвид Уилер.
RXL
Технический
Администратор

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #64 : 26-11-2011 08:02 » 

Тогда предлагаю слегка форсировать до двух выпусков в неделю. Пятую часть я опубликовал в среду. Рассылка выйдет сегодня.
Записан

... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
Sla
Команда клуба

ua
Offline Offline
Пол: Мужской

WWW
« Ответ #65 : 26-11-2011 09:19 » 

Цитата
потому как UI на "автоматах" – сложная штука
Т.к. не увидел смайлов, то посчитал это серьезным заявлением.
Описать состояния интерфейса, жестко прописать в таблицу.
Переходы на п/п по адресу в таблице.
Записан

Мы все учились понемногу... Чему-нибудь и как-нибудь.
Dale
Блюзмен
Модератор

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #66 : 26-11-2011 13:15 » 

Цитата
потому как UI на "автоматах" – сложная штука
Т.к. не увидел смайлов, то посчитал это серьезным заявлением.

Сложность - категория весьма относительная и субъективная:

Цитата
На наше формирование большое влияние оказывают инструменты, которые мы используем, в частности: формализмы, которые мы используем, формируют наш образ мышления лучшим или худшим образом, и это значит, что мы должны быть чрезвычайно осторожны в выборе того, чему учить и чему учиться, потому что разучиться потом совершенно невозможно.
(Дейкстра, "Ответы на вопросы студентов отделения программного обеспечения EWD1305"). Впрочем, хватит философствовать, пока не накликали беду.

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

Описать состояния интерфейса, жестко прописать в таблицу.
Переходы на п/п по адресу в таблице.

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

Всего лишь неделя кодирования с последующей неделей отладки могут сэкономить целый час, потраченный на планирование программы. - Дж. Коплин.

Ходить по воде и разрабатывать программное обеспечение по спецификациям очень просто, когда и то, и другое заморожено. - Edward V. Berard

Любые проблемы в информатике решаются добавлением еще одного уровня косвенности – кроме, разумеется, проблемы переизбытка уровней косвенности. — Дэвид Уилер.
v2
Помогающий

ua
Offline Offline

« Ответ #67 : 26-11-2011 14:51 » 

(потому как UI на "автоматах" – сложная штука).
Для меня и, скорее, психологически.




Записан
RXL
Технический
Администратор

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #68 : 02-12-2011 04:13 » 

Предыдущая статья полностью опубликована.
https://club.shelek.ru/viewart.php?id=354
https://club.shelek.ru/viewart.php?id=355
https://club.shelek.ru/viewart.php?id=356
https://club.shelek.ru/viewart.php?id=357
https://club.shelek.ru/viewart.php?id=358
https://club.shelek.ru/viewart.php?id=359
https://club.shelek.ru/viewart.php?id=360
Записан

... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
Dimka
Деятель
Команда клуба

ru
Offline Offline
Пол: Мужской

« Ответ #69 : 08-12-2011 22:45 » 

Ну вот, после отзыва можно вернуться к теме.

Есть следующее предложение по содержанию задачи: световой телеграф.

Это устройство, которое соединено с компьютером по COM или USB, получает от компьютера текстовые сообщения в свой буфер и "намигивает" их лампочкой.

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

Со стороны host-машины для общения с устройством нужно иметь 3 протокола (или 3 направления взаимодействия):
1) Разные настройки - например, скорость вывода.
2) Загрузка текста в буфер устройства.
3) Чтение состояния и управление (остановка, запуск, сброс и т.п.)
Записан

Программировать - значит понимать (К. Нюгард)
Невывернутое лучше, чем вправленное (М. Аврелий)
Многие готовы скорее умереть, чем подумать (Б. Рассел)
zubr
Гость
« Ответ #70 : 09-12-2011 11:44 » 

Лет 10 назад я что то подобное делал, правда там было наоборот: к LPT-порту был подключен ключ отстука, а в окне программы отображался текст, отстученный на ключе морзянкой.
Записан
Dale
Блюзмен
Модератор

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #71 : 29-05-2014 06:18 » 

Цитата
Ну, граждане алкоголики, хулиганы, тунеядцы – кто хочет поработать?

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

Итак, вкратце.

Основная задача: повысить качество разработки встроенных систем с микропроцессорами с одновременным уменьшением временных затрат за счет более тщательного тестирования как отдельных блоков, так и системы в целом. Акцент делается не на soft и не на hard (в обеих областях есть инструменты для этого), а именно на firmware.

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

Идеология: попытаться экстраполировать "гибкие" методики проектирования ПО (TDD, BDD) на процесс проектирования программно-аппаратного комплекса в целом.

Предполагаемый инструментарий для решения: C (для стенда), Ruby + Cucumber (для хоста, управляющего тестированием), Gherkin (как язык описания функциональных требований к системе).

Есть реально заинтересованные в результате (или хотя бы в процессе его получения)?

P.S. Не могу сказать, что идея нова: несколько лет назад команда из Atomic Object публиковала статьи и доклады о чем-то наподобие. Однако в качестве стенда использовалось оборудование с довольно ограниченными возможностями, без перспектив расширения. Софт так и не был доведен до состояния "бери и пользуйся", требовал плясок с бубном и не обновлялся уже несколько лет.
Записан

Всего лишь неделя кодирования с последующей неделей отладки могут сэкономить целый час, потраченный на планирование программы. - Дж. Коплин.

Ходить по воде и разрабатывать программное обеспечение по спецификациям очень просто, когда и то, и другое заморожено. - Edward V. Berard

Любые проблемы в информатике решаются добавлением еще одного уровня косвенности – кроме, разумеется, проблемы переизбытка уровней косвенности. — Дэвид Уилер.
RXL
Технический
Администратор

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #72 : 29-05-2014 11:43 » 

Я пасс. Времени мало.
Записан

... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
LemmonRus
Помогающий

ru
Offline Offline
В правильно заданном вопросе 90% ответа.


« Ответ #73 : 30-05-2014 11:12 » 

Народ поясните мне,а зачем в исходной работе микроконтроллер?
Это можно сделать на аналоговых схемах.
Записан
Dale
Блюзмен
Модератор

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #74 : 30-05-2014 12:10 » 

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

Всего лишь неделя кодирования с последующей неделей отладки могут сэкономить целый час, потраченный на планирование программы. - Дж. Коплин.

Ходить по воде и разрабатывать программное обеспечение по спецификациям очень просто, когда и то, и другое заморожено. - Edward V. Berard

Любые проблемы в информатике решаются добавлением еще одного уровня косвенности – кроме, разумеется, проблемы переизбытка уровней косвенности. — Дэвид Уилер.
Ochkarik
Команда клуба

ru
Offline Offline
Пол: Мужской

« Ответ #75 : 30-05-2014 12:16 » 

кстати... недавно один человек тут на форуме искал команду единомышленников, для построения ЧПУ станка. от проектирования плат-плис-контроллеров до драйверов. как раз в учебно-практическом смысле... правда я ему ответил, что сомнительно, что кто то присоединится, в виду отсутствия времени и интереса по данной тематике у основной части участников. но если кому то идея интересна - могу ему отписать?
Записан

RTFM уже хоть раз наконец!  RTFM :[ ну или хотя бы STFW...
Dale
Блюзмен
Модератор

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #76 : 30-05-2014 12:21 » 

Конечно, почему бы нет. Правда, тема самодельных ЧПУ давно избита и заезжена, поэтому имеет смысл браться только при наличии свежих идей. Ибо на конструкции, которые массово тиражируют, без слез не взглянуть. Спроектировано по принципу "зато работает".
Записан

Всего лишь неделя кодирования с последующей неделей отладки могут сэкономить целый час, потраченный на планирование программы. - Дж. Коплин.

Ходить по воде и разрабатывать программное обеспечение по спецификациям очень просто, когда и то, и другое заморожено. - Edward V. Berard

Любые проблемы в информатике решаются добавлением еще одного уровня косвенности – кроме, разумеется, проблемы переизбытка уровней косвенности. — Дэвид Уилер.
Aether
Специалист

ru
Offline Offline
Пол: Мужской

« Ответ #77 : 07-04-2015 08:58 » 

Можно тоже подкинуть тему, чтобы было и полезно и занимательно.

Много народа использует МК для устройств различной сложности, и значительное место занимает вопрос вывода информации, в том числе и во время тестирования, когда имеется необходимость выводить не только нужные параметры, но и служебные. Обычно, по мере роста сложности, для простых устройств используются сегментные индикаторы, шкалы, далее идут готовые малоформатные текстовые и графические модули. Но, что делать, когда нужно следить за кучей параметров, использовать, некоторую графику? Самое распространённое решение - сделать интерфейс с компьютером и выводить информацию через него на монитор, но можно ли поступить иначе - формировать изображение на мониторе, минуя стадию обработки на ПК?
Надо сказать, что даже информации по электрике VGA в сети не так уж и много, но на сегоднешний день этот стандарт уже устарел, да и разрешения, вроде, 640х480 на современных мониторах выглядят некачественно.
Задача: сделать модуль для организации вывода текстовой или графической информации на экран обычного монитора (например, через DVI). Речь, естественно, не идёт об интерактивном выводе видео - просто терминал. Мне это видится, как два буфера - один заполняем, другой рисуется, по заполнению нужными данными производим переключение. Управление модулем и передача данных должны происходить простейшим способом: SPI, I2C, RS-232... Время заполнения пассивного буфера не критично, так как до переключения будет повторно рисоваться активный буфер во избежания мерцания или появления каких-либо дефектов изображения.

Возможно, существуют готовые решения? Но, в любом варианте сама тема актуальна и интересна.
Записан
Ochkarik
Команда клуба

ru
Offline Offline
Пол: Мужской

« Ответ #78 : 07-04-2015 09:48 » 

http://rspmarket.com/shop/
Записан

RTFM уже хоть раз наконец!  RTFM :[ ну или хотя бы STFW...
Aether
Специалист

ru
Offline Offline
Пол: Мужской

« Ответ #79 : 07-04-2015 10:49 » 

Одноплатные компьютеры - это, конечно, хорошо, но:
как раз в учебно-практическом смысле...
Задача даст возможности оценить и ПЛИС и МК, работу с разными типами памяти... хотя, конечно, объёмно и не так просто, но не писать же статью на тривиальную тематику? Как идея для статьи, достойной профессионала, думаю, неплохо.
Записан
Dale
Блюзмен
Модератор

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #80 : 07-04-2015 21:49 » 

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

Во-первых, для тестирования он окажется бесполезен чуть более чем полностью. Хороший тест должен быть полностью автоматическим, будь то модульный, интеграционный, функциональный или еще какой (исключение можно сделать разве что для приемочного, но это совсем отдельная история). Если тест выводит что-то на экран, обязательно подразумевается некто, кто будет это с экрана считывать, и этот некто - человек со всеми его недостатками. Человек считывает данные медленно (по компьютерным меркам). Если данных будет много, человек будет еще и ошибаться. Ну а если тесты медленные, то мы вынуждены сказать "прощай" разработке через тестирование, регрессионному тестированию, рефакторингу, "гибким" методикам проектирования в целом и еще множеству весьма полезных в хозяйстве разработчика вещей. Даже если бы у меня такой девайс уже был прямо сейчас забесплатно, я все равно не задействовал бы его для тестов - не нужен он там совершенно, даже отчасти вреден.

Во-вторых, рассмотрим его как устройство для вывода. Дисплею нужен буфер для хранения битовой карты экрана. Разместить его во встроенной оперативной памяти контроллера нереально - даже для VGA 640х480 требуется треть миллиона пикселов. Если выделить всего по байту на пиксел, получается запредельный для типичного микроконтроллера объем. Если вынести битовую карту в отдельную память и заполнять ее по серийному интерфейсу - грубо оценим необходимое для формирования кадра время. SPI с натугой пропустит несколько мегабит в секунду (вопрос, сколько времени уйдет на генерацию этих данных на большинстве микроконтроллеров, пока отложим). I2C с порогом  400 кбит/с и RS232 с еще более скромными показателями годятся еще меньше.

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

Я бы для данной задачи рассмотрел два варианта. Первый тривиален: использовать отвергнутый ранее одноплатный компьютер, в котором все необходимое, включая графические библиотеки, уже есть. Но тут все совсем просто и нет полета фантазии.

Второй вариант тоже не блещет оригинальностью: используем популярное в "большом" программировании отделение данных от представления (MVC/MVP и иже с ними). Оснащаем контроллер сетевым интерфейсом (с проводами либо без, не суть важно) и встроенным web-сервером (благо этого добра в Сети навалом в готовом виде). Любой желающий отобразить эти данные подключается как браузер, причем годится что угодно вплоть до смартфона.

Мое IMHO: если главная цель - размяться и поднатореть в применении ПЛИС, то почему бы и нет? Задача в самый раз - и не слишком тривиальная, и в то же время не неподъемная. Если же вторая цель - еще и получить полезный в хозяйстве девайс, тут меня гложут большие сомнения: тот же результат достигается куда проще и практичнее, плюс еще и масштабируется не в пример лучше.
Записан

Всего лишь неделя кодирования с последующей неделей отладки могут сэкономить целый час, потраченный на планирование программы. - Дж. Коплин.

Ходить по воде и разрабатывать программное обеспечение по спецификациям очень просто, когда и то, и другое заморожено. - Edward V. Berard

Любые проблемы в информатике решаются добавлением еще одного уровня косвенности – кроме, разумеется, проблемы переизбытка уровней косвенности. — Дэвид Уилер.
Aether
Специалист

ru
Offline Offline
Пол: Мужской

« Ответ #81 : 08-04-2015 15:34 » 

Основная цель, естественно, образовательная, как говорите - поднатореть, думаю, многие, начиная от радиолюбителей и заканчивая "домашними" ЧПУ-строителями, заинтересуются данным устройством или, по крайней мере, получат серьёзный стимул к развитию в области практической электроники. С коммерческой стороны - да, одноплатные компьютеры - решение эффективное, масштабируемое...

С точки зрения реализации, не нужно умножать цель, например, сетевой интерфейс - сам по себе не так прост, и является темой для отдельной статьи. Главное просто и доступно. Не зря изначально я сказал, что о воспроизведении видео не может быть и речи, естественно, ни у одного МК не хватит собственной памяти, а у средних, например, PIC - скорости. Стало быть, передача, исключительно, массива точек из устройства пользователя (на базе МК, МП - да чего угодно) в девайс лишена смысла. Мне видится интерфейс методом последовательной передачи команд (пакетов, содержащих команды, данные, код контроля целостности), то есть модуль должен поддерживать команды:
а) собственной инициализации (вкл/выкл, установка разрешения монитора...),
б) закрашивания пассивного буфера в заданный цвет (или прямоугольной области),
в) установки пикселя в пассивном буфере по координатам и цвету,
г) записи таблицы растрового шрифта в ПЗУ,
д) установки буквы по координате, цвету и адресу в ПЗУ...
...
е) обмена активного и пассивного буферов местами.
Активный буфер - тот, который выводится на экран, пассивный - тот, в котором мы рисуем, подготавливая изображение.
Записан
Dale
Блюзмен
Модератор

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #82 : 08-04-2015 23:08 » 

С коммерческой стороны - да, одноплатные компьютеры - решение эффективное, масштабируемое...

Сегодня это вполне реально не только для коммерческого применения. Возьмите, к примеру, Raspberry Pi. За несчастных 36$ вместе с доставкой получаете готовый компьютер размером с кредитку под Linux'ом с частотой 700 Мгц, ОЗУ в полгигабайта, сетевой интерфейс 10/100 Mбит/c, 4 порта USB, довольно приличный для таких размера и цены видеоакселератор, звук средней паршивости и интерфейс расширения, к которому можно нацеплять чего угодно. По сегодняшнему курсу это немного меньше 2.000 руб, не жалко пожертвовать в качестве контроллера для нетривиальной задачи. Сумеете уложить свой мегадевайс вместе с разработкой железа/софта и изготовлением в эту сумму?

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

IMHO преувеличение, и сильное. Модуль на 28J60 стоит меньше трех баксов с доставкой и устроен проще пареной репы, если захочется развести на плате собственный вариант, а не лепить покупной. От софта к нему буквально ломится интернет, начиная со стека сетевых протоколов и до готового встроенного web-сервера. Писать о нем статью - пустая трата времени, такую статью только ленивый до сих пор не написал: http://yandex.ru/yandsearch?text=28j60%20%D0%BF%D0%BE%D0%B4%D0%BA%D0%BB%D1%8E%D1%87%D0%B5%D0%BD%D0%B8%D0%B5&lr=39

Разумеется, это при условии, что не польстились на Raspberry.

Основная цель, естественно, образовательная, как говорите - поднатореть, думаю, многие, начиная от радиолюбителей и заканчивая "домашними" ЧПУ-строителями, заинтересуются данным устройством или, по крайней мере, получат серьёзный стимул к развитию в области практической электроники.

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

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

Всего лишь неделя кодирования с последующей неделей отладки могут сэкономить целый час, потраченный на планирование программы. - Дж. Коплин.

Ходить по воде и разрабатывать программное обеспечение по спецификациям очень просто, когда и то, и другое заморожено. - Edward V. Berard

Любые проблемы в информатике решаются добавлением еще одного уровня косвенности – кроме, разумеется, проблемы переизбытка уровней косвенности. — Дэвид Уилер.
Aether
Специалист

ru
Offline Offline
Пол: Мужской

« Ответ #83 : 09-04-2015 15:08 » new

За несчастных 36$ вместе с доставкой... По сегодняшнему курсу это немного меньше 2.000 руб, не жалко пожертвовать в качестве контроллера для нетривиальной задачи. Сумеете уложить свой мегадевайс вместе с разработкой железа/софта и изготовлением в эту сумму?
Хорошо, убедили.
Записан
Страниц: 1 2 [3]  Все   Вверх
  Печать  
 

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines