естественный фон пусть 10мкР/час.
1 рентген — ионизация 2e9 элекронов в воздухе в 1см3.
то есть при естественном фоне в кубическом сантиметре будет 20 000 электронов в час или 5 электронов в секунду.
фемтоамперные токи пожалуй вполне можно измерять, пара фА это 10000 электронов в секунду, то есть для одного пикселя нужна ионизационная камера в 2000см3, ну или размер пикселя около 10х10х10см.
то есть можно взять две пластины 0.5м х 0.5м с расстоянием ~10см, на одной натянуть вертикальные провода, на другой горизонтальные, на вертикальные провода по очереди подавать напряжение ~30В, для 10см вроде больше не надо. а горизонтальные провода подключить к какому-нибудь DDC264 — получится очень небыстрый сенсор для естественного фона с разрешением 64х64.
останется лишь объектив для него соорудить :)
возможно и ошибаюсь, откуда именно цифры — не скажу (не помню), но флэш вроде бы может начать сбоить набрав единицы Грэй, то есть около сотни Рентген, характерные дозы на снимок, типа флюорографии — милиРентген. Микросхемы/печатные платы не столь прозрачны как легкие, так что там и энергии повыше да и дозы побольше могут быть.
но всё равно разница получается примерно 3-5 порядков.
Ну никакого нового функционала нет, только прошивка неродной конфигурационной памяти, штатным бластером.
Протокол общения с бластером впринципе известен, BSDL файлы для цыклона есть, команды для для работы с флешью — в её даташите, то есть если уж изобретать велосипеды, можно было и самому программатор соорудить который будет шить данный «нестандартный» флэш через усббластер как напрямую(такой велосипед я и сам делал, хотя и готовых наверняка хватает), так и через дрыгание ногами подопытной плис через jtag, что даже дополнительного коннектора к памяти не потребует.
Беглый осмотр даташитов M25P32 и EPCS показал что размеры секторов(65К) и страниц(256) абсолютно одинаковые, соответственно единственное различие, которое и не нравится программатору это прочитанный ID, что очень легко вылечить, убедив его, что он всегда читает правильный ID, не влезая при этом в сам процесс программирования и ничего там не модифицируя.
А вообще подход описанный автором конечно правильный. Ещё более правильный путь это, пожалуй, иметь возможность обновления флэша в самой боевой прошивке, и просто загружать её через jtag, а затем «обновляться» штатными средствами, но такой отдельный небольшой велосипедик тут тоже подходит.
Раз флэшки сами по себе совместимы и только альтеровскому программатору не нравится прочитанный ID (что есть свинство со стороны альтеры, можно же было сделать предупреждение «ID не совпали, продолжить на свой страх и риск?», но ведь кто тогда будет покупать их флэш втридорога), то тогда можно со спокойной совестью взять в руки ollydbg и просто объяснить программатору, что не надо ругаться на несовпадение ID, а лишь выполнить пару nopов вместо перехода на обработку ошибки и продолжить работать как ни в чём ни бывало.
Крайности при том, что кто-то вместо обёртки для того же gpio в виде макросов, предлагает их запретить совсем, и использовать другие обёртки, а ведь на плюсах можно сделать обёртку куда более страшную, за примерами далеко ходить не надо.
Оператор goto вот тоже считается что использовать плохо, сколько раз он в исходниках ядра линукса встречается?
Есть и другая крайность, arudino, и потом начинаются вопросы, а почему
while(1) {digitalWrite(ledPin, HIGH); digitalWrite(ledPin, LOW);}
мигает на частоте всего несколько кГц, а не МГц.
Макросы конечно впринципе зло, и не нужны, есть const и inline.
Но вот для gpio так называемые макросы Волкова, когда в одном месте можно описать порт, пин, активное состояние, тип выхода, ..., — зло оправданное.
#define PIN_LED PORTA, 4, H
toggle(PIN_LED);
Тип чего тут проверять? вместо PIN_LED туда что попало засунуть не получится.
но в релизе 2.3 того что показано в видео — ведь нет?
да, калькулятор есть, без но переменных параметров толку от него не много, один раз «20+30» я и во внешнем калькуляторе посчитать могу.
не хватает именно переменных, а потом возможно захочется и несложных функций, хотя бы sin/cos например, и тогда уже может оказаться что ту же lua прикрутить проще чем делать свой велосипед.
Ещё один довод против подобных велосипедов: если например ввести в качестве длины «sqrt(100», без закрывающей скобки solvespace просто падает.
з.ы. заглянул сейчас в код, да есть вроде и параметры но как этим пользоваться в программе не нашел :(
нет, не накинутся.
вообще комментарий даже был больше к aslepov78
что мол пользователю для действий, как в видео: a+5, 2*a, и т.д. обязательно нужен DSL и на основе именно С#, а не какая-то там поделка.
хотя там и lua-то не нужна, просто её прикрутить может оказаться проще чем самому писать очередной «калькулятор» для разбора арифметических действий.
Если у него графический интерфейс, а то и вообще работает в браузере, то честно говоря, абсолютно без разницы на чём он там внутри написан, хоть на brainfucke. Особенно если исходники не открыты :)
а причём тут solverspace?
Вы похоже хотите openSCAD на C#.
Я же предложил лишь добавить некую параметризацию в solverspace, чтобы не только циферки можно было задавать в констрейнах.
Про IDE, и что там за армия разрабов — отдельный вопрос. Так же как то, как это вообще может помочь в описании геометрии на DSL основанном на C#.
прикручивать до-диез для того чтобы можно было выражения вроде a+b заданные пользователем посчитать, да возможно позвать тригонометрические функции какие-нибудь, вот уж действительно в топку.
странно что нет задачки про гномов и двухцветные шапки.
ну и ещё одна, больше на пространственное воображение: как повесить картину на веревке на два вбитых гвоздя, чтобы при выдёргивании любого из них она падала.
USBIP должен пробросить USB через ethernet прозрачно, как будто бы железка подключена к локальному usb.
Никаких протоколов реализовывать не надо.
но в каком оно сейчас состоянии — не знаю. последние обновления были в 2012.
SolveSpace отличный, единственно чего немного не хватает, так это переменных параметров. Вот его бы совсем чуть-чуть с openscadом скрестить, совсем красота получится.
Eсть допустим несколько базовых параметров из которых вытекают большинство остальных размеров, вот их неплохо бы задавать непосредственно в текстовом виде: baseLenght = 50.
чтобы в нужные констрейны, например длины, потом вписывать не конкретную цифирку, а выражение baseLength*5, которое вычисляется и конвертируются в цифру не в момент ввода один раз, а пересчитывается при изменении.
Это всё можно и сейчас сделать через lenght ratio и difference, но хотелось бы задавать параметры непосредственно.
Lua, например, всунуть ему в качестве интерпретатора заданных констрейнов, и писать туда какие угодно выражения, а не только цифры.
1 рентген — ионизация 2e9 элекронов в воздухе в 1см3.
то есть при естественном фоне в кубическом сантиметре будет 20 000 электронов в час или 5 электронов в секунду.
фемтоамперные токи пожалуй вполне можно измерять, пара фА это 10000 электронов в секунду, то есть для одного пикселя нужна ионизационная камера в 2000см3, ну или размер пикселя около 10х10х10см.
то есть можно взять две пластины 0.5м х 0.5м с расстоянием ~10см, на одной натянуть вертикальные провода, на другой горизонтальные, на вертикальные провода по очереди подавать напряжение ~30В, для 10см вроде больше не надо. а горизонтальные провода подключить к какому-нибудь DDC264 — получится очень небыстрый сенсор для естественного фона с разрешением 64х64.
останется лишь объектив для него соорудить :)
но всё равно разница получается примерно 3-5 порядков.
те что побольше, ECP, загружаются снаружи.
Протокол общения с бластером впринципе известен, BSDL файлы для цыклона есть, команды для для работы с флешью — в её даташите, то есть если уж изобретать велосипеды, можно было и самому программатор соорудить который будет шить данный «нестандартный» флэш через усббластер как напрямую(такой велосипед я и сам делал, хотя и готовых наверняка хватает), так и через дрыгание ногами подопытной плис через jtag, что даже дополнительного коннектора к памяти не потребует.
Беглый осмотр даташитов M25P32 и EPCS показал что размеры секторов(65К) и страниц(256) абсолютно одинаковые, соответственно единственное различие, которое и не нравится программатору это прочитанный ID, что очень легко вылечить, убедив его, что он всегда читает правильный ID, не влезая при этом в сам процесс программирования и ничего там не модифицируя.
А вообще подход описанный автором конечно правильный. Ещё более правильный путь это, пожалуй, иметь возможность обновления флэша в самой боевой прошивке, и просто загружать её через jtag, а затем «обновляться» штатными средствами, но такой отдельный небольшой велосипедик тут тоже подходит.
habrahabr.ru/post/110395
habrahabr.ru/post/302570
а тут всего лишь размер сектора поправить если вдруг не совпадёт :)
Оператор goto вот тоже считается что использовать плохо, сколько раз он в исходниках ядра линукса встречается?
IAR с++ позволяет, но денег за это хочет.
while(1) {digitalWrite(ledPin, HIGH); digitalWrite(ledPin, LOW);}
мигает на частоте всего несколько кГц, а не МГц.
Макросы конечно впринципе зло, и не нужны, есть const и inline.
Но вот для gpio так называемые макросы Волкова, когда в одном месте можно описать порт, пин, активное состояние, тип выхода, ..., — зло оправданное.
#define PIN_LED PORTA, 4, H
toggle(PIN_LED);
Тип чего тут проверять? вместо PIN_LED туда что попало засунуть не получится.
Да, есть шаблоны, и можно сделать не хуже по потреблению флэша/памяти
www.webalice.it/fede.tft/stm32/stm32_gpio_and_template_metaprogramming.html
но для каких-нибудь, например, 8051 или stm8 есть бесплатный с++ компилятор?
да, калькулятор есть, без но переменных параметров толку от него не много, один раз «20+30» я и во внешнем калькуляторе посчитать могу.
не хватает именно переменных, а потом возможно захочется и несложных функций, хотя бы sin/cos например, и тогда уже может оказаться что ту же lua прикрутить проще чем делать свой велосипед.
Ещё один довод против подобных велосипедов: если например ввести в качестве длины «sqrt(100», без закрывающей скобки solvespace просто падает.
з.ы. заглянул сейчас в код, да есть вроде и параметры но как этим пользоваться в программе не нашел :(
вообще комментарий даже был больше к aslepov78
что мол пользователю для действий, как в видео: a+5, 2*a, и т.д. обязательно нужен DSL и на основе именно С#, а не какая-то там поделка.
хотя там и lua-то не нужна, просто её прикрутить может оказаться проще чем самому писать очередной «калькулятор» для разбора арифметических действий.
Вы похоже хотите openSCAD на C#.
Я же предложил лишь добавить некую параметризацию в solverspace, чтобы не только циферки можно было задавать в констрейнах.
Про IDE, и что там за армия разрабов — отдельный вопрос. Так же как то, как это вообще может помочь в описании геометрии на DSL основанном на C#.
ну и ещё одна, больше на пространственное воображение: как повесить картину на веревке на два вбитых гвоздя, чтобы при выдёргивании любого из них она падала.
Никаких протоколов реализовывать не надо.
но в каком оно сейчас состоянии — не знаю. последние обновления были в 2012.
Eсть допустим несколько базовых параметров из которых вытекают большинство остальных размеров, вот их неплохо бы задавать непосредственно в текстовом виде: baseLenght = 50.
чтобы в нужные констрейны, например длины, потом вписывать не конкретную цифирку, а выражение baseLength*5, которое вычисляется и конвертируются в цифру не в момент ввода один раз, а пересчитывается при изменении.
Это всё можно и сейчас сделать через lenght ratio и difference, но хотелось бы задавать параметры непосредственно.
Lua, например, всунуть ему в качестве интерпретатора заданных констрейнов, и писать туда какие угодно выражения, а не только цифры.