сколько из-за того что он 1 мегаом

это всё нч осцилы для максимум пары десятков мег

тоесть фронт в быстрой логике ты уже не увидишь

в моих схемах бывают сигналы цифровые длиной несколько нсек, и осцилы мегомные с их говнощупами их не видят вообще, как будто не было никогда

для этого они и не предназначены, да и не позиционируются для этих целей. это больше для радиолюбителей и "неприхотливых" задач.

и полоса пропускания это ладно, самое неприятное это как раз то, что у них частота дискретизации и так в скромные 1GSa/s делится между активными каналами емнип

так а смысл в высокой дискретизации

прескейлер правильно там минус единица?

Upcounting mode In upcounting mode, the counter counts from 0 to the auto-reload value (content of the TIMx_ARR register), then restarts from 0 and generates a counter overflow event. --- похоже не только psc -1 надо, но и arr. Раз с нуля идет. но погоды это не сделает, т.к. там разница не в мсек, а в доли на 1мс :-)

кому интересен ответ вопроса по таймерам... на 1сек было вчера 1.1мс набега... теперь десятки мксек!

на 10 сек - пол мсек!

на 48МГц был код PSC = 48 ARR = 1000 так же были варианты PSC = 47 ARR = 1000 и PSC = 47 ARR = 999 и PSC = 48 ARR = 999 все они шли неправильно, с набегами большими

рабочий с указанными погрешностями оказался PSC = 0 ARR = 47999 чтение даташита ясности не принесло, помог калькулятор от этих товарищей они как-то весьма странно генерируют эти коэф.

кому интересен ответ вопроса по таймерам... на 1сек было вчера 1.1мс набега... теперь десятки мксек!

попробуй ради интереса PSC=6, ARR=6857

1.5мксек это можно списать на LL_TogglePin, оно как раз на столько и тормозное

хотя нет, с 0/47999 получается вообще красиво

Подскажите по Altium Designer. При пересечении проводников альтиум ставит узел в этом месте, а мне нужно просто два проводника провести.

кликни на него

На кого?

ну а ты как думаешь?

Наркоман что ли?

Уже сам разобрался

Эт чё, любое пересечение он воспринимать будет как контакт ?

Эт чё, любое пересечение он воспринимать будет как контакт ?

а нехуй спагетти мотать, есть обозначение имени цепи

Мдя, как то не удобно

Эт чё, любое пересечение он воспринимать будет как контакт ?

Да, если точку нарисовал.... если мостик - нет. но дело не в этом было. Я резисторы слишком близко поставил и он цеплялся к концам их выводов

Понятно

На последней картинке мостик - это не пересечение

Эт чё, любое пересечение он воспринимать будет как контакт ?

в настройках задается, ставить ли узел при пересечении проводников можно и без мостика

На картинке он попадает в пин резюка. отодвинь подальше резюк.

Стандартно вместе пересечения нет точек.

На картинке он попадает в пин резюка. отодвинь подальше резюк.

Спасиб, я уже догадался

Стандартно вместе пересечения нет точек.

Да. Видать парень не удержался и нажал в горизонтальной линии.

коллеги, никто не знает чатиков по крипто? А то вопросец мелкий назрел: Требуется помощь тех, кто соображает в криптографии, т.к. мои познания в теме очень поверхностны. Задача - сделать алгоритм формирования ключа из passphrase, чтобы он не перебирался слишком просто на ASIC/GPU/FPGA (как например PBKDF2). Функция такова: Есть фиксированный salt[X] Есть password первый оборот - intermediate[0] = SHA512(salt+password) intermediate[n] = SHA512(intermediate[0] + ... + intermediate[n-1]) (т.е. хешируем все бОльший и больший блок) Т.е. упор на то, что в последующих оборотах используется материал всех предыдущих(чтобы не параллелили), и к концу обьем используемой памяти растет(чтобы не засунули в ASIC/FPGA с быстрой памятью перебирающий в несколько потоков) Конечное вычисление = последний оборот. Имеет ли право на жизнь такое? я в электрониксе на форум кинул - тишина, проект опенсорц, потому не хочется пихать туда что попало, хоть какой-то совет хочется, может где-то есть очевидная ошибка

А чем PBKDF2 не устраивает?

Еще есть scrypt и bcrypt

Ни одна из этих функций не параллелится в том контексте, как написано в сообщении, scrypt еще при этом адски жрет память

На scrypt ASIC сделали, bcrypt использует blowfish, в котором есть уязвимости PBKDF2 вообще элементарно в железо засовывается, и т.к. он применяется в wifi - то наверняка уже есть как минимум ip core для FPGA (хотя и возможно не для sha512), в любом случае он не использует значительный обьем памяти, это является одним из методов защиты от запихивания в железо

Все функции параметризированы. Ничего не мешает выкрутить параметры так, что сделать что-то будет проблематично

Особенно scrypt, которому можно потребовать в параметрах, что нужно хоть мегабайт, хоть гигабайт памяти

+ scrypt в эту память еще и пишет очень активно, в самодельной функции её в основном читают, более того - последовательно (в scrypt случайный доступ)

хм, действительно

ERROR: S client not available

просто хочется все таки еще и простой и компактный код, возможно это приемлимый "обмен"

коллеги, никто не знает чатиков по крипто? А то вопросец мелкий назрел: Требуется помощь тех, кто соображает в криптографии, т.к. мои познания в теме очень поверхностны. Задача - сделать алгоритм формирования ключа из passphrase, чтобы он не перебирался слишком просто на ASIC/GPU/FPGA (как например PBKDF2). Функция такова: Есть фиксированный salt[X] Есть password первый оборот - intermediate[0] = SHA512(salt+password) intermediate[n] = SHA512(intermediate[0] + ... + intermediate[n-1]) (т.е. хешируем все бОльший и больший блок) Т.е. упор на то, что в последующих оборотах используется материал всех предыдущих(чтобы не параллелили), и к концу обьем используемой памяти растет(чтобы не засунули в ASIC/FPGA с быстрой памятью перебирающий в несколько потоков) Конечное вычисление = последний оборот. Имеет ли право на жизнь такое? я в электрониксе на форум кинул - тишина, проект опенсорц, потому не хочется пихать туда что попало, хоть какой-то совет хочется, может где-то есть очевидная ошибка

этим требованиям отвечает CryptoNight

Ну тут к простому и компактному коду даже близко нет ничего

scrypt требует дохрена памяти, возможно, намешав кучи всяких алгоритмов можно потребовать еще дохрена вычислительных блоков в потенциальной аппаратной реализации

Но на практике — неуловимый джо и все такое, scrypt-а с сильными параметрами хватит с головой

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

по идее, подняв у scrypt memory segment size, это уже сделает проект несовместимым с существующими спец. устройствами

да даже если и совместимо - скорость уронит значительно по идее еще можно мою схему доработать и сделать выборку из большого куска побайтно так, чтобы DDR память работала максимально неэффективно

большое спасибо за советы! отойду на часик

не только, я с ним работаю локально, репозиторий на этом же компе

И опять вопрос к знатокам C/C++

class CharBuff { private: char _value[10]; public: CharBuff(): value(_value) {} const char* const value; }

value в public - ссылка на массив _value. В _value вижу нужные данные, а в value - мусор, указатель не на начало _value

ЧЯДНТ ?

так оно таки конст или не конст? и почему не инициализировано тогда

А давай наоборот - что ты хочешь получить? Потому что сейчас это фигня какая-то

Особенно мне нравится value(_value). Тут же тебе компилятор должен был обматериться со всех сторон.

хочу чтобы value - был указатель на начало _value

Чтобы в value было то что и в _value

так оно таки конст или не конст? и почему не инициализировано тогда

инициализируется же в конструкторе

Особенно мне нравится value(_value). Тут же тебе компилятор должен был обматериться со всех сторон.

не матерится, IAR

не матерится, IAR

(задумчиво) Интересно, как это тогда интерпретировал ...

Чтобы в value было то что и в _value

{ value = & _value[0]; } в конструкторе. и убери value(_value)

Я не знаю, как iar интерпретировал value(_value), но я бы сказал, что ты пытаешься унаследоваться от const char* const и вызвать конструктор полученного с _value в качестве аргумента. Я бы охренел.