wxRuby из всего, что пробовал — самый удобный.
Вы еще fxruby забыли, а он ведь даже по дефолту в виндовом установщике идет:)
Tk прост как табуретка, но для простых задач самое то, единственное, чтобы приложения выглядели нативно, нужно использовать экстеншн tile, который в виндовый rubyscript2exe пакуется только с бубном, ну и с табличным компонентом заморочки.
Бумажная упаковка — срубленное дерево. Притом одноназового использования, для каждого нового пакетика — рубить дерево. Как-то не очень экологично:)
Куда лучше полиэтилен не сжигать или закапывать, а повторно перерабатывать.
Полопал пузырьки — переработал, и снова лопаешь, бесконечное наслаждение:)
Простая формула для личной оценки сроков(ёпт метод":)).
Прикинуть сколько дней это займет(t) и помножить получившееся значение на e(≈2.7).
Затем помножить итог на π(≈3.14:)) и сказать результат заказчику.
В итоге, если в процессе выполнения не одалеет понос или золотуха, то функция реального времени от прикинутого:
ATMega/ATTiny точно везде продается. Покрайней мере, чуть ли не во всех иркутских магазинах они есть. А Иркутск намного удаленнее от Москвы чем Саратов:)
Нда, плохо. Погуглил, $40 эта С3088 стоит, плюс ~$20 доставка выйдет…
Хотя, я тут все же подумал насчет камер от мобильников. Ведь там процессор то совсем слабенький, с оцифровкой аналогово видео точно не справится, значит эти камеры все-таки цифровые, но, раз выводов мало, с последовательным интерфейсом. (Просто в нашем радиомагазине целая полка на витрине ими завалена, и цены вполне бюджетные:)). Но насчет работы с этими камерами ничего нагуглить не могу…
Армом заинтриговался:) Будем гуглить на эту тему:) Я както смотрел конференцию про Ruby, там парни рассказывали про какой-то девайс, что-то типо траффико считалки для датацентров. Так сам девайс был на арме, притом там был поставлен uLinux, под которым запущен Ruby интерпретатор. Ну и вся софтварная часть была написанна на Ruby. Плюс еще видел пост на форуме, как парни делали корабль робота на каком-то мк, и тоже софт на Ruby. За $10000 предлагали тюнинговать интерпретатор под их цели:) Ошибка, чтоли какая-то была. Ну, я как фанат Ruby, записал в список своих мечт хардварный девайс под контролем Ruby:)
Но я думал, что арм это только процессор. А если это «все в одном»...:)
Только тогда я не понимаю, как туда линукс ставят? Разве можно разместить на одном кристале столько оперативки?(флешка то явно внешняя).
Насчет дисплея, тот который я выпаял — вобще ноунэйм, никакой маркировки. Не буду тогда мучится, схожу куплю экранчик.
Ясно, то-то я смотрю камера в корпусе:) Но всеравно странно, т.к. первое, что я нагуглил на «avr camera interface» — это пдфка с проектом на atmega16 и цифровой камере: www.robozes.com/inaki/dproject/report.pdf
Но, C3088 я на чипдипе не нашел, а раз нет на чипдипе, то в моих местных радиомагазинах уж точно нету… Вот я и думал, может есть какое-то распространенное решение:) Мне сложный процессинг не нужен, это не для робота. Грубо говоря мне нужно что-то типа проверок «есть ли черный квадрат на белом фоне». Т.е. можно будет обойтись построчной обработкой, думаю атмеговской памяти на это хватит:)
Ну, идея с армом конечно тоже хорошая, но думаю для меня пока это сложновато будет… Там же, как я понимаю, кристал только производит вычисления, озу и флеш вынесены отдельно?
>распространены LCD на контроллере HD44780
Ясно. А как узнать, дисплей с этим контроллером или нет? Только эмперически — заработает, значит HD44780?:)
О, накидайте, пожалуйста, ссылок, на работу с камерой? Только я совсем-совсем начинающий:) Совсем недавно спаял программатор и прошил свою первую атмегу:)
Я как понял, камеры бывают аналоговые и цифровые. Мне бы как работать с цифровыми. Хочется процессить картинку прямо на мк.
Я пока просто даже в замешательстве в какую сторону гуглить. Видел в местном магазине например камеры для мобильников, но у них всего толи два толи три вывода, тоесть они аналоговые? Тогда где брать цифровые, и какие именно?
И еще, сильно интересно, как работать с LCD дисплеем(пока только сегментные индикаторы освоил). Я выпаял дисплейчек со старого радио, у него много ножек, и ничего на нем не написанно:) Как с ним работать на атмеге?
Основная фишка тут в том, что пока один поток ждет чего-то, второй в это время выполняется. Т.е., как TDz выше написал, например работа с сетью. Один поток отправил запрос и ждет ответа, второму ответ уже пришел, и он обрабатывает результат, третий за это время успел уже два запроса обработать. В итоге, без потоков эти пять запросов обрабатывались бы последовательно, а с потоками — паралельно.
Классический пример потоков(правда десктопный), это GUI и обработка в разных потоках. Если они будут в одном потоке, то во время обработки GUI будет подвисать.
Применительно к вебу — тоже самое, есть сервер, одна из функций, например, массовая рассылка почты. Появилась ситуация когда нужно разослать письма — создаем поток и рассылаем(или, если писем много, создаем n потоков). Так же очень удобно использовать потоки в грабберах. Граббинг в n потоков почти в n раз быстрее:)(до определенного момента). Хотя, в случае граббинга можно использовать curl-multi, но это если граббинг без процессинга.
У меня например на сервере в паралельном потоке весит джаббер бот, который меня извещает об ошибках, и имеет простенькую обработку комманд для получения статистики.
Конечно никто не спорит, что тоже самое можно сделать форками, либо вобще несколькими независимыми приложениями сообщающимися посредством, например, сокетов. Но используя потоки, все вразы проще:)
Конечно за простоту приходится платить проблемами с синхронизацией, но, при аккуратном использование таких проблем не возникает:)
Ну по теме — потоки на форках, это конечно очень уныло. Кстати, была на хабре похожая тема(да почти идентичная, тоже пхпшные потоки на форках), я специально не поленился и погуглил насчет php pthread. И такой проект есть, насчет его статуса не скажу, но если оно работает, это куда лучше форков:)
Вы еще fxruby забыли, а он ведь даже по дефолту в виндовом установщике идет:)
Tk прост как табуретка, но для простых задач самое то, единственное, чтобы приложения выглядели нативно, нужно использовать экстеншн tile, который в виндовый rubyscript2exe пакуется только с бубном, ну и с табличным компонентом заморочки.
Куда лучше полиэтилен не сжигать или закапывать, а повторно перерабатывать.
Полопал пузырьки — переработал, и снова лопаешь, бесконечное наслаждение:)
Прикинуть сколько дней это займет(t) и помножить получившееся значение на e(≈2.7).
Затем помножить итог на π(≈3.14:)) и сказать результат заказчику.
В итоге, если в процессе выполнения не одалеет понос или золотуха, то функция реального времени от прикинутого:
Проще тогда уже nanoPC заюзать:)
Хотя, я тут все же подумал насчет камер от мобильников. Ведь там процессор то совсем слабенький, с оцифровкой аналогово видео точно не справится, значит эти камеры все-таки цифровые, но, раз выводов мало, с последовательным интерфейсом. (Просто в нашем радиомагазине целая полка на витрине ими завалена, и цены вполне бюджетные:)). Но насчет работы с этими камерами ничего нагуглить не могу…
Армом заинтриговался:) Будем гуглить на эту тему:) Я както смотрел конференцию про Ruby, там парни рассказывали про какой-то девайс, что-то типо траффико считалки для датацентров. Так сам девайс был на арме, притом там был поставлен uLinux, под которым запущен Ruby интерпретатор. Ну и вся софтварная часть была написанна на Ruby. Плюс еще видел пост на форуме, как парни делали корабль робота на каком-то мк, и тоже софт на Ruby. За $10000 предлагали тюнинговать интерпретатор под их цели:) Ошибка, чтоли какая-то была. Ну, я как фанат Ruby, записал в список своих мечт хардварный девайс под контролем Ruby:)
Но я думал, что арм это только процессор. А если это «все в одном»...:)
Только тогда я не понимаю, как туда линукс ставят? Разве можно разместить на одном кристале столько оперативки?(флешка то явно внешняя).
Насчет дисплея, тот который я выпаял — вобще ноунэйм, никакой маркировки. Не буду тогда мучится, схожу куплю экранчик.
www.robozes.com/inaki/dproject/report.pdf
Но, C3088 я на чипдипе не нашел, а раз нет на чипдипе, то в моих местных радиомагазинах уж точно нету… Вот я и думал, может есть какое-то распространенное решение:) Мне сложный процессинг не нужен, это не для робота. Грубо говоря мне нужно что-то типа проверок «есть ли черный квадрат на белом фоне». Т.е. можно будет обойтись построчной обработкой, думаю атмеговской памяти на это хватит:)
Ну, идея с армом конечно тоже хорошая, но думаю для меня пока это сложновато будет… Там же, как я понимаю, кристал только производит вычисления, озу и флеш вынесены отдельно?
>распространены LCD на контроллере HD44780
Ясно. А как узнать, дисплей с этим контроллером или нет? Только эмперически — заработает, значит HD44780?:)
Я как понял, камеры бывают аналоговые и цифровые. Мне бы как работать с цифровыми. Хочется процессить картинку прямо на мк.
Я пока просто даже в замешательстве в какую сторону гуглить. Видел в местном магазине например камеры для мобильников, но у них всего толи два толи три вывода, тоесть они аналоговые? Тогда где брать цифровые, и какие именно?
И еще, сильно интересно, как работать с LCD дисплеем(пока только сегментные индикаторы освоил). Я выпаял дисплейчек со старого радио, у него много ножек, и ничего на нем не написанно:) Как с ним работать на атмеге?
Применительно к вебу — тоже самое, есть сервер, одна из функций, например, массовая рассылка почты. Появилась ситуация когда нужно разослать письма — создаем поток и рассылаем(или, если писем много, создаем n потоков). Так же очень удобно использовать потоки в грабберах. Граббинг в n потоков почти в n раз быстрее:)(до определенного момента). Хотя, в случае граббинга можно использовать curl-multi, но это если граббинг без процессинга.
У меня например на сервере в паралельном потоке весит джаббер бот, который меня извещает об ошибках, и имеет простенькую обработку комманд для получения статистики.
Конечно никто не спорит, что тоже самое можно сделать форками, либо вобще несколькими независимыми приложениями сообщающимися посредством, например, сокетов. Но используя потоки, все вразы проще:)
Конечно за простоту приходится платить проблемами с синхронизацией, но, при аккуратном использование таких проблем не возникает:)
Ну по теме — потоки на форках, это конечно очень уныло. Кстати, была на хабре похожая тема(да почти идентичная, тоже пхпшные потоки на форках), я специально не поленился и погуглил насчет php pthread. И такой проект есть, насчет его статуса не скажу, но если оно работает, это куда лучше форков:)
На Ruby лаконичнее:)
Это сервер очередей, с удобным ruby api:)
Топик — рай для спамеров:)