|
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
|
#
¿
Nov 28, 2014 01:24
|
|
|
|
| # ¿ Apr 29, 2024 11:01 |
|
|
teensy3? 
|
|
#
¿
Nov 28, 2014 01:24
|
|
|
one with an amazingly lovely register layout that doesn't even seem to come with CMSIS headers, yes i'm the big-endian IP cores on a little-endian processor
|
|
#
¿
Nov 28, 2014 03:03
|
|
|
It's a pity that putting together an ARM toolchain is much much more painful than it strictly needs to be or I'd just advise hobbyists to put one together. Get a board from Olimex that has an MCU and connector set you like Get a JTAG pod supported by OpenOCD Compile the toolchain Write a makefile Write a link script Write a crt Unfortunately it requires a fair bit of research work so it's probably more trouble than it's worth. I might write some poo poo up about my experiences in this regard some other time, but I'd argue that if you're doing this for fun and don't care about the low-level poo poo then you're kind of missing the point.
|
|
#
¿
Dec 1, 2014 20:56
|
|
|
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
|
|
|
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
|
|
|
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
|
|
|
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
|
|
|
DuckConference posted:yeah if there comes a day when using C is embedded is mostly a thing of the past I will be very sad A lot of greybeards probably said the same thing about assembly language
|
|
#
¿
Dec 5, 2014 22:59
|
|
|
Bloody posted:"who gives a gently caress"
|
|
#
¿
Dec 8, 2014 03:02
|
|
|
longview posted:should i use something like freetros for my next project or just do what i always do and write ad hoc routines and a ten page exception handler? Write a linked-list library, then create a linked list of function pointers protected by nestable IRQ enable/disable commands. There's your operating system. Superloops are kinda lovely to work with ime for all but the most trivial firmware projects. If you have some nontrivial reliability requirements then buying an RTOS license might be worth your while though. If you're going to go completely ham with overlapping DMA then it might be worth pulling in a "real" embedded OS just so you can have a context-switching scheduler, continuation passing style in C is not very fun.
|
|
#
¿
Dec 12, 2014 19:31
|
|
|
some motherfucker suggested I get a Bitscope. I got a bitscope for the task I was trying to accomplish with it (analysis of a SPI bus running in the low MHz range and also some GPIO activity alongside it) it's really a square peg in a round hole. no idea what it's like for analog stuff though. also their software and API library are written in loving Pascal 
|
|
#
¿
Dec 19, 2014 22:14
|
|
|
Bloody posted:Back in school we built an arm7 system on a solderless breadboard with like memory buses and poo poo running all over the place and those effects were by far the least of our issues that's pretty cool i'd like to design something with like DDR2 RAM but apparently it's really hard to get right idk i mean i think you're supposed to start with easier poo poo like just a microcontroller with integrated flash and sram but unfortunately that's not very useful for what i have in mind, it needs to have a bunch of io but also a tcp/ip stack and being able to run high level poo poo like http and that basically means linux (no i am not going to use uip)
|
|
#
¿
Dec 26, 2014 07:16
|
|
|
i had a $10,000 Agilent MSO on my desk when I was a grad student and now I have some $300 computer-driven piece of poo poo that doesn't work. gently caress whoever recommended bitscopes to me and made me look like a god drat money wasting idiot.
|
|
#
¿
Dec 31, 2014 16:43
|
|
|
lol does it still break out GPIOs onto separate chips interfaced over I2C?
|
|
#
¿
Jan 6, 2015 18:06
|
|
|
yeah i really have no idea what on earth quark is for it's built on a super expensive process and is really op for the sorts of things you'd use a microcontroller for
|
|
#
¿
Jan 9, 2015 22:03
|
|
|
I'm doing firmware for a lil battery powered wireless sensor it has a 1.5F supercapacitor on it for some reason  makes power cycling more of a pain than it needs to be
|
|
#
¿
Feb 10, 2015 19:13
|
|
|
i mean as far as i can tell it's there to smooth out the shock of the radio switching on and transmitting because the power consumption blips up from 300 uA to 10 mA for a fraction of a second, they only overspecced the necessary capacitance for that by uuh like six orders of magnitude or so nbd did i mention the BOM cost is supposedly a major consideration on this board too and anyway, instead of smoothing out the current spike it probably causes a Tohoku-scale inrush when you first plug the batteries in so it doesn't really seem like a win to me. like i'm pretty sure this thing would arc if alkaline battery chemistry were capable of it hooking this thing up to a benchtop PSU current-limited to 100 mA it takes like three seconds for the current limiter to disengage, in the meantime the voltage rises up to 3V from a starting value of something like 1.4 (i am a software guy, not a hardware guy. i know like ohm's law and vaguely how capacitors are used and that's about it)
|
|
#
¿
Feb 10, 2015 19:32
|
|
|
The BOM cost is really important for this project so we're giving you the cheapest and shittiest microcontroller we can find with not nearly enough ROM when $1 Cortex-M0 chips with 64KB of program ROM are a thing that exists *plans to ship 10,000 units* At least it isn't a PIC
|
|
#
¿
Feb 10, 2015 19:39
|
|
|
yes 5v-tolerant gpio is a thing
|
|
#
¿
Mar 10, 2015 15:29
|
|
|
Bloody posted:
can we have a new one without the "it's political correctness gone mad, stu" person pls
|
|
#
¿
Mar 13, 2015 21:41
|
|
this thread
|
atomicthumbs posted:from reading this thread, i am no longer interested in FPGA design i am but it seems like a tough gig to break into also microcontrollers and socs being what they are these days it seems there aren't that many places where asics or fpgas are cost-effective
|
|
#
¿
Mar 17, 2015 20:14
|
|
|
imagine, if you will, that this is Sochi and we have two toilets in the same room. and there's a bunch of people in the room who communicate by flushing these two toilets in various prescribed patterns and watching the water levels. iiuc this is basically how i2c works
|
|
#
¿
Mar 25, 2015 17:23
|
|
|
yeah seriously what's up with that but i mean, they usually explain SPI too, and there's really not that much to explain there.
|
|
#
¿
Apr 2, 2015 23:32
|
|
|
spi is "anything with at least one shift register that connects to the outside world and maybe a select line", yes
|
|
#
¿
Apr 3, 2015 14:56
|
|
|
Bloody posted:pretend this is added to my list of bullshit spi interfaces: an interface which is change rising/capture falling when writing registers, and is capture rising/change falling when reading registers 
|
|
#
¿
Apr 3, 2015 20:33
|
|
|
Fanged Lawn Wormy posted:My only formal programming training was some VBASIC back in high school, of which I remember nothing. When I came to the company I'm at, they were using Basic Stamps for a lot of stuff, and so I learned a little PBASIC, but then as I worked with them I found them really slow and frustrating. I began to tinker with arduinos at home, Then we had a project come in that a stamp couldn't do, I proposed an arduino-based solution, and coded the whole thing. If you don't actually have to make a mass-produced product then throw Raspberry Pis at everything and save yourself the ballache of writing linker scripts and crts and clock tree initialization routines
|
|
#
¿
Apr 8, 2015 18:19
|
|
|
if you want to learn this poo poo on your own time (please do not inflict your learning process on your employer, for them you should do some simple poo poo that might not be super optimally cost effective but that will at least actually work i.e. use a Raspberry Pi for everything) then i guess try the following: First, actually learn C in a cozy environment like a desktop IDE. Do not learn C++. Go to olimex.com and buy a board with an STM32 on it that you like the look of. Do some research, find a JTAG pod that will work with OpenOCD that you can hook up to your STM32 board. Do some research, learn how to build a cross GCC and Binutils toolchain targetting ARM (see if you can manage to do this without pulling in the Newlib libc) Read the datasheet for the STM32, learn how its address space is laid out, write a linker script (from scratch, most examples have a ton of ancient copy&paste cruft that hasn't been relevant since the 90s). Write a CRT (C Runtime). A CRT is a small chunk of code that sets up the CPU to the point where it can run ordinary C code. Microsoft are loving obnoxious and call their C standard library the "CRT", that's not wha a CRT is. Anyway. The STM32 has a Cortex-M3 CPU core inside it. One of the nice things about this CPU is that you can even write a CRT in C: all you really have to do is clear memory and then copy the initial values of your variables into RAM from ROM. Most of this stuff is googling but then that's what you're going to be doing a lot of anyway.
|
|
#
¿
Apr 8, 2015 18:28
|
|
|
doing the crt/linker script thing is whimsical but it really pulls back the curtain in a decisive way. Define a symbol for the interrupt vector table and a fixed address for it, set up sections for rom and ram then use them to define __bss_start and __bss_end or whatever. write a C file that defines this vector table and fills it with various function pointers (again, a reason why Cortex-M's NVIC owns), write a __start() in C that loops between __bss_start and __bss_end and zeros the memory out then calls main(). Write a non-recursive makefile to drive the compilation and linking process (and then copy and tweak this Makefile for every subsequent project you'll ever write until the day you die) and emit an ELF, then finally do an objcopy to convert the non-metadata parts of this file into a binary ROM image. Open the binary ROM image in a hex editor and gaze upon your work. Every byte of it is yours. There are no more training wheels, no more arcane magic that was once beyond your ken. There is only your creation sitting upon the machine's cold steel throne. Then learn the joys of gdb remote debugging and double and triple-checking your clock setup and GPIO port configuration code when you run the poo poo and the GPIO doesn't start blinking like it was supposed to 
|
|
#
¿
Apr 8, 2015 21:29
|
|
|
yes hence why i said it's whimsical you could write an app in ARM assembly by hand too but that's probably taking it a bit far.
|
|
#
¿
Apr 8, 2015 21:47
|
|
|
Mido posted:
dude wtf r u doin
|
|
#
¿
May 10, 2015 18:47
|
|
looks like my name is on someone's short list for good emb-c devs
|
Mido posted:I'm p bad at gauging how much my time is worth you don't say. if those five functions are so easy to write that some other dude over there can knock em out with 30 minutes of googling then let them do just that if hey actually those functions require some experience to develop then they can pay you what your time is actually worth to do them otherwise you just look desperate and you're going to get walked over. remember that your contracting rate per hour, all else being equal, should be (at least) 2x your expected salary after conversion into an hourly rate because you have no job security or benefits while contracting.
|
|
#
¿
May 10, 2015 19:45
|
|
|
fwiw i too am awful at negotiating and knowing what my time is worth etc but i do know at least that $60/hr for freelance embedded dev work is so low as to not get you taken seriously.
|
|
#
¿
May 10, 2015 19:46
|
|
|
|
|
#
¿
May 10, 2015 19:59
|
|
|
Somewhat tangentially related but the RISC-V project published their supervisor ISA spec recently, to complement their already published user ISA spec. http://riscv.org/download.html#tab_isaspec Hopefully we'll see real silicon for this thing sometime this year because the architecture itself is very 
|
|
#
¿
May 22, 2015 18:27
|
|
|
hey jawn what is your opinion on this http://www.clifford.at/icestorm/ is this like the open-source synthesis equivalent of Hello World or is it closer to a Noveau-scale hardware reverse engineering accomplishment
|
|
#
¿
Jun 28, 2015 20:43
|
|
|
Fpga design sounds really fun but I have no background in it beyond doing some firmware work, how easy is it to break into?
|
|
#
¿
Jun 29, 2015 19:40
|
|
|
yeah i mean i get how it works on a conceptual level, i'm just wondering how easy it would be to get a job with no prior experience.
|
|
#
¿
Jun 30, 2015 15:57
|
|
|
the worst is everything produced by microchip
|
|
#
¿
Jul 22, 2015 13:37
|
|
|
|
| # ¿ Apr 29, 2024 11:01 |
|
|
movax posted:whoa buddy let's not say things that we can't take back I'm sure their analog poo poo is fine it's just like so they have an 802.15.4 radio right it has like a zillion registers for some reason. a small address space and a big address space for two different sets of registers. well there's one register in the big address space that's just like, "state machine state". a bunch of state codes and symbolic names are given. no meaning for any of these states is given. ok nbd. turns out though, it also has a hardware auto-ack. you kind of need to have one in order to turn around ack packets fast enough. turns out if you want to transmit you actually have to do the following actions in addition to all the steps they describe: 1. disable reception (actually you can't. the datasheet tells you to disable reception by enabling a bit that causes the digital frontend to decode 1s as 0s and vice versa, which basically is guaranteed to cause the deframe unit to reject everything) 2. watch the semi-undocumented state register and wait for it to go to the quiescent state before transmitting then re-enable reception obv if you try to transmit while the hardware mac is sending an auto-ack it just loving locks up forever. it's cool though, i mean it's not like anybody would ever try to transmit a packet in response to another packet or anything rofl and that's actually pretty mild as microchip wtfs go, i don't even have to program PICs thank god or i'd have probably managed to drink myself to death by now oh yeah, an honest to god erratum for that chip: "if you enable the encryption and authentication engine then sometimes the hardware HMAC will reject a valid packet. retransmit if that happens. sorry  "ok i made up the "sorry " part
|
|
#
¿
Jul 24, 2015 23:43
|
|