a thread about janitoring individual bits and using oscilloscopes and stuff

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > YOSPOS > a thread about janitoring individual bits and using oscilloscopes and stuff

«‹›11 »

Bloody: Mar 3, 2013

we have good threads for software things but we don't have anywhere for hardware really so now we do

i know we got a lotta electrical engineers itf so lets talk about hardware

i mostly do like digital design and low-power microcontroller poo poo like msp430s n whatever

okay so the question that prompted this thread is like so usually when i wanna get bytes out of a computer into a thing i use like an ftdi usb-uart or similar. but what if i want to get data in/out faster?? how do i do like real usb or ethernet as painlessly as possible??

# ¿ Nov 25, 2014 19:36

Adbot: ADBOT LOVES YOU

# ¿ Apr 29, 2024 10:45

Bloody: Mar 3, 2013

avr supremacy is legit especially if you use xmegas, xmegas are dope

# ¿ Nov 25, 2014 19:40

Bloody: Mar 3, 2013

movax posted:

also avrs suck hth

atmegas suck but xmegas are like lower-power more featured msp430s

# ¿ Nov 25, 2014 20:29

Bloody: Mar 3, 2013

pcie sounds cool as hell but hard like how the hell do i write a pcie driver or whatever on the pc side??

# ¿ Nov 25, 2014 20:30

Bloody: Mar 3, 2013

Bloody posted:

atmegas suck but xmegas are like lower-power more featured msp430s

although some of the m0 and m3 silicon people are pumping out these days are just mind-bogglingly efficient

# ¿ Nov 25, 2014 20:31

Bloody: Mar 3, 2013

also atmel studio owns because it is visual studio

no iar or keil crap

# ¿ Nov 25, 2014 21:26

Bloody: Mar 3, 2013

The Management posted:

PCI driver in Linux is pretty easy to write. the problem with pcie is that it's difficult to debug the physical layer unless you have very good tools.

I2S is actually a super easy way to move a lot of data and you can get parts with pretty fast I2S channels. if your signal rate is higher, for higher rates usb is probably your best bet.

yea debugging sounds stressful. i only really need like 10s of mbits per second so idk pcie feels overkill for that

# ¿ Nov 25, 2014 21:43

Bloody: Mar 3, 2013

how do i spi from a pc :aaaaa:

i guess like ftdi modules have spi up to like 30mbits does that count

# ¿ Nov 25, 2014 22:42

Bloody: Mar 3, 2013

movax posted:

modern intel chipsets have a spi controller on them; no idea if you can do dma and such with them, but they exist. unfortunately, they're usually attached to the spi memory that holds your bios, so uh, i wouldn't use that.

# ¿ Nov 25, 2014 23:01

Bloody: Mar 3, 2013

surface mount is seriously easy to solder by hand if you have liquid flux and if you dont have liquid flux just get the gently caress out

# ¿ Nov 25, 2014 23:23

Bloody: Mar 3, 2013

mishaq posted:

hey bloody i jutst wanted to pop into say that for a party im going to i'm doing apple cider + fireball like this inspired by you

also this thread makes me realize im pretty dumb

thank you blooduy

good poo poo

# ¿ Nov 25, 2014 23:26

Bloody: Mar 3, 2013

I own no equipment so it owns Workin in a lab with like 100k network analyzers n metcal irons n poo poo

Not that I ever take advantage of this

Might for Santee though!

# ¿ Nov 26, 2014 01:42

Bloody: Mar 3, 2013

ChiralCondensate posted:

I (in a team with others) janitor these bits:

the cms forward pixel detector

dope

# ¿ Nov 26, 2014 02:42

Bloody: Mar 3, 2013

beep boop lmao

# ¿ Nov 26, 2014 05:25

Bloody: Mar 3, 2013

wish/hope im your santee

# ¿ Nov 26, 2014 05:25

Bloody: Mar 3, 2013

kwinkles posted:

its not you but it is another well known shamefully nerdy yosposter. if you want i can post my source code to be ridiculed, i am a bad c++ programmer and i am sure i write it all as if it were system verilog and everything happens in zero simulation time with no regard for actual resources.

tbf thats probably better than average

# ¿ Nov 26, 2014 05:58

Bloody: Mar 3, 2013

wheres the cheapest place to get loose tolerance full panel 1 or 2 layer boards

im not interested in toner transfer

# ¿ Nov 26, 2014 05:58

Bloody: Mar 3, 2013

z0rlandi viSSer posted:

we have cycles to fukkn spare like woah

your in the wrong thread m8

# ¿ Nov 26, 2014 06:47

Bloody: Mar 3, 2013

I bought a tm4c launchpad board last night. 20 bucks and a cortex m4 and a zillion peripherals n poo poo

# ¿ Nov 27, 2014 02:54

Bloody: Mar 3, 2013

Mido posted:

in my dumb opinion it's okay to waste cycles on simple applications in projects that don't need to scale or multi task much. get something done. optimize when it's time. structure your code base well so you can refactor your inefficiencies later

Epic thissery. The field owns though when you find yourself optimizing stack usage to save individual bytes because it means writing out to flash slightly less frequently and now you can meet or exceed your power requirements etc etc. Desktop software is like you're an artist with an arbitrarily large canvass and you have so much freedom and room for activities that your constraints wind up largely self imposed but on a lil microcontroller it's like you have the back of a postcard to get as much done as possible Idk I'm bad at analogies good night yospos

# ¿ Nov 27, 2014 03:47

Bloody: Mar 3, 2013

Locker Room Zubaz posted:

I messed around with FPGAs a little in college and thought they were really cool and I want to get back into them. Can anyone recommend a decent breadboard?

Yeah but only if by decent you mean expensive and horribly complex

Or at least expensive

Actually I'm not sure if it's expensive but the igloo nano dev kit is pretty cute and painless. Digilent (I think?) makes some decent educational stuff too iirc

# ¿ Nov 27, 2014 04:29

Bloody: Mar 3, 2013

kwinkles posted:

i read this and i think: faaaaaaart
just run x86 on it and be the fastest because that is how the real world works.

RIP power budget

# ¿ Nov 27, 2014 04:47

Bloody: Mar 3, 2013

I'm the through hole clown devices

# ¿ Nov 28, 2014 00:31

Bloody: Mar 3, 2013

Mr Dog posted:

there are still people using something other than Cortex-M chips for something that doesn't have to be ultra low power

smdh (i'm one of them, this project uses an STM8 because it needs to be dirt loving cheap but i mean apart from the IAR license wiping out the money we saved on the BOM cost several times over because this is a hilariously low volume product you could do worse)

poo poo i mean you can get actual application processor SoCs for like $10 these days if you're man enough to lay out some DDR lines

i write some fairly ownage firmware but i've never designed a PCB before and i'm not sure i'd want to start in a situation where my job depended on me not loving it up

also the other day i thought "hm, connecting AA batteries in series sums the voltage, right? ok just making sure" so yeah maybe i'm not the best man for that particular job

Aww yiss ddr termination

# ¿ Nov 28, 2014 01:55

Bloody: Mar 3, 2013

Their architecture is bad and their mips per mw or whatever power metric you want is bad

# ¿ Dec 1, 2014 05:24

Bloody: Mar 3, 2013

movax posted:

i'd be surprised if either the nexys-3 (spartan 6) or nexys-4 (artix 7) wouldn't be enough -- hopefully you can get academic pricing

microsemi's a low cost option but i think you'd need the igloo2 to fit everything

Idk one of their app notes crams an 8051 and some not cheap peripherals in a third of the 250

# ¿ Dec 1, 2014 16:03

Bloody: Mar 3, 2013

your program counter comes up in a known state (probably) or some sort of reset generator causes it to enter a known state (such as the reset vector) from there, code happens

# ¿ Dec 1, 2014 19:10

Bloody: Mar 3, 2013

like on msp430s or maybe its arm7s or something i forget it doesnt matter it always comes up at 0x0200 so if yo want a bootloader you stick its entry point at 0x0200 and go from there

# ¿ Dec 1, 2014 19:11

Bloody: Mar 3, 2013

install diptrace

# ¿ Dec 1, 2014 21:54

Bloody: Mar 3, 2013

yea that thing seems cool

iot is dumb as gently caress but it sure is making a lot of cool dev kits available for dirt cheap

# ¿ Dec 4, 2014 19:06

Bloody: Mar 3, 2013

I can't wait for my refrigerator to get a virus and melt all of my food so that I too can get a virus

# ¿ Dec 5, 2014 06:10

Bloody: Mar 3, 2013

Xmegas own because they are good chips with great and cheap/free tools

# ¿ Dec 5, 2014 06:34

Bloody: Mar 3, 2013

dang thats a long effort post

gonna go read it

pre-emptive good poo poo op

# ¿ Dec 5, 2014 19:18

Bloody: Mar 3, 2013

Mr Dog posted:

alright i might as well do an effortpost on usb as well. note that i don't know much about usb beyond 1.1 but eh 12mbit is still decently fast

at the PHY layer, usb is a half-duplex packet-oriented asymmetric broadcasting bus. there is exactly one host and since everything on the bus sees all traffic the devices only speak when spoken to. timeouts are very strict (a device has much less than 1ms in which to respond to a request). devices have an 8-bit address on the bus, zero when they are first attached. so your microcontroller's usb phy+mac will have hardware address recognition, and dma (or maybe some manually-shovelled dedicated FIFOs on poverty-tier hardware) is kind of non-optional given how fast it needs to react.

each device has between 1 and 16 "endpoints", which are addressable hardware DMA engines. EP0 is mandatory and needs to understand certain standardised metadata query and control messages. It is also very different to all of the others: it is bidirectional (all other endpoints are unidirectional, I think the odd ones are device->host and the even ones are host->device but it might be the other way around), and it also uses "control" transfers. ep0 is slightly confusing so i'll get back to it later.

"IN" and "OUT" are from the perspective of the host btw.

regular endpoints can be configured for bulk, interrupt, or isochronous operation. note that "interrupt" endpoints are actually polled because usb doesn't have real interrupt signalling, because of the stuff described above: devices only speak when spoken to, there isn't any csma/ca poo poo or w/e. this is actually a good thing, because it allows the host to perform hard realtime scheduling and guarantee bandwidth to the interrupt and isochronous endpoints, which it wouldn't be able to do if the bus was a mess of unpredictable collisions and retransmissions.

the type of endpoint mostly controls bandwidth guarantees. every 1ms the host broadcasts a start-of-frame packet on the bus (note: the timing stability on SOF packets is actually required to be very strict by the spec, so you could do a lot worse than using this as a timebase). within each 1ms frame you have various kinds of scheduling. i won't go into the exact packet sequences but essentially:

interrupt EPs: One packet in or out every X frames (where X comes from endpoint metadata, see below). USB 1.1 packets have a max size of 64 bytes btw so if X=1 then your max throughput is 64KB/sec (i.e. bad, don't transfer lots of data over interrupt EPs jfc). must use a fixed packet size pre-declared in endpoint metadata. USB HIDs (keyboards, mice, etc) are typical users of interrupt EPs.

isochronous EPs: really weird and hard to program for. One packet every frame, but these packets are special and are allowed to be as long as 1023 bytes. so these top out at about 1MB/s, i.e. most of the available bandwidth on a single USBus. must also use a fixed pre-declared packet size, i think. first in line for bus bandwidth; actually they are guaranteed their own dedicated slice of bandwidth in every frame. USB audio-video devices (mics, cameras) are typical users of iso EPs.

bulk EPs: these get whatever bandwidth is left over within the frame. still limited to 64 byte packets, but the host keeps pushing/pulling data until a packet shorter than 64 bytes is transferred. these can send variable-length packets, i think. USB mass storage devices are typical users of bulk EPs.

if you're programming a micro then the hardware register interface will operate at the endpoint level. you'll get sixteen sets of (base, length, flags, interrupt) registers that you can program and "arm" for DMA. when the host transfer comes in that DMA engine needs to be ready to go with a response RIGHT THE gently caress NOW (like, tens of microseconds or some poo poo) so your destination buffer or response packet needs to be prepared ahead of time. i mean i guess they'll all share an actual physical dma engine since only one endpoint on a device (or indeed even one device on the bus) can communicate at a time but w/e. but that should be your silicon "API", well, that and your 8-bit device address register which you'll need to program during discovery and association (aka "enumeration" because this is loving Microsoft writing the spec). and i guess a global status, flags, interrupt, and interrupt mask register. the shittiness of your usb silicon is directly proportional to how many other garbage registers you have with descriptions like "reserved" and "power-on reset value is 0x00, you must always set this to 0x71".

oh yeah, regarding the flags field in those ep registers: you can arm an EP in such a way as to send/recv a response, but you can also arm it to respond with a NAK packet (my buffers are full/empty, come back later) or a STALL packet (this endpoint is in an errored state, go away). unless it's an iso ep in which case you're not allowed to do that, the error handling is "welp, something went wrong, drop it on the floor and don't retry, just hit the EP again and try to transfer the next packet on the next frame, gottagofast". yeah i also think those two packet names are the wrong way around but there you go.

anyway, control transfers.

ep0 isn't an interrupt, bulk, or iso endpoint, it's a special unique "control" endpoint, and control transfers have three phases: a "setup" phase (very bad name), a payload phase, and an ack phase.

the setup phase OUTs a standard fixed-size i-guess-you-could-call-it-"topic" structure that contains a bunch of fields. First is a one-bit direction field, then what kind of logical entity on the usb device the transfer is addressed to: could be the device as a whole, an interface (more on these later), or an endpoint (confusing! the control transfer itself always physically travels over ep0, but it could contain a command that controls some other endpoint). most control transfers are addressed to the device as a whole. then there's a namespace identifier (standard command, class-specific command, or vendor-defined command). there's an 8-bit command code drawn from the namespace in question, and then there's ~~WPARAM and LPARAM~~ two general-purpose 16-bit parameters called wValue and wIndex. Well, wIndex is required to be used for the number of the EP or interface the request is targetting if the control transfer is aimed at an EP or interface.

payload is self-explanatory, and is absent if the setup packet declares a zero length payload. this aspect works kinda like a bulk in/bulk out: packets keep getting transferred until one of them is shorter than 64 bytes. your usb core's dma engine will probably automatically packetize the payload for you.

the ack phase is a zero-length data transfer that travels in the opposite direction to the direction the payload went (or would have gone, had it existed). the usb packet request/response pairs that the silicon sends behind the scenes do include ACKs, but those are silicon ACKs that say "yes i got your packet and the crc looks correct and so does the length and whoops my 10 microseconds are almost up gtg bye!", the explicit control ack is a higher-level thing. this actually comes, in the fullness of time, from the MCU program or host operating system, saying "yes i received your request and i have processed it". kinda like how TCP has ACKs but you still want to send SMTP "ok yes your email has been queued for transmission" acks, same idea. A NAK during this phase means the command is still processing, and a STALL indicates an error: normally a STALL requires some sort of heavy reset (i don't remember the specifics) to clear, but in the case of a control transfer the device is required to reset EP0 to a working state as soon as the next SETUP comes in.

this covers the actual mechanics of control transfers. let's talk about the control transfers a device needs to actually support.

this is probably a good time to introduce interfaces. interfaces are the logical units of functionality provided by your device, which can be vendor-specific or they can be standardised (HID, mass storage, media, communication, etc). Like for instance a USB3 laptop dock would have an audio interface for its headphone jack and a comms interface for its Ethernet port (Microsoft Remote NDIS typically ) and a mass storage interface for its internal SATA dock, whatever. I say "logical" because interfaces only really exist as structures within the device metadata. Each endpoint other than EP0 must be declared to belong to exactly one interface, though. EP0 logically belongs to all of them; recall that control transfers all physically travel over EP0 but they can logically be addressed to any interface or any EP. since interfaces don't correspond to hardware resources per se, just chunks of metadata, a device can have up to 256 of them in principle.

anyway, the most important command is the "get descriptor" command from the "standard" command namespace. this downloads various kinds of standardised metadata from a device and is the reason why usb can do plug-and-play poo poo, and it comes with two 8-bit parameters in the setup packet: a descriptor type, and a descriptor index. this is always addressed to the device as a whole, and the device will send back the descriptor binary in the payload phase of the setup transfer.

a "get descriptor" request with type=device downloads the device descriptor, containing the VID, PID, and a device class drawn from the same set of 8-bit class codes as interface classes (0 if you're a multi-function device with more than one interface, tbh you should always just say 0 here), also 8-bit indices into the "string descriptor" table for your manufacturer, product name, and serial number. note that, strictly speaking, a device is only allowed to draw 2 mA over USB until it negotiates with the host for a higher power consumption.

beneath the one unique device descriptor in the hierarchy of descriptors are one or more configuration descriptors. the vast majority of devices only have one configuration descriptor. this describes the power consumption of the device (in units of 2 mA, up to a max of 500 mA), and it also logically contains its own instances of all of the interface descriptors (which in turn physically incorporate endpoint descriptors). in principle, the host is supposed to pick a configuration from the device that the host is capable of satisfying based on the configuration's advertised power demand and how much committed bandwidth the isochronous endpoints, if present, require: alternative configurations might contain copies of the exact same interface and endpoint descriptors, but the iso endpoints in those particular copies might declare smaller packet sizes and hence require less committed bandwidth if there isn't enough to go around on the host's bus at the time the device is inserted.

in practice, configuration selection seems to be a solution in search of a problem and nobody really uses it i don't think? maybe AV devices with heavy iso bandwidth requirements do idk???? certainly nobody cares about the power negotiation thing and I think all modern motherboards are capable of powering every single port at full throttle simultaneously. still, technically, until the device has been told to adopt a particular configuration it is only allowed to consume 2 mA of current or less (0.002 A * 5 V = 10 milliwatts. Not a lot). Nothing actually cares these days, and you can chop off a USB plug and stick a 500 mA load across the VBUS and GND pins and your laptop probably won't complain when you plug it in, but this is the reason why BlackBerries would refuse to charge off a PC (or indeed a non-BBY wall wart) unless you installed a charging driver first: BBY was being pedantic about the spec despite the fact that nobody else was and despite the fact that this behaviour was hideously user-unfriendly.

"get descriptor" with type=interface is a bit more complicated. this downloads an entire hierarchical data structure: first the interface descriptor itself, followed by the descriptors for all of its endpoints, and then whatever standardised descriptors the interface class requires (like, if you're supplying an audio interface, how many channels you have and what your sample rate is, that kind of poo poo). this is all contatenated into one whole. endpoint descriptors mostly just describe what regime the EP operates in (bulk, interrupt, iso, etc).

again, endpoint descriptors actually get concatenated onto the descriptor of the interface they're associated with (non-EP0 endpoints must be grouped into exactly one interface, EP0 is considered part of every interface and has no EP descriptor at all, because the spec says exactly how it must operate). the host will never send "get descriptor" with type=endpoint, despite what you might naturally assume.

you can actually write C structure definitions that you can use to declare static const descriptors in C code or you could use an external compiler program that compiles this poo poo to a raw byte array that you can link in later, w/e. i know one crazy person who wrote a strongly typed C++11 template library to do it.

let's see, what other commands do you need to be aware of

well, there's "select configuration", which i mostly explained above, there's "set device address" i guess, once you've fully transmitted the acknowledgement you need to reprogram your usb device address register from zero to whatever address you were assigned.

probably some other poo poo too? i guess that's it.

anyway, if you don't want to create a standardised interoperable device then give it an interface whose class code is 0xFF (vendor specific), then write something using libusb or WinUSB on the host side that'll send control transfers with command codes in the vendor-specific namespace addressed to that interface (don't address them to the device, that's bad design. devices are just containers for interfaces, it is interfaces that actually hold functionality). if you need lower latency or greater throughput than what the high overheads of payloaded control transfers allow for then chuck in a few endpoints of the appropriate type too.

of course, windows is a piece of poo poo, and WinUSB is a fairly recent thing (and you still need to write a ~~necronomicon~~ INF file and install it in order for the kernel-side generic WinUSB driver to bind to your device and make it available to userspace), so what a lot of lovely ppl used to do back in the day was abuse the HID class and Windows' raw HID access API in order to do driverless user-mode USB. A lot of firmware updaters still do this. Please don't do this, it makes baby jesus cry.

if you do want to have a standard interface or two on your device, well, read the device class' documentation on usb.org bithc

A good intro that actually gives the details that you'd need to implement all the stuff I've skimmed over can be found here:

http://www.beyondlogic.org/usbnutshell/usb1.shtml

this is a really really good post

# ¿ Dec 5, 2014 19:32

Bloody: Mar 3, 2013

Jonny 290 posted:

i'm thinking of doing RGBW LED strips in Hausbus instead of christmas lights.

what would be a fun controller/board to use that isnt arduino. cheapside. not much power needed. i/o for a couple mode buttons or a spectrum pot would be fun

figure i can use whatever and just use pwm drivers

i just bought one of these and it is really cool although a similar thing but wifi could be cooler:
http://www.ti.com/ww/en/launchpad/launchpads-connected-ek-tm4c1294xl.html#tabs
has a metric shitton of gpio for blinking leds and has a ton of example code but trigger warning: code composer studio

# ¿ Dec 5, 2014 19:34

Bloody: Mar 3, 2013

yeah they've apparently amped up the wired poo poo into a arduino-like thing or something (energia???) but im an idiot masochist so i downloaded ccs

im pretty sure that bottom row is just every single cpu pin broken out to 0.1"

# ¿ Dec 5, 2014 19:42

Bloody: Mar 3, 2013

DuckConference posted:

well some guy made an fm transmitter out of a small uc and a battery because the main pll was reconfigurable fast enough for that to be viable way to modulate the core clock with audio frequencies, so as long as the pll lock is much shorter than the symbol duration I guess you could do it. doesn't do receiving, though

that owns

# ¿ Dec 5, 2014 21:44

Bloody: Mar 3, 2013

Illusive gently caress Man posted:

dope post. the chip i've been working with the last few days is slightly different though. There's no DMA. There's two registers I have direct access to (UADDR, UDATA) and then several other registers (most of which are bitfields for enabling/checking for interrupts on things like "a packet is ready in EP3-IN") which I can access through those two. Then i can read packets a byte at a time by (for example) setting UADDR to 'read bit' bitwise and the usb register number for the EP0-out buffer, waiting for the ready bit on UADDR to be set, and then reading UDATA to get my byte. Repeat 8 times for the whole setup packet. The chip has 2 IN endpoints, 1 OUT endpoint and ep0.

So far I've copied a bunch of example code from a the manual that makes the chip identify itself as a keyboard. I tried to adapt the code to make it easier to change into what i need (not a keyboard), and now it fucks up about 50% of the time (watching dmesg on the laptop I plug it into says it isn't sending the device descriptor or something). kinda weird that it sometimes works. maybe I slowed it down too much and it's timing out? god i hope not.

sdounds like your using the aforementioned poverty-tier hardware. sorry for your loss.

# ¿ Dec 6, 2014 07:47

Bloody: Mar 3, 2013

"who gives a gently caress"
"at mega"

# ¿ Dec 8, 2014 01:51

Adbot: ADBOT LOVES YOU

# ¿ Apr 29, 2024 10:45

Bloody: Mar 3, 2013

semon demon posted:

I did a ton of FPGA stuff in school like writin a few multicore processors in verilog and some weird video processsing poo poo and it was real fun but now I spend all day doin gay database garbage. Are there any non-stupid-expensive and non-ridiculous-toolchain FPGA's for general gently caress-around-ery out there?

a lot of the dev kits come with some sort of license like you can get a decent zynq kit for a couple hundred bucks with a not too crippled copy of vivado

# ¿ Dec 8, 2014 02:03

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > YOSPOS > a thread about janitoring individual bits and using oscilloscopes and stuff

«‹›11 »