|
movax posted:Now, to go for broke, get your entire setup into Git and building as part of scons or some other build system without shooting yourself. I'm glad I dodged the bullet on that one. I have a whole Xilinx dev setup here and we ended up going down another route, thank god. My alsa problems sound (pun intended) like they're solved at this point. It wasn't really related to polling at all, it was all due to working with medium latency: 10ms from input to start of sound. No good for a musician but plenty for making a UI beep. The very first thing you do is feed a few periods worth of frames to the PCM out to try to load up the buffer. When I ran the demo code with 10ms periods it had the same problem I did at first - a half dozen underruns before it recovered and started working properly. Thing is, sending two buffers back to back, the second always errored out with an underrun. I mean literally back to back, two writei() calls in a row, not waiting on polling or checking for available space, since I have a 5 period buffer I knew there was enough space. The difference was if there's an error they start checking the state and mashing recovery before trying to send another frame, where I was doing recovery then blindly sending another frame. Apparently it takes two resets to take? Low-level sound is a mess. I nuked my entire event handler and re-wrote it with the exact structure from alsa_demo.c and now it's working properly. On the positive side, it ran for 12+ hours and no glitchy audio, so there's that.
|
#
?
Oct 24, 2017 22:09
|
|
|
|
| # ? May 10, 2024 12:22 |
|
|
What the gently caress is wrong with embedded vendors and their toolchains? I'm very grateful for the open source atmel toolchain on Linux (avrdude, avr-gcc, etc etc) because the Windows versions just suck (except for Atmel Studio, that's pretty sweet) Just seems like they could be doing a much better job, than having shite toolchains/ides stuck in the cretaceous era.
|
|
#
?
Oct 25, 2017 08:10
|
|
|
Odette posted:What the gently caress is wrong with embedded vendors and their toolchains? I'm very grateful for the open source atmel toolchain on Linux (avrdude, avr-gcc, etc etc) because the Windows versions just suck (except for Atmel Studio, that's pretty sweet) Windows toolchain is avr-gcc under the hood. You could probably use the win10 bash4windows stuff and run makefiles nowadays and do the code in eclipse-CDT or whatever you prefer. If you think embedded compilers are in the cretaceous era, try schematic/layout tools. They're completely incompatible with modern concepts like "change history", "shared work" or even "what the gently caress is different between these". We had to retool a board because there's no actual check that a net is really connected to anything, so because one was going to external 3v3 and the other page was exporting 3_3v it happily decided those didn't need to go anywhere. In compiler terms: you can link with missing objects and it just lets it go to production that way. Of course it crashes in the field... When you have 50 active components and their associated passives and power planes you don't want to try to design each one based on incomplete datasheets, you grab the vendors reference design and plop it down, then attach it to yours. The audio amplifier had a dumb name for it's VCC plane and it got missed. Now, it does scream if you have a cross-page connection and rename one end, but it just doesn't give a gently caress if global power planes really exist. How do you even manage to be that braindead? Some techbro should really "disrupt" Cadance/Allergo/et al. Then you try out FPGA/ASIC design and just blow your brains out, because that's even worse.
|
|
#
?
Oct 25, 2017 10:57
|
|
|
Harik posted:Windows toolchain is avr-gcc under the hood. You could probably use the win10 bash4windows stuff and run makefiles nowadays and do the code in eclipse-CDT or whatever you prefer. Embedded Programming Microthread: Just blow your brains out
|
|
#
?
Oct 25, 2017 12:54
|
|
|
movax posted:I was at Xilinx HQ a few months ago, and at least some of their senior guys admitted "yeah, we kind of hosed up" when it came to making Vivado and tools play nice with VCS. that's p lol, and also matches my experience exactly
|
|
#
?
Oct 26, 2017 03:46
|
|
|
Harik posted:Now, it does scream if you have a cross-page connection and rename one end, but it just doesn't give a gently caress if global power planes really exist. How do you even manage to be that braindead? I want to clarify this a bit.  This is the bit of schematic that's wrong. The problem is capture has no concept of exports and imports, so those VCC rails don't have to be connected to anything. +5V and +3.3V were called something different on the power controller because this codec design was pulled in from a different board with different names. Nothing indicates that +5V was a dead end, because it could be an export. There's all sorts of static analysis tools for programming to make sure this exact error doesn't happen, but for circuit boards you're supposed to manually check every part of sometimes incredibly complex schematics, which is just nuts. We do, but the focus is on the complete failure parts - DDR, EMMC, power delivery to the processor. If it comes up and a peripheral has a problem we can whitewire it and fix the schematic without blowing weeks redoing the board. If the DDR doesn't work we're dead in the water. I'm currently enjoying a perusal of the device tree to try to figure out what GPIO is misconfigured and causing instant wakeups. If only there were a wakeup reason recorded that wasn't clearly bogus. (CPU 0 performance counter is not a valid wakeup reason).
|
|
#
?
Oct 26, 2017 05:24
|
|
|
Harik posted:Windows toolchain is avr-gcc under the hood. You could probably use the win10 bash4windows stuff and run makefiles nowadays and do the code in eclipse-CDT or whatever you prefer. Oh god, that brought flashbacks from my time using AutoCAD/Altium/etc. Really have to agree with the FPGA stuff, the toolchains are even worse.
|
|
#
?
Oct 26, 2017 07:40
|
|
|
Harik posted:I want to clarify this a bit. We use Altium, and the way I protect against stuff like this strictly enforcing naming conventions, and having a Python linter that parses the netlist to look for things like this. That data directly feeds into a Python based simulator that among other things, executes a power and thermal model, that draws its data directly from the source — a schematic. Also, in layout, I think you’d notice instantly if a key power connection was missing / there’s a power “island” somewhere. Altium is the best (I.e. least lovely) schematic / layout tool available today, IMHO. Cadence is surviving on legacy / enterprise customers for PCB layout, but we built a shim to plug Altium into our ERP system. Still think IC layout and PCB / schematic areas of EDA are ripe for disruption, but it’ll be such an uphill battle. (Foundries don’t want to play with another tool for their PDKs == get hosed and still suffer with Virtuoso) I’m hyper OCD / anal about hardware development process for my engineers, but in four years, we’ve not had to respin a board in response to a design error. Trade-off is additional time spent in review / upfront dev for the tools, but builds are not cheap and take time.
|
|
#
?
Oct 27, 2017 03:34
|
|
|
I'm investigating the viability of installing an ESP32/8266 inside my home thermostat, to not only remotely read the temperature it's sensing but to also change the set point and fan settings. Our condo recently installed these Peco T170 thermostats in all the units. So far I've noticed the following things from opening them up and reading the documentation:
Also, I've never tinkered with anything that works on mains voltage but I know enough that it can hurt you bad so I've been hesitant to prod around with my multi-meter and watch how the various wires voltages change as the thermostat turns on/off, fan controls are changed via buttons. Anyone ever do something like this? Advice? Warnings?
|
|
#
?
Oct 27, 2017 20:56
|
|
|
Yeah: - Unless you know what you're doing, don't mess around with mains voltage because you will shock and kill yourself - Unless you know what you're doing, don't mess around with thermostats because you will burn your place down and kill your elderly neighbours Why don't you like go mess around with a router or something to get your feet wet
|
|
#
?
Oct 27, 2017 21:21
|
|
|
IAR's toolchain now supports C++14 and C11. Anyone tried it out yet? How good is the implementation? I'm kinda shocked they even attempted it.
|
|
#
?
Oct 28, 2017 20:23
|
|
|
I've used static_assert in C, but that was before they supported C11, just C99+extensions.
|
|
#
?
Oct 29, 2017 14:12
|
|
|
I have an Atari 800 connected to my PC via a COM port. The PC appears as a device on the serial bus to the Atari and I have a program that emulates a bunch of disk drives that I use for running things on it. I want to be able to also run a second program that appears as a separate device on the bus but I can't connect two programs to the same COM port in Windows. Any recommendations for programs (preferably free/cheap) that will forward traffic coming in on one COM port to one or more virtual COM ports? I was using a trial version of something called Serial Splitter but they want $100 for the full version.
|
|
#
?
Oct 30, 2017 00:30
|
|
|
Luigi Thirty posted:I have an Atari 800 connected to my PC via a COM port. The PC appears as a device on the serial bus to the Atari and I have a program that emulates a bunch of disk drives that I use for running things on it. I want to be able to also run a second program that appears as a separate device on the bus but I can't connect two programs to the same COM port in Windows. Any recommendations for programs (preferably free/cheap) that will forward traffic coming in on one COM port to one or more virtual COM ports? I was using a trial version of something called Serial Splitter but they want $100 for the full version. I have a feeling that this would be a lot easier to do from Linux, to be honest. Also this is the 'programming embedded things' thread - maybe SH/SC is a better bet?
|
|
#
?
Oct 31, 2017 17:14
|
|
|
The Cortex M4 has some nice integer SIMD instructions. You can multiply 2x16 bit ints together and add/sub the results in one cycle. But is there any instruction that does the SIMD multiply without combining the results? Seems like a strange omission.
|
|
#
?
Nov 2, 2017 22:13
|
|
|
It's intended for FIR filters, it's basically the next level of fused multiply-accumulate. Don't think they cared about many other use cases
|
|
#
?
Nov 3, 2017 02:06
|
|
|
Anyone think RISC-V or the other FOSS MCUs will eventually become a force to reckon with?
|
|
#
?
Nov 6, 2017 04:36
|
|
|
I really hope so, they seem interesting. Nvidia is using RISC-V for the controllers on some new GPUs. I hope that if more big companies continue to use and develop RISC-V, the chips will become commonplace and toolchain support will be excellent.
|
|
#
?
Nov 6, 2017 05:27
|
|
|
Odette posted:Anyone think RISC-V or the other FOSS MCUs will eventually become a force to reckon with? If MIPS couldn't crack it, I'm not sure what RISC-V really brings to the table. At some point you get enough of a network effect that 'why should I use something that's not an ARM in this' needs a fairly compelling answer.
|
|
#
?
Nov 6, 2017 18:11
|
|
|
Hi. This is a serious post. Does anyone here live in or want to move to New England and get a job doing embedded stuff? We're having a hard time finding qualified applicants. We're pretty much looking for everything from bare metal microcontroller experience to embedded Linux application development and possibly tying in with some Android. PM me if you are remotely interested and I can give you details about the positions and what we do.
|
|
#
?
Nov 8, 2017 15:52
|
|
|
Odette posted:Anyone think RISC-V or the other FOSS MCUs will eventually become a force to reckon with? I think so, for RISC-V. Aero and space are looking at RISC-V hard for RH processors, and I bet Chinese chip makers would love to stop paying ARM license fees at some point. If anything, maybe it’ll get more people centralized around it instead of split between MicroBlazes, Nios IIs, Tensilicas, etc...
|
|
#
?
Nov 8, 2017 21:43
|
|
|
movax posted:Chinese chip makers would love to stop paying ARM license fees at some point.  "There was one serious name getting floated around but everything attached just looks like an empty pitch?
|
|
#
?
Nov 8, 2017 22:39
|
|
|
movax posted:and I bet Chinese chip makers would love to stop paying ARM license fees at some point. I'm sure. Is the savings from that in cheaper chips actually enough to get them design wins given what they lose, though? What does RISC-V have over ARM as an ISA for RH stuff?
|
|
#
?
Nov 8, 2017 23:23
|
|
|
Never did get back to replying to this.movax posted:
Yeah. 3 man shop though. EE does all the hardware, I do the software, and the other guy manages the hosting/cloud VMs. We've done some pretty cool designs for such a small team, I'll do a writeup at some point. Pretty varied work, the guts of a change machine (the protocols to readers and dispensers are bad), crane safety equipment running on embedded micros connecting wireless 900mhz to an android-based display, slick little pill dispenser that can call your kids when you forget to take meds, AR-15 skins for feeding simunition training inputs into Unreal/VBS for virtual soldier training, dozens of little one-offs for NFC readers, RS485 <--> ethernet bridges, etc. Small team explains how things like this get missed - you focus resources on the board-killers like DDR, core voltages, etc. TBF it was an inductor to isolate the audio from the system noise, it just somewhat over-succeeded in it's design goal; zero audio noise.  It's why I love/hate embedded. Hardware sucks and I've released more magic smoke than I like to admit, but you get to work on some neat projects. 
|
|
#
?
Nov 9, 2017 03:36
|
|
|
I've always said to be an embedded developer you need to be a masochist.
|
|
#
?
Nov 9, 2017 03:45
|
|
|
Harik posted:
I had a great magic smoke moment a few weeks ago with a hand wired prototype. We had five built and we were testing them. One powered up but without the display functioning. So, I'm connecting up to troubleshoot, and then those of us in the lab start sniffing. "Do you smell burning plastic?" It turned out we had a connector (a really odd ball connector) wired up mirrored which caused power shorted to ground when we powered the display. It was easy to track down by pointing to the white-char on the board where one of the load switches should have been.
|
|
#
?
Nov 9, 2017 07:14
|
|
|
JawnV6 posted:This is the one argument that I sorta believe, and that wavers day to day. The folks I know who are super into RISC-V are all carrying axes to grind, and they do that bitcoin thing where criticism from nearby-field experts are brushed off as "so make ur own orthogonal extensions Nvidia is using it on GPUs as a watchdog micro Tbh it will likely compete more with xtensa and arc than arm unless apple decodes to stop paying for an arm license. Maybe it'll kill off some softcores on FPGA. The hifive1 mcu is neat but niche. Isa just doesn't matter that much when the code is high level. Also, Arm ip libraries are just more complete and developed. Malcolm XML fucked around with this message at 19:24 on Nov 9, 2017 |
|
#
?
Nov 9, 2017 19:22
|
|
|
I dug around, the info's out there. Back when ex-coworkers were trying to recruit me for the thing it was hush-hush, but I was thinking of Dave Ditzel. If anything's going to cause a paradigm-breaking shift in computing architecture, it'll have some tie to Transmeta. Those folks got so, so much right. Malcolm XML posted:Nvidia is using it on GPUs as a watchdog micro
|
|
#
?
Nov 9, 2017 19:50
|
|
|
I'm really attracted to PIC micros for the sheer number and variety of peripherals. I like the SOC approach for ADCs and DACs and comparators and the like because it makes breadboarding a breeze. Does anyone else do DIP SOCs? Curious as to what's out there. Specifically looking for stuff with NCOs.
|
|
#
?
Nov 9, 2017 21:04
|
|
|
Looks like some of the AVRs have them. That seems pretty specific. What do you need the NCO for? A lot of the functions can be done with a standard timer that pretty much any micro will have. Some of the features aren't duplicated in standard timers, though. My opinion of PICs is that if you're using a PIC18 or below, they are hell to work on and debug on. I hear the PIC24s, PIC32s, and dsPICs aren't so bad.
|
|
#
?
Nov 9, 2017 22:05
|
|
|
I like the 8-bit PICs but some of the new ones are starting to get so beefy it's making me wonder what the point is and if you shouldn't just switch to a 16- or 32-bit micro when your project needs 8 kilobytes of RAM, vectored priority interrupts, and DMA. I find debugging them to not be so much of a hassle but I shelled out for an ICD3 which may make a difference to my experience. There's an ICD4 out now but unlike the jump from ICD2 to ICD3 the differences don't seem very significant unless you also want to use it with former-Atmel parts. Which I don't, so my ICD3 still has some life in it. BattleMaster fucked around with this message at 22:18 on Nov 9, 2017 |
|
#
?
Nov 9, 2017 22:13
|
|
|
sliderule posted:I'm really attracted to PIC micros for the sheer number and variety of peripherals. I like the SOC approach for ADCs and DACs and comparators and the like because it makes breadboarding a breeze. Avr of course. (Which is also microchip these days) TI's msp430 line has quite a few dip packages. Nxp used to do an arm in a dip package, but it's obsolete and hard to get now. Lastly, there's a huge amount of surface mount to dip-esque conversation boards. There are simple boards that are just break out pins, and there are complex ones that have things like a USB socket and power regulation on board. The teensy and the stm32 "blue pill" are pretty good examples of the latter. Or the Arduino micro, mini, etc.
|
|
#
?
Nov 9, 2017 22:17
|
|
|
The Teensy is cool and good. I think the 3.6 actually has a debug header. We had to hack one in on the 3.2 we used (for size), but the non-debug prototypes were real easy to load up with the code.
|
|
#
?
Nov 9, 2017 22:28
|
|
|
Inspired by this thread, for my final project in my micro class, I named the team I'm on "Team 640k".
|
|
#
?
Nov 9, 2017 22:34
|
|
|
Woah. 640k is NOT a power of two. What were you thinking?!?!?
|
|
#
?
Nov 9, 2017 23:35
|
|
|
Mr. Powers posted:Woah. 640k is NOT a power of two. What were you thinking?!?!? I'm thinking it's enough memory for this project.
|
|
#
?
Nov 9, 2017 23:39
|
|
|
JawnV6 posted:I dug around, the info's out there. Back when ex-coworkers were trying to recruit me for the thing it was hush-hush, but I was thinking of Dave Ditzel. It's basically a ME equivalent. it runs a bunch of "security" code and handles some DRM stuff too. The designer gave a talk about it https://www.youtube.com/watch?v=gg1lISJfJI0
|
|
#
?
Nov 9, 2017 23:57
|
|
|
feedmegin posted:
It’s more that since it’s an open ISA, you don’t have to shell out for the tier of ARM license that gives you the access you need to do your own layout, add TMR to register files, implement scrubbers and EDAC in your SRAMs and peripheral memories. In layout you want to be using DICE or other non-commercial topologies vs your 6T SRAM cells to ensure some kind of SEE immunity. As process size shrinks, TID tolerance has generally gone way up, but SEE performance goes down (as in, more) because you need less charge to cause an upset. Then again, Cortex-A53 has been selected and is in development for the next American “high-performance” space processor (essentially similar to Zynq MPSoC) and is taping out in the next year or so from Boeing, IIRC. It’s also appealing because it may finally overtake SPARC V8 in Europe as the high-performance CPU of choice. NVIDIA turned it into the Falcon (or replaced the Falcon) as it’s GPU housekeeping MCU now. Smart move, IMO. movax fucked around with this message at 05:41 on Nov 10, 2017 |
|
#
?
Nov 10, 2017 05:38
|
|
|
Harik posted:Never did get back to replying to this. This sounds like a cool little firm to work with, how do you do business development?
|
|
#
?
Nov 10, 2017 05:44
|
|
|
|
| # ? May 10, 2024 12:22 |
|
|
The Zynq MPSoC (the Ultrascale+) is a great improvement over the Zynq 7000, but I've only used ES parts with early part support in Vivado/SDK. Boy howdee is that power number bad. The ZU3EG (ES rev) was sitting at ~2W as soon as power is applied, and went up from there as you start running code and loading up the logic. I think we're going to look at getting an UltraZed or Trenz, but looking at their specced power requirements is not heartening.
|
|
#
?
Nov 10, 2017 05:59
|
|