Надо озабоченным справедливостью американским астрономам подкинуть идею организовать гей-НАСА, и там запускать космические телескопы с именами исключительно гендерно-правильных товарищей.
Вообще, рисуется довольно интересная картина: Приделываем к заду коровы газосборник с разделителем на водород-углекислый газ, и водород качаем по трубе как «зеленое» топливо, а из углекислого газа делаем крахмал. Идеальное, практически безотходное производство. Доходность будет такая, что мясо/молоко станут просто побочными отходами. Может, в конце концов и от них откажутся.
В ванну размером 165*75 можно влить 210 литров воды. Это получается, что 300-литровый рубец коровы — это чуть ли не плавательный бассейн. Жутко представить такого монстра… Или в таком случае корова состоит только из рубца и вымени?
Когда у нас была кошка, она приучилась писать в пустой лоток (сначала с песком, потом с рваными газетами, потом совсем пустой). Но вот какала принципиально в углу возле входной двери. Ты ее ругаешь почем зря, а она мрачно на тебя смотрит и делает свое грязное дело. Никакие меры не помогли.
Когда-то я читал про подобное исследование у людей — что плод еще в утробе начинает различать речь и обучаться ей.
По-моему, очевидно, что подобное обучение осуществляется исключительно на основе генетически заложенных программ, а не в результате социализации.
Отсюда возникает вопрос: Что стоит за общностью этих механизмов у птиц и людей? Важность вокализации для птиц и ее обкатка и отладка в течение миллионов лет очевидна. А вот какими были процессы, стоящие за выработкой подобных механизмов у людей? Какими должны были быть механизмы полового и естественного (связанного с окружающей средой) отбора?
Похоже. что подобные вопросы тщательно избегаются исследователями, что очень жаль. По крайней мере, мне ни разу не попадались работы на эту тему, хотя я пытался их найти.
Мне надо будет делать софт для измерителя расхода факельных газов. Заодно и выбрать контроллер для него. Так как я уже имел дело с разными ардуинами и RP pico, я подумал, что можно было бы сделать комбинацию из нескольких контроллеров (один общается с сенсорами, другой – выводит инфу на экран и накапливает данные.) Но мне все время казалось, что подобное решение для нефтегаза может не прокатить – как раз потому, что там, по идее, должны быть свои железки, соответствующие суровым производственным требованиям.
В связи с этим – вопрос: какое железо допустимо (необходимо) использовать в подобных задачах? Где об этом можно почитать (хотя бы какие ключевые слова использовать для поиска)?
Сам софт должен быть достаточно простой – принять данные от сенсоров, обработать по заданной формуле, сохранить на флешке, показать на экране, отослать в центральную диспетчерскую. Ну и какое-никакое меню управления для ввода/коррекции параметров и просмотра данных, если будет нужно.
Еще вопрос – есть ли контроллеры, которые можно ставить непосредственно в газовый поток? Типа измерить на месте давление и отослать данные в центральный блок?
Мне какое-то время пришлось работать на Маке. Сначала бесило, что привычные (в Винде) сочетания клавиш вызывают совершенно другую (и абсолютно ненужную) реакцию. Потом разобрался и настроил все, что можно, как в Винде. После этого стало работать нормальнее.
Вот что мне совершенно не нравится в МакОс:
1. Микроскопические кружочки-светофор для управления окнами. Они ВЫНУЖДАЮТ тебя пялиться на экран, чтобы точно попасть, куда надо. В Винде окно можно закрыть не глядя (если оно развернуто на весь экран). Да и кнопки управления окном там побольше будут, что гораздо удобнее.
2. Отсутствие возможности одновременно «правого» (Ctrl+Ins, Shift+Ins) и «левого» (Ctrl+C, Ctrl+V) копипаста. Только какой-то один вариант.
3. Отсутствие возможности свернуть/развернуть все окна одним щелчком мыши, не глядя.
Общее впечатление — что Макос разрабатывалась с прицелом на американских домохозяек, которые преимущественно смотрят на компе ролики и кликают по рекламе, и для которых лишние пара секунд, потраченные на поиск нужной кнопки — не время. Тогда как Винда разрабатывалась в первую очередь инженерами для инженеров, с прицелом на эффективную работу. Я так думаю.
Да, файловый менеджер на Маке просто кошмар. Мне дико не хватало FAR.
Похоже, единственный способ для этого робота поймать кошку — это взять в руки коробку и тихо сидеть в углу.
Качеству помывки посуды этим роботом я бы не доверял. Тут и не все человеки ее хорошо моют. Максимум — пусть поставит ее в посудомоечную машину и нажмет на кнопку.
Интересно, а исследовали ли при этом динамику гормонального статуса (типа, концентрации тестостерона/окситоцина)? Меняются ли уровни гормонов (и если да, то каких и как) при ремиссии/рецессии?
И имеется ли связь между гипоталамо-гипофизарно-надпочечниковой/тиреоидной системами и СДВГ?
Я отлаживал все, ориентируясь на данные, полученные ПК (т.е. уже в Visual Studio).
Т.е., например, организовывал передачу данных из ведомого Тинси в ведущий, а из него — в ПК. Т.е. отладка шла на самом верхнем уровне (ПК). Соответственно, если происходил сбой в передаче данных из ведомого, то я ничего в ПК не мог увидеть. Но, в конце концов, оно все заработало.
Насчет Visual Micro — как я понял, они используют способность Тинси создавать до трех СОМ-портов, и один из них используют для передачи отладочной информации и даже для организации точек останова. Это бы мне ну очень пригодилось при отладке ведомого Тинси, но система таки заработала до того, как я дошел до точки )).
Кстати, то, что не получилось параллельно использовать UART и I2C — это баг или фича? Я написал в статье, что где-то наткнулся на упоминание, что в Ардуино это таки фича (для ATmega), но является ли это сознательным решением для Тинси — непонятно. Может, при использовании родных библиотек от NXP были бы совсем другие проблемы.
Интересный материал. Лично я, правда, работал с Тинси исключительно под Ардуино, т.к. низкая сложность проектов вполне это позволяла, да и функционал имеющихся библиотек меня вполне устраивал.
Есть пара вопросов:
1. Насчет отладки — что Вы думаете о Visual Micro? Я понимаю, что она под Ардуино (что не стыкуется с основной идеей ваших статей), но наличие возможности отладки (хоть какой-то), с моей точки зрения, является большим плюсом. Правда, по ряду причин я этой возможностью воспользоваться не смог.
2. Я столкнулся с проблемами при организации обмена данными между двумя Тинси 4.0 по UART, в результате чего пришел к выводу, что лучше всего в этом случае использовать синхронную передачу данных (например, тот же SPI). Интересно было бы узнать Вашу точку зрения на описанные мной случаи. Я допускаю, что, в частности, проблемы в работе UART при подключении другого Тинси к ПК (да и другие траблы) могли быть вызваны использованными библиотеками, но так глубоко я не копал — не было ни времени, ни серьезной необходимости.
Тут, наверное, надо смотреть на задачу в целом, и под нее подбирать паратмеры железа.
Тинси мне нравится за это:
ARM Cortex-M7 at 600 MHz
Float point math unit, 64 & 32 bits
1984K Flash, 1024K RAM (512K tightly coupled), 1K EEPROM (emulated)
USB device 480 Mbit/sec & USB host 480 Mbit/sec
Т.е., например, можно сразу в память загнать до 400-500к отсчетов, а потом их перегнать в ПК. У STM32F103C8 так не получится — у него всего 20к SRAM. Но, еще раз, — хозяин барин.
К сожалению, в статье не упоминается, на какую стоимость стоит ориентироваться при разработке подобных устройств. Если бюджет в размере 25-30 долларов приемлем, то я бы рекомендовал Teensy 4.0 или 4.1 (в зависимости от требований) в сочетании с AD5621.
Как известно, чем выше разрядность АЦП, тем лучше отображается форма сигналов. Соответственно, 12-разрядный AD5621, работающий на частоте 1 МГц, будет гораздо лучше «родного» 8- или 10-битного, которые для «повышения разрядности» используют усреднение.
Если уж «гулять, так гулять», то можно сделать и 2-канальную систему, в которой на каждом канале будет свой Тинси и АЦП, но тут могут быть проблемы с обменом данными, о которых я написал в своей заметке.
Я для себя пользуюсь концепцией «матрицы знаний» — т.е. сначалы мы заполняем самые крупные клетки матрицы (например, что Земля — это планета, которая взаимодействует с Солнцем), потом — более мелкие ячейки (климатические зоны и материки, меридианы и параллели), потом еще более мелкие и т.д.
Для меня «пачка объектов» — это самые мелкие ячейки, которые содержат, например, данные о том, каковы запасы угля и руды в Костромской области, с какими регионами она соседствует и как зовут их губернатора. Если я не живу в Костроме — как я по жизни смогу воспользоваться этой информацией, если хранить ее в голове? Да никак. Это как запоминание того, сколько стали было выплавлено в СССР за первую пятилетку и сколько было добыто угля во вторую. Я так и не смог в свое время запомнить эти числа. Экзамен по истории СССР сдал чисто чудом (мне попался 1-й билет, который я успел выучить от и до :) )
Насчет требование м.о. — согласен, образование, как и медицина, — весьма консервативные области. Принцип «зазубрил — значит знаешь», к сожалению, остается неизменным со времен Российской империи. Но сегодня гораздо важнее становится понимание мира, чем набор фактов о нем, которыми ты никогда не воспользуешься.
По-моему, очевидно, что подобное обучение осуществляется исключительно на основе генетически заложенных программ, а не в результате социализации.
Отсюда возникает вопрос: Что стоит за общностью этих механизмов у птиц и людей? Важность вокализации для птиц и ее обкатка и отладка в течение миллионов лет очевидна. А вот какими были процессы, стоящие за выработкой подобных механизмов у людей? Какими должны были быть механизмы полового и естественного (связанного с окружающей средой) отбора?
Похоже. что подобные вопросы тщательно избегаются исследователями, что очень жаль. По крайней мере, мне ни разу не попадались работы на эту тему, хотя я пытался их найти.
Еще один вопрос — если поставить принтер на балконе, какая часть частиц попадет в квартиру?
Понимаю, что вопросы надо адресовать не автору перевода, но, может, кто-то знает ответы?
Мне надо будет делать софт для измерителя расхода факельных газов. Заодно и выбрать контроллер для него. Так как я уже имел дело с разными ардуинами и RP pico, я подумал, что можно было бы сделать комбинацию из нескольких контроллеров (один общается с сенсорами, другой – выводит инфу на экран и накапливает данные.) Но мне все время казалось, что подобное решение для нефтегаза может не прокатить – как раз потому, что там, по идее, должны быть свои железки, соответствующие суровым производственным требованиям.
В связи с этим – вопрос: какое железо допустимо (необходимо) использовать в подобных задачах? Где об этом можно почитать (хотя бы какие ключевые слова использовать для поиска)?
Сам софт должен быть достаточно простой – принять данные от сенсоров, обработать по заданной формуле, сохранить на флешке, показать на экране, отослать в центральную диспетчерскую. Ну и какое-никакое меню управления для ввода/коррекции параметров и просмотра данных, если будет нужно.
Еще вопрос – есть ли контроллеры, которые можно ставить непосредственно в газовый поток? Типа измерить на месте давление и отослать данные в центральный блок?
Вот что мне совершенно не нравится в МакОс:
1. Микроскопические кружочки-светофор для управления окнами. Они ВЫНУЖДАЮТ тебя пялиться на экран, чтобы точно попасть, куда надо. В Винде окно можно закрыть не глядя (если оно развернуто на весь экран). Да и кнопки управления окном там побольше будут, что гораздо удобнее.
2. Отсутствие возможности одновременно «правого» (Ctrl+Ins, Shift+Ins) и «левого» (Ctrl+C, Ctrl+V) копипаста. Только какой-то один вариант.
3. Отсутствие возможности свернуть/развернуть все окна одним щелчком мыши, не глядя.
Общее впечатление — что Макос разрабатывалась с прицелом на американских домохозяек, которые преимущественно смотрят на компе ролики и кликают по рекламе, и для которых лишние пара секунд, потраченные на поиск нужной кнопки — не время. Тогда как Винда разрабатывалась в первую очередь инженерами для инженеров, с прицелом на эффективную работу. Я так думаю.
Да, файловый менеджер на Маке просто кошмар. Мне дико не хватало FAR.
Качеству помывки посуды этим роботом я бы не доверял. Тут и не все человеки ее хорошо моют. Максимум — пусть поставит ее в посудомоечную машину и нажмет на кнопку.
И имеется ли связь между гипоталамо-гипофизарно-надпочечниковой/тиреоидной системами и СДВГ?
Т.е., например, организовывал передачу данных из ведомого Тинси в ведущий, а из него — в ПК. Т.е. отладка шла на самом верхнем уровне (ПК). Соответственно, если происходил сбой в передаче данных из ведомого, то я ничего в ПК не мог увидеть. Но, в конце концов, оно все заработало.
Насчет Visual Micro — как я понял, они используют способность Тинси создавать до трех СОМ-портов, и один из них используют для передачи отладочной информации и даже для организации точек останова. Это бы мне ну очень пригодилось при отладке ведомого Тинси, но система таки заработала до того, как я дошел до точки )).
Кстати, то, что не получилось параллельно использовать UART и I2C — это баг или фича? Я написал в статье, что где-то наткнулся на упоминание, что в Ардуино это таки фича (для ATmega), но является ли это сознательным решением для Тинси — непонятно. Может, при использовании родных библиотек от NXP были бы совсем другие проблемы.
Есть пара вопросов:
1. Насчет отладки — что Вы думаете о Visual Micro? Я понимаю, что она под Ардуино (что не стыкуется с основной идеей ваших статей), но наличие возможности отладки (хоть какой-то), с моей точки зрения, является большим плюсом. Правда, по ряду причин я этой возможностью воспользоваться не смог.
2. Я столкнулся с проблемами при организации обмена данными между двумя Тинси 4.0 по UART, в результате чего пришел к выводу, что лучше всего в этом случае использовать синхронную передачу данных (например, тот же SPI). Интересно было бы узнать Вашу точку зрения на описанные мной случаи. Я допускаю, что, в частности, проблемы в работе UART при подключении другого Тинси к ПК (да и другие траблы) могли быть вызваны использованными библиотеками, но так глубоко я не копал — не было ни времени, ни серьезной необходимости.
Тинси мне нравится за это:
ARM Cortex-M7 at 600 MHz
Float point math unit, 64 & 32 bits
1984K Flash, 1024K RAM (512K tightly coupled), 1K EEPROM (emulated)
USB device 480 Mbit/sec & USB host 480 Mbit/sec
Т.е., например, можно сразу в память загнать до 400-500к отсчетов, а потом их перегнать в ПК. У STM32F103C8 так не получится — у него всего 20к SRAM. Но, еще раз, — хозяин барин.
Как известно, чем выше разрядность АЦП, тем лучше отображается форма сигналов. Соответственно, 12-разрядный AD5621, работающий на частоте 1 МГц, будет гораздо лучше «родного» 8- или 10-битного, которые для «повышения разрядности» используют усреднение.
Если уж «гулять, так гулять», то можно сделать и 2-канальную систему, в которой на каждом канале будет свой Тинси и АЦП, но тут могут быть проблемы с обменом данными, о которых я написал в своей заметке.
Для меня «пачка объектов» — это самые мелкие ячейки, которые содержат, например, данные о том, каковы запасы угля и руды в Костромской области, с какими регионами она соседствует и как зовут их губернатора. Если я не живу в Костроме — как я по жизни смогу воспользоваться этой информацией, если хранить ее в голове? Да никак. Это как запоминание того, сколько стали было выплавлено в СССР за первую пятилетку и сколько было добыто угля во вторую. Я так и не смог в свое время запомнить эти числа. Экзамен по истории СССР сдал чисто чудом (мне попался 1-й билет, который я успел выучить от и до :) )
Насчет требование м.о. — согласен, образование, как и медицина, — весьма консервативные области. Принцип «зазубрил — значит знаешь», к сожалению, остается неизменным со времен Российской империи. Но сегодня гораздо важнее становится понимание мира, чем набор фактов о нем, которыми ты никогда не воспользуешься.