на видосиках паяют пастами и жалом/Феном

пришес просить чем паять

Ответы тебе даны

про печки там ничего

про скф и пруток тоже

на видосиках паяют пастами и жалом/Феном

Забудь об пастах! Не твой случай

про скф и пруток тоже

Самый лучший вариани

потому и вопросил, что за пасты

потому и вопросил, что за пасты

Пасты для автоматической сборки. Наносятся, на них клеятся детали и в печку

потому и вопросил, что за пасты

Для ручной сборки они неприменимы

Гимор

Имхо

нее, без паст некотроые корпуса не спаять, у которых пады под пузом

нее, без паст некотроые корпуса не спаять, у которых пады под пузом

у меня кварцы такие

нее, без паст некотроые корпуса не спаять, у которых пады под пузом

Да? Ок!

у меня кварцы такие

Забей?все хорошо

пойдет или говно?

Хм...

Пиздато же

Под лупами реально кто-то паяет? Мне кажется я без нее лучше вижу, но я особо сам не паял

дык не в лупе дело

просто держалка нужна

Индексы массива с 0?

0 - начало пакета, $

упс завис после разговора о котиках)

а приоритет операций? что сначала ? сдвиг? или побитное или?

Сейчас гляну, хм

А в каком виде вообще отправляется float?

Ну то есть зачем так это делать, если можно прикастовать пакет к packed-структуре?

А в каком виде вообще отправляется float?

(uint8_t*)floatValue

и 4 байта по юарту таких

Подожди, а какого типа sinValue?

float_t

размеры совпадают- 4 байта

А потом ты из UART'а вытаскиваешь эти данные?

Ага

На х86?

У тебя там ведь порядок может не совпадать, я правильно понимаю?

x64, QT. проверил размер- тоже 4 байта

Сейчас еще кое-что прверю. чему на стороне приема равны эти байты

передачи*

Размер-то понятно, я про big-endian и little-endian.

да вроде как литл, от старшего байта к младшему

а. а перадаю я старший->младший.

хм..

Короче говоря, нельзя так делать, как ты делаешь :D

Я думаю, оно незаметно кастуется к int'у до присваивания к float.

как лучше сделать?

упаковать в структуру?

http://codeo.tk/pfMzu

Тут у тебя приоритет операций неверный.

У тебя & приоритетнее, чем плюс, если я правильно помню.

Да, верно, поставил просто посмотреть значения

У тебя взаимодействие какой-нибудь STM'ки с x86? В идеале, конечно, тебе передавать float в платформо-независимом виде, гарантированно отправляя байтики в Network byte order, например.

А на принимающей стороне преобразовывать к host order с помощью семейства функций http://beej.us/guide/bgnet/html/multi/htonsman.html

Если лень делать, то можешь, как и в http://codeo.tk/pfMzu, прикастовать так: float received = *((float *)(byteArray + 1))

Хотя если у тебя всё-таки STM, то на x86 и на ARM разный порядок хранения байт, и всё должно сломаться.

Да вот странно это/

Передается то нормально

хотя....

сейчас посмотрю порядок хранения байт там и там

Ты возьми мою программу, и в одном случае сделай printf, а в другом дебагером посмотри на каждый байт.

Главное, не проебись с порядком операций, а лучше всё в скобочки оберни.

Так.

СТМ литл эндиан..

а как сделать по-нормальному, можно статейку?

Господа, посоветуйте книг по архитектуре ЭВМ и цифровой электронике

Господа, посоветуйте книг по архитектуре ЭВМ и цифровой электронике

Харрисон, Харрисон.

Чтоб прям мочь вычислительные устройства делать)

Харрисон, Харрисон.

А как имя?

а как сделать по-нормальному, можно статейку?

Так говорю же. По-нормальному: приводить отправляемые данные на отправителе к одному и тому же порядку (network order). На принимаемой стороне переводить от network order к host order (там, где host order совпадает с network order, функция просто ничего делать не будет, если ты будешь использовать http://beej.us/guide/bgnet/html/multi/htonsman.html). А дальше кастовать к packed-структуре.

А как имя?

Извините, перепутал. Харрис, Харрис. http://files.nazaryev.ru/books/digital-design-and-computer-architecture-russian-translation.pdf

Спасибо

т.е. взять данные на СТМ, там заюзать перед передачей ntohs()

а на приеме заюзать htons()?

Наоборот, я думаю.

Тебе нужно Host-to-Network на STM и Network-to-Host на хосте/x86.

https://stackoverflow.com/questions/45116212/are-packed-structs-portable О, ребята даже packed-структуры не советуют использовать, ибо compiler-specific.

кто-то замерял наносекундные промежутки времени? 1-15ns со времени включения лазера и получения ответа (допустим лазер, его драйвер, фотодиод и т.п. - достаточно быстрые)

смотря с какой точностью надо

https://hastebin.com/yobabefufe.cpp У кого что выведет?:D

смотря с какой точностью надо

+-10ns

ну т.е. +- 5-15ns

промежуток может быть ~1500ns к примеру, скажем до 12 бит разрядности

я вот на CPLD посматриваю

я вот на CPLD посматриваю

Ес 10нс это точность то ваще изи

Генер 100 мег и счетчик из логики стандартной, они на 250 мег

Ят думал пикосекунды

Генер txco и ваще збс

мне скорее интересно - нельзя ли удешевить OTDR :) но это скорее так, умственные изыскания

а еще подумалось - если загнать FSMC в serdes и скормить SFP, получаем занедорого оптический линк?

а клок где?