Ну, в реализации CDC-ACM, видимо, тоже не боги пакеты по горшкам раскладывают, если накосячили в EEM, кто мешает сделать аналогичный баг в ACM. (И вообще мне кажется это один и тот-же баг...)
Т.е. если CRC не совпала, пакет надо-бы перепослать, но кто такой стандарт чтобы указывать что нам делать?
urx, похоже что ваша STM не проверяет пришло ли ACK для текущего пакета, и тупо шлет следующий, в то время как хост думает, что она честно перепосылает предидущий.
А фразы типа «Соответственно мы из следующего пакета вычитываем N потерянных байт, а следующие данные воспринимаем как начало нового EEM-пакета и интерпретируем первые 2 байта как заголовок.» заставляют шевелиться волосы на голове.
Ладно потеряли пакет из середины, а что контрольную сумму итогового TCP пакета никто не проверял??
И кто-бы вы думали виноват??? и USB я стал любить чуть меньше, чем раньше.
Вы с какого процессора ассемблер изучать начали?
Я таких извращений даже на 8080 не встречал. Чем-то MCS-51 напоминает, разве что.
Не заставляйте новичков разбирать такое, да еще без комментариев. Садизм-же.
Эквивалентный код:
Могу посоветовать реализовать IrDA (только нижиний протокол естественно). Из обвязки — только светодиод.
Когда игрался с тиньками было очень удобно. Правда нужен приемник который имеет инфракрасный порт и умеет к нему обращаться на низком уровне.
Я использовал ПДА-ку HP2210. Никаких плясок с проводами и преобразованием уровней. И логи можно посмотреть в любом сарае (или в машине, когда я ODB-I диагностику пытался ковырять).
Если кому интересно могу выложить исходники.
А вообще 13 тинька была хороша лет 8 назад. Сейчас за те-же деньги есть контороллеры с кучей готовых интерфейсов.
Правда, теперь наш процесс из двухчастичного (электрон — фотон) стал трехчастичным, что существенно снизило его вероятность. Для светодиода это значит, что из всех электронов в зоне проводимости лишь немногие смогут излучить фотон – а значит, мы заметно проиграем в КПД.
—
А дефекты для оптоэлектроники – это не просто плохо, а очень плохо: они здорово захватывают носители и позволяют им рекомбинировать безызлучательно, резко уменьшая КПД.
Когда сам собирался, еще только, ехать нашел забавный хак на эту тему.
Если знаешь когда, кем, и в какую контору устроился человек, то с хорошей вероятностью можно найти его зарплату здесь: www.h1bwage.com/
(правда это для h1b только)
я не интересовался этим вопросом, потому не расскажу. но на форумах типа forum.privet.com и govorimpro.us есть множество тем об этом.
единственное что знаю — очень не рекомендуется после подачи на беженство посещать свою страну хотя-бы лет 5.
Можно. В случае если находясь на этой визе вступаете в брак с гражданином США. Но потом у ваших родственников будут большие проблемы с получением любых виз в США.
Или если будете подаваться как беженец. Но тогда надо будет придумывать почему вы опасаетесь за свою жизнь в родной стране.
не. У них даже шире это понятие. На визе B1/B2 нельзя:
1. Получать деньги из американского источника
2. Выполнять любую работу, за которую американец мог-бы получать деньги.
3. Нельзя работать волонтером (бесплатно), даже если самим амерканцам за эту работу не платят.
Одна из стандартных причин отказа в визе приезжающим родителям, если они на собеседовании говорят, что едут посидеть с внуком. Для консульства это означает, что они собираются ехать работать babysitter-ом. И не важно что к своим-же детям.
вот я тут как сильно третье лицо скажу: мне очень не нравится их формат чисто рекламных публикаций. Но не нравится мне он именно в части рекламы. А вот наполнение очень даже интересное обычно.
Поэтому я вам предлагаю читать эти статьи немного в другом виде. Заменять шапку вида «Мы прогнали наш продукт на исходниках...», на что-то типа «Мы заставили 1000 индусов просмотреть код ...».
А дальше-то прикольные вещи идут. И не важно что 1000 индусов смотрели не сам исходный код, а логи их продукта. Прикольные вещи они и правда находят.
А вот оценивать что эффективнее просматривать исходники или логи — это не программерское занятие.
то, что он пытается доказать — это хорошо.
то, что он, на основе этих доказательств, пытается сделать код короче/быстрее — это просто превосходно.
но вот когда я, ваяя свой код, должен задумываться не о своих алгоритмах, а о том, что взбредет в голову gcc — это, простите, п… ц.
Т.е. если CRC не совпала, пакет надо-бы перепослать, но кто такой стандарт чтобы указывать что нам делать?
urx, похоже что ваша STM не проверяет пришло ли ACK для текущего пакета, и тупо шлет следующий, в то время как хост думает, что она честно перепосылает предидущий.
А фразы типа «Соответственно мы из следующего пакета вычитываем N потерянных байт, а следующие данные воспринимаем как начало нового EEM-пакета и интерпретируем первые 2 байта как заголовок.» заставляют шевелиться волосы на голове.
Ладно потеряли пакет из середины, а что контрольную сумму итогового TCP пакета никто не проверял??
И кто-бы вы думали виноват???
и USB я стал любить чуть меньше, чем раньше.
Я таких извращений даже на 8080 не встречал. Чем-то MCS-51 напоминает, разве что.
Не заставляйте новичков разбирать такое, да еще без комментариев. Садизм-же.
Эквивалентный код:
По той-же причине не сильно в курсе про других производителей, но вот, например, что бытро нашлось в поиске:
www.mouser.com/ProductDetail/Freescale-Semiconductor/MC9S08QG4CFQE/?qs=ATe30Cu2%2Ft4gtg2g9GwdXQ%3D%3D
Когда игрался с тиньками было очень удобно. Правда нужен приемник который имеет инфракрасный порт и умеет к нему обращаться на низком уровне.
Я использовал ПДА-ку HP2210. Никаких плясок с проводами и преобразованием уровней. И логи можно посмотреть в любом сарае (или в машине, когда я ODB-I диагностику пытался ковырять).
Если кому интересно могу выложить исходники.
А вообще 13 тинька была хороша лет 8 назад. Сейчас за те-же деньги есть контороллеры с кучей готовых интерфейсов.
—
А куда уходит энергия в этих случаях?
Если знаешь когда, кем, и в какую контору устроился человек, то с хорошей вероятностью можно найти его зарплату здесь: www.h1bwage.com/
(правда это для h1b только)
И как из газа делают нити?
единственное что знаю — очень не рекомендуется после подачи на беженство посещать свою страну хотя-бы лет 5.
Или если будете подаваться как беженец. Но тогда надо будет придумывать почему вы опасаетесь за свою жизнь в родной стране.
1. Получать деньги из американского источника
2. Выполнять любую работу, за которую американец мог-бы получать деньги.
3. Нельзя работать волонтером (бесплатно), даже если самим амерканцам за эту работу не платят.
Одна из стандартных причин отказа в визе приезжающим родителям, если они на собеседовании говорят, что едут посидеть с внуком. Для консульства это означает, что они собираются ехать работать babysitter-ом. И не важно что к своим-же детям.
вроде создатели gcc что-то слышали о прерываниях. и даже включили термин «interrupt» в свой язык.
ну да бог с ним. нонешнее поколение не очень любит микроконтроллеры и программирование драйверов.
но есть всеми любимая многопоточность. неужели и тут мне придется рассказывать gcc, что глобальную переменную может поменять не только он сам?
Поэтому я вам предлагаю читать эти статьи немного в другом виде. Заменять шапку вида «Мы прогнали наш продукт на исходниках...», на что-то типа «Мы заставили 1000 индусов просмотреть код ...».
А дальше-то прикольные вещи идут. И не важно что 1000 индусов смотрели не сам исходный код, а логи их продукта. Прикольные вещи они и правда находят.
А вот оценивать что эффективнее просматривать исходники или логи — это не программерское занятие.
то, что он, на основе этих доказательств, пытается сделать код короче/быстрее — это просто превосходно.
но вот когда я, ваяя свой код, должен задумываться не о своих алгоритмах, а о том, что взбредет в голову gcc — это, простите, п… ц.
gcc обмануть?
дык для того специальное слово есть — volatile
самое смешное, что доказывать приходится обратное. Вот есть у тебя глобальная переменная interrupt_has_occured.
ну и цикл:
interrupt_has_occured = 0;
while(!interrupt_has_occured);
дык вот пока ты не расскажешь gcc, что эта переменная-то у тебя volatile, он будет включать режим «недопараноика», и делать бесконечный цикл.