throughtheether

Отличия языков в уровнях абстракции.



На уровне вентилей Verilog имеет все из коробки, язык от туда и начинался, в то время как для VHDL была разработана VITAL. В результате они сравнились по возможностям.

С описанием алгоритмов и поведенческих моделей, они справляются оба, тут дело вкуса и действительно наличия лицензии. Verilog зачастую идет как основной язык, в то время VHDL - опция. Куча софта на входе желают видеть Verilog или производные из него. В плане FOSS решений есть icarus verilog и GHDL, однако последний вроде как встал.

Уровень системы, тут конечно VHDL вырывается в перед. Аля Паскаль( и его родители ) система пользовательских типов, все из коробки, ребята давайте тип сделаем фукнции к нему напишем, операторы определим, лучше день потерять потом за пять минут до лететь. Куда там C-подобному Verilog'у без структур данных, тяжко. Однако SystemVerilog такое С++ из мира Verilog. Вот вам Typedef, Enum, Union, Struct, Class. Правда SV - это другой язык и к нему опять нужна лицензия.

Я начинал с VHDL, он такой строгий и прям в строгости держит, сейчас перебираюсь на Verilog, SystemVerilog.

| - это операция побитовое ИЛИ
4 | 5 | 6 == 7 все верно
4 = 100
5 = 101
6 = 110
==> 111 = 7

То есть вы создаете объект "c" класса SomeClass, в который передается результат этой операции.

У вас есть 32-0.5кб на код, 2кб оперативки и 1кб энергонезависимой памяти.
Сколько кода у вас влезет - сложно сказать, все зависит от того, на чем и как вы будете писать программу.
Можете отказаться от бутлоадера и программирования на wiring и перейти на чистый си с разработкой кода в Keil, например. Это будет более правильно. Правда потребуется внешний программатор, но это не проблема - можно собрать, можно купить.

Здравствуйте, однажды мой маршрутизатор под прошивкой OpenWRT превратился в кирпич. Я разобрал его, подключился через UART с помощью Raspberry PI, можно и просто через переходник UART, как удобней. Ну в общем через терминал и восстановил.

ИМХО: найдите UART на плате, посмотрите что пишет при загрузке; есть 3.3V и 5V напряжение, чаще первое

Вот ссылка reverse engineering serial ports в помощь, удачи

P. S. UART на TP-LINK TL-MR3020

в Питоне же специализации есть какие-никакие
проще всего - найдите ресурс, откуда скачиваете эти по списку и пройдитесь по содержанию интересно-неитересно

"для всех" можно порекомендовать

см. на английском содержание, выходит 15 января
и, возможно,
( не могу найти развернутое содержание, но тоже выходит летом на русском)

полезно тематически:
scraping
multiprocessing
и паттерны
раз, два
ну и по сетям, думаю, тоже всем нужно, вот неплохая


в тех же темах, где Питон применяют типа NumPy, Scikit-Learning или NTLK - книг еще больше, но там прокачка будет посложнее

по Django - Flask книг тоже полно, по Pyramid поменьше, но тоже есть

Хорошо, что вы указали в тегах Windows, это все объясняет. Под Windows нет простого способа "раздвоиться" процессу при вызове multiprocessing.Process, поэтому осуществляется очень сложная эмуляция этого поведения. При этом функция target выдирается из модуля, запускается в отдельном интерпретаторе, а все параметры сереализуются передаются и десереализуются перед вызовом target, при этом инициализация модуля в новом интерпретаторе выполняется частично (инициализируется только глобальный контекс). Подробнее об этом, например, тут, есть еще одна очень хорошая статья где подробно рассмотрен этот механизм, но сейчас не найду ссылку.

Коротко о том, как готовить multiprocessing под Windows:

1. Разделять процессы (вызов multiprocessing.Process()) как можно раньше в коде.
   
2. По возможности избегать инициализации любых ресурсов и глобальных переменных до разделения. Учитывайте, что этот код выполняется во всех процессах независимо и может давать кучу сторонних эффектов.
   
3. Не передавать через args никаких сложных объектов с "поведением" (кроме объектов из самого multiprocessing, он сам знает как их правильно передавать), только голые данные (примитивы или объекты состоящие только из примитивов), которые сериализуются без сторонних эффектов.
   
4. Создавать дочерние процессы один раз, и на протяжении всего времени работать с ними посредством обмена сообщениями через Pipe/Queue. Не порождать новые процессы в цикле вычислений в момент "когда понадобятся".
   
5. Queue при попытке записи/чтения может блокировать процесс, если при этом происходит запись/чтения в/из нее в другом процессе. (Думаю, именно это и происходит в коде в вопросе).
   
6. Лучше использовать Pipe, который в худшем случае блокирует один процесс, а не все, как Queue.
   
7. При создании процесса можно передавать ему два Pipe (input одного + output другого), в вызывающем процессе хранить соответствующие им коннекторы и только при помощи их общаться с дочерним процессом.
   
8. Можно не делать process.join(), а просто читать результаты из output Pipe, они прочтутся только после того как попадут туда, что дальше будет происходить с процессом уже не важно (можно поставить return после записи в Pipe в дочернем процессе).
   

with open(path, 'w+') as f:
      f.write(json.dumps(data, indent=2, ensure_ascii=False).encode('utf-8'))

Используйте KVM switch

Простейший вариант…
1. Для каждой малой картинки выбрать «средний» цвет.
2. Уменьшить исходное изображение до M×N px, и в каждый пиксель вместо сплошного цвета подставить ту картинку, которая больше всего подходит по цвету.

Алгоритм можно совершенствовать — например, подставлять одну из 10 наиболее подходящих, а если в радиусе, скажем, 30 единиц есть куда больше 10 картинок — брать их все. А можно ещё использовать метод коррекции ошибок Флойда-Стейнберга (наиболее удачный метод при переводе картинок в N цветов)