|
Sagebrush posted:i ordered a couple of spark photons cause a $19 wifi thingie development board sounds cool to me. has anyone used the spark devices? how are they found it, disregard
|
#
?
Dec 4, 2014 06:42
|
|
|
|
| # ? Apr 23, 2024 11:46 |
|
|
are you telling me to disregard your post or to disregard the device? i like the idea of screwing around with wifi stuff but finding something capable of it for under 20 bucks has been nearly impossible and hey this has a 120mhz cortex on it as well
|
|
#
?
Dec 4, 2014 07:21
|
|
|
Sagebrush posted:are you telling me to disregard your post or to disregard the device? disregard my other post
|
|
#
?
Dec 4, 2014 07:22
|
|
|
Base Emitter posted:disregard my other post oh dont worry everyone already did seriously tho, those spark things seem really neat and I might end up ordering some
|
|
#
?
Dec 4, 2014 19:05
|
|
|
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
|
|
|
made even more cables, getting better each time real happy with the brady bmp21 labelmaker, prints right on shrink tubes and it looks pro as gently caress, labelling on each end of the cable. only annoyance is the tubes are a bit hard to shrink all the way and its tedious with 60+ labels to shrink, and the smallest size doesn't fit anything smaller than ~AWG 18 neatly. today i brought it to a whole 'nother level, brought out the lacing thread and proper knot technique, a bit tricky to make good ends with PTFE wiring but it's doable still glad we're outsourcing most of this for production, but it's nice to have properly built prototype hardware instead of hundreds of unlabelled flying leads, and i'll still get to do some patch wiring with all the wank i want for the final hardware
|
|
#
?
Dec 4, 2014 19:24
|
|
|
suffix posted:is codesourcery still a thing? yes. ARM hired them to make GCC not terrible for ARM targets. they've made some good progress. eschaton posted:how's LLVM/clang as an embedded compiler these days? should have pretty good ARM support. it is the default compiler for iOS so it's pretty good at arm (and the best arm64 compiler now that Apple open-sourced their backend). it took them a long time to figure out stuff that embedded targets need, but now they seem to be on it so they won't blow your stack up or break cortex m by putting in unsupported op codes. although they do have a knack for screwing up inline asm. It's probably my compiler of choice unless I'm really pressed for space.
|
|
#
?
Dec 4, 2014 19:28
|
|
|
quote:closed-source LLVM backend oh hey that thing everybody said wouldn't happen happened enjoy your  Community Edition though(oh wait lmao you actually want the poo poo to work?  )
|
|
#
?
Dec 4, 2014 19:33
|
|
|
longview posted:made even more cables, getting better each time the bmp21 is good
|
|
#
?
Dec 4, 2014 19:58
|
|
|
what do y'all use for lab notebooks? i've been using national computation books but they don't lay flat and tend to fray/dogear more than i like
|
|
#
?
Dec 4, 2014 20:21
|
|
|
for doodles and notes i like rhodias dotpads like these i like dotted paper so ymmv
|
|
#
?
Dec 4, 2014 20:25
|
|
|
i'm either gonna get a pic or hook up the bus pirate to this teensy thing and see what's goin on i guess thx for the help
|
|
#
?
Dec 4, 2014 23:53
|
|
|
Werthog 95 posted:i'm either gonna get a pic or hook up the bus pirate to this teensy thing and see what's goin on i guess thx for the help when I tried to figure out how usb worked on a low level in order to program a usb device it got way too complicated for me almost immediately. I do not recommend this unless you are a better programmer than me (probable) or you can find someone online who already has 90% of the work done (also probable)
|
|
#
?
Dec 5, 2014 00:38
|
|
|
today i started writing code for USB communication on a microcontroller. i have to write to raw rear end registers and poo poo. its dope.
|
|
#
?
Dec 5, 2014 00:41
|
|
|
Bloody posted:yea that thing seems cool i am sorry but before you can wash this load of laundry you need to update to LaundOS 4.3.7 or later. Update? Y/N:
|
|
#
?
Dec 5, 2014 00:49
|
|
|
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
|
|
|
i know the real EEs itt don't care for avrs but it's all i know and i am kind curious what's out there, so what are the cons of avr or the pros of other mcu families?
|
|
#
?
Dec 5, 2014 06:32
|
|
|
Xmegas own because they are good chips with great and cheap/free tools
|
|
#
?
Dec 5, 2014 06:34
|
|
|
putting "pic microcontrollers" on my resume got me a job interview once. that's pretty much the only salient pro I have.
|
|
#
?
Dec 5, 2014 06:47
|
|
|
maniacdevnull posted:i know the real EEs itt don't care for avrs but it's all i know and i am kind curious what's out there, so what are the cons of avr or the pros of other mcu families? other (good) chips are 32-bit arms which you can target with good compilers, also you don't have to worry about what color your pointers are because it's all one address space they're just as cheap too, since you're not doing massive volume of anything.
|
|
#
?
Dec 5, 2014 06:59
|
|
|
I remember losing my mind for a month trying to get USB going on a Freescale MCU, I gave up and moved onto validating other features like SDIO a week into SDIO I figured out that I wasn't enabling the loving DMA security bit on the MMU I think it was. SHITTTTTTTTTTT but it was too late and I couldn't go back and fix it, now I don't work there and I still think about the USB that could have been
|
|
#
?
Dec 5, 2014 07:03
|
|
|
Blotto Skorzany posted:what do y'all use for lab notebooks? i've been using national computation books but they don't lay flat and tend to fray/dogear more than i like vela workings makes good poo poo; i had work buy a shitload of the series-a2 and series-a2b
|
|
#
?
Dec 5, 2014 08:30
|
|
|
Bloody posted: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 and all this with 4 cores op
|
|
#
?
Dec 5, 2014 11:45
|
|
|
iirc the teensy handles the usb his side of things somehow, that was why id bought it in the first place. I think that's also why you find it in hacked mice
|
|
#
?
Dec 5, 2014 15:05
|
|
|
kinetis works i guess but like i said the register layout is just disgusting i'm the big-endian peripherals on a little-endian mcu no wait i'm the flash protection page at 0x400 that can brick your mcu if you write code over it. because why the gently caress not
|
|
#
?
Dec 5, 2014 15:58
|
|
|
Mr Dog posted:no wait i'm the flash protection page at 0x400 that can brick your mcu if you write code over it. because why the gently caress not months later, still lolin @ dis
|
|
#
?
Dec 5, 2014 16:13
|
|
|
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 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 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
|
|
#
?
Dec 5, 2014 18:23
|
|
|
dang thats a long effort post gonna go read it pre-emptive good poo poo op
|
|
#
?
Dec 5, 2014 19:18
|
|
|
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
|
|
#
?
Dec 5, 2014 19:19
|
|
|
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 this is a really really good post
|
|
#
?
Dec 5, 2014 19:32
|
|
|
Jonny 290 posted:i'm thinking of doing RGBW LED strips in Hausbus instead of christmas lights. 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
|
|
|
holy hell, look at all those pins isn't there some open source alternative to the TI tools?
|
|
#
?
Dec 5, 2014 19:40
|
|
|
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
|
|
|
one of my 2015 goals is to figure out a microcontroller solution for transmitting and receiving AFSK without a dedicated modem chip. then I can strap this to a $30 chinese ham radio and have a $70 packet radio node that I can hook up to whatever and do neat things with. there doesnt really seem to be a solution to this right now. theres an arduino modem board that'll do it but it's $$$$ and feels too Commodore-1541 to me
|
|
#
?
Dec 5, 2014 19:45
|
|
|
Jonny 290 posted:one of my 2015 goals is to figure out a microcontroller solution for transmitting and receiving AFSK without a dedicated modem chip. then I can strap this to a $30 chinese ham radio and have a $70 packet radio node that I can hook up to whatever and do neat things with. 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
|
|
#
?
Dec 5, 2014 21:14
|
|
|
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
|
|
|
yeah i saw that but all i'm trying to do is modulate and demodulate 2400 bps AFSK audio on the board. i'll provide an audio pipe in and out to a real transmitter. I kind of don't believe in SDRs for everyday use yet
|
|
#
?
Dec 5, 2014 21:50
|
|
|
I was never that good at microcontrollers I just liked them because I thought "wow you can take a circuit that requires hundreds of logic gates and just program a single chip to do it!" 
|
|
#
?
Dec 5, 2014 22:13
|
|
|
i've seen a few decades now of connectivity issues, like, you look at a gadget in one room that you want to control from another room and you're like "man i wish there was a little single task computer i could program to just basically push the buttons on this dumb thing" and that's what microcontrollers are to me, really. really good ways to interface the physical and electronic worlds
|
|
#
?
Dec 5, 2014 22:17
|
|
|
|
| # ? Apr 23, 2024 11:46 |
|
|
I'm pretty much the opposite now because I don't like high level programming but I want to know how to build things out of transistors
|
|
#
?
Dec 5, 2014 22:19
|
|