|
movax posted:This sounds like a cool little firm to work with, how do you do business development? Currently, we don't. Way overloaded with projects at this point. Mostly just client referrals or doing work for a client of a client so our primary client can sell them more stuff. And last night the audio started glitching again. I'm going to have to see how to suspend alsa instead of continually streaming silence out. E: since this is the embedded thread, my current fun project is heterogeneous computing. iMX7 is a pair of A9 cores and an M4. Shared memory, RTOS on the m4 side, linux on the main. Doing gyroscope acquisition as fast as it will go in the smaller core and feeding it into a filter before sending a smaller number of clean updates to the linux side. Harik fucked around with this message at 20:38 on Nov 10, 2017 |
#
?
Nov 10, 2017 20:24
|
|
|
|
| # ? May 5, 2024 21:01 |
|
|
Thanks for the recommendations. I've got a few options now I hadn't worked with before. AVR32 has such lovely docs, I already hate working with it if only for that reason. I work with PIC24s and like them pretty well. Decent docs. NCO is for low-power no-interrupt waveform synthesis. It would be nice to see 2 on a chip, but the PICs top out at 1.
|
|
#
?
Nov 11, 2017 09:29
|
|
|
What sort of waveforms? Pretty much every timer will let you generate a square wave, though you may not be able to get a precise frequency.
|
|
#
?
Nov 11, 2017 16:38
|
|
|
I once blue up a wall wart charger. I was using a DMM to test voltages at certain points to figure out where I could solder in a connection and accidentally shorted a lead. The thing blew up in my face with a huge bang that about gave me a heart attack as I shorted 120 V. The power went out at my work and everyone had a good laugh at my expense. Another good one. Place I worked at we were an Intel certified partner (or something like that) so we would get new chips in months before commercial release. Intel still technically owned these chips and could request to have them back at any time and we were usually limited in how many we had. Well I got a board with one of these chips but no heat sink. One of the hardware engineers gave me a heat sink and I figured it's simple enough to screw down. The setup was a little wonky and I ended up over compressing the CPU with the heat sink and destroying it. That was fairly embarrassing.
|
|
#
?
Nov 13, 2017 21:50
|
|
|
That reminds me of the old socket A athlon chips that had an exposed die and rocking the heatsink at all during install would chip the die and bye bye processor.
|
|
#
?
Nov 14, 2017 00:59
|
|
|
sharkytm posted:That reminds me of the old socket A athlon chips that had an exposed die and rocking the heatsink at all during install would chip the die and bye bye processor. My first PC build was a Thunderbird. I was so very cautious with that step.
|
|
#
?
Nov 14, 2017 05:44
|
|
|
Mr. Powers posted:What sort of waveforms? Pretty much every timer will let you generate a square wave, though you may not be able to get a precise frequency. Linear frequency control and accuracy are key for the application.
|
|
#
?
Nov 14, 2017 07:17
|
|
|
Has anyone implemented a ARM NEON fast reverse memcpy() before? I can find plenty of examples of vectorised memcpy(), but nothing that reversed the bytes from source to dest. Basically, I'm looking for the fastest replacement for std::reverse_copy() I can get on a Zynq platform, since the DMA doesn't support negative increments.
|
|
#
?
Nov 17, 2017 08:20
|
|
|
I wonder if LDMIA/STMDA combos would be fast enough. That would only give you double word swapping, though. E: looks like you could use VLDMIA !, VREV64.8 on each NEON register you're using, then VSTMDA ! You might be able to do something with the interleaved load/store, too. Like a VLD4.8, two VSWP, and then VST4.8 (it looks like you can't reorder the dest/src registers, so the VSWPs are required). I'm going to go with something like this: r0 = dst address r1 = src address r2 = size in bytes add r1, r2 add r1, -32 copy: vld4.8 {d0, d1, d2, d3} r1! vswp d0, d3 vswp d1, d2 vst4.8 {d0, d1, d2, d3} r0 add r0, -32 add r2, -32 it eq beq copy Can probably clean up to be better than that. Worth looking at the performance of VLDM/VSTM with more VREV instructions versus more loop iterations with VLD4.8/VST4.8 and the VSWPs. The VSTM will also do the subtract of r0 for you. E: might also be able to do something with the Q registers. carticket fucked around with this message at 07:50 on Nov 18, 2017 |
|
#
?
Nov 18, 2017 07:15
|
|
|
Mr. Powers posted:I wonder if LDMIA/STMDA combos would be fast enough. That would only give you double word swapping, though. Awesome, that is for this! I'll give it a go Tuesday when I'm back in front of the kit. I'm an embedded C/C++ guy mainly who only does ASM when I have to, and haven't done ARM assembly before (I stuck to 8-bit devices in the past and ASM wasn't warranted on the huge 32-bit projects I worked on the last few years).
|
|
#
?
Nov 19, 2017 01:31
|
|
|
EpicCodeMonkey posted:Has anyone implemented a ARM NEON fast reverse memcpy() before? I can find plenty of examples of vectorised memcpy(), but nothing that reversed the bytes from source to dest. I'm assuming you checked this before - but is there any reason you need to copy it in reverse instead of generating/parsing it in reverse? I do things like pre-rotate all my sprites, coordinates and drawing so that the 90° screen rotation stride-memcpy is baked into the storage format and I don't eat it on every refresh.
|
|
#
?
Nov 19, 2017 03:33
|
|
|
Harik posted:I'm assuming you checked this before - but is there any reason you need to copy it in reverse instead of generating/parsing it in reverse? Unfortunately, it's the display - it's mounted upside down and transposed, and the HW guys tell me it can't be changed (or SW reconfigured). I'm rendering into a frame buffer in a format the LCD can process directly.
|
|
#
?
Nov 19, 2017 05:25
|
|
|
EpicCodeMonkey posted:Unfortunately, it's the display - it's mounted upside down and transposed, and the HW guys tell me it can't be changed (or SW reconfigured). I'm rendering into a frame buffer in a format the LCD can process directly. That's exactly the issue I have, except mine is turned 90° so my memcpy stride would be 4 bytes every 320*4. I just render everything to the framebuffer pre-rotated so the actual refresh is a straight linear DMA. It's not that hard to render upside down, pre-rotated, pre-scaled, or pre-alpha blended, and it saves a lot of cycles when it comes time to hit the display.
|
|
#
?
Nov 19, 2017 13:27
|
|
|
I just get to use non-bad displays where I just flip two bits for a 180 degree rotation. Just a note about the reverse copy stuff I gave: it all has pretty strict alignment requirements, so that may be a problem.
|
|
#
?
Nov 19, 2017 15:03
|
|
|
Oh yes, we composite everything so that the final frame buffer is just streamed to the display as-is via a DMA. The problem lies in the compositing - it's a 1920x1080 screen we need to draw various widgets to at 60 frames per second, transposed and upside down to match the final frame buffer. The sheer number of changing graphics, text and meters means any improvements in copying speed of our bare metal core has a noticeable impact on FPS.
|
|
#
?
Nov 19, 2017 22:42
|
|
|
EpicCodeMonkey posted:Oh yes, we composite everything so that the final frame buffer is just streamed to the display as-is via a DMA. You have a Zynq. I would just render the frame right-side up and have the FPGA engineers implement a reverse-DMA controller for you.
|
|
#
?
Nov 20, 2017 00:14
|
|
|
Speaking of Xilinx DMA, I'm about to lose my mind dealing with this scatter gather DMA engine. The FPGA guy was explaining it in more detail and he linked me to a bunch of older DMA version documents that had more detail in the operation. But it appears for multi-channel SG DMA Xilinx just tacked on a bunch of modules to their existing DMA logic and it's kind of a Frankensteins monster to parse.
|
|
#
?
Nov 20, 2017 04:59
|
|
|
Ahhh yes of course, if you want the DMA engine to continue running after reaching the end of the buffer descriptor chain you just have to set the end chain descriptor register value to a non buffer descriptor address (so that the compare of current to end descriptor location never matches). Never mind that the DMA driver automatically figures out the last buffer descriptors address and sets this register for you. So you either have to modify the drive or know to manually change this value to be something bogus.
|
|
#
?
Nov 21, 2017 05:45
|
|
|
Just set up the first scatter target as the end chain descriptor and have the DMA engine reprogram itself 
|
|
#
?
Nov 21, 2017 17:35
|
|
|
JawnV6 posted:Just set up the first scatter target as the end chain descriptor and have the DMA engine reprogram itself  That's devious as heck
|
|
#
?
Nov 23, 2017 02:36
|
|
|
I would like ro get into embedded programming, but don't want to spend a lot on boards and miscellanea. Are there any environments which are virtualized well?
|
|
#
?
Dec 2, 2017 19:59
|
|
|
Kuule hain nussivan posted:I would like ro get into embedded programming, but don't want to spend a lot on boards and miscellanea. Are there any environments which are virtualized well? Well, what are you really trying to do? Keep in mind that embedded platforms tend to rely on the GPIO/SPI/I2C/PWM hardware that they interface with. You could virtualize much of an embedded platform, but without also virtualizing the hardware that the embedded platform interfaces with, you'll be a bit limited. Now, that being said, QEMU supports emulating a bunch of ARM platforms. You miss out on the adventures in getting the bootloader and such sorted out, but that's probably a big selling point to someone just starting out. Honestly, I'd suggest just shelling out the $90 for a Raspberry Pi or BeagleBone Black starter kit, or $100 for the fancy Arduino kit, with all of the odds and ends. You're going to get a ready-to-go Linux distro with toolchains and libraries you can just apt-get and install on the RasPi/BBB and a lot of hardware components for experimenting with the Arduino. I can understand having a limited budget, so emulating is QEMU is fine. But you're going to butt-up against the limitations of an emulated environment and you'll have to try and figure out what clever thing that you need to do to work around those limitations. You also miss out on plugging actual LEDs and such into your platform and interacting with them, which is most of the fun when working with an embedded platform.
|
|
#
?
Dec 2, 2017 20:39
|
|
|
Yeah, don't emulate. Buy a few Arduino clones and an STM32F1 dev board for like $3 off eBay. You don't need to put a lot of money into this stuff anymore.
|
|
#
?
Dec 2, 2017 23:06
|
|
|
Something like a teensy 3.2 is fairly high powered, has good software support (works like an Arduino but more powerful) and costs $20. Programming is over USB.
|
|
#
?
Dec 3, 2017 02:21
|
|
|
I second the Teensy 3.2. We used one recently to rapid prototype a device at work. You can start with the Arduino environment and graduate to a C/C++ environment. Or you can dive right into C/C++. For debug facilities you need to modify the board, but I believe the 3.6 has SWD (ARM debug connection) test points or pins.
|
|
#
?
Dec 4, 2017 06:54
|
|
|
Is there a better thread for FPGA questions? I have a spartan-6 board. I've downloaded ISE 14.7, done the stupid DLL swap to get it to run on Windows 10, now i have an example project I want to open that's from EDK. Can I open EDK projects? It failed on the first go but maybe there's additional steps to get it running on Win10. Could I just import the pcores into ISE? Failing that, is there a modern FPGA with a free toolchain, HDMI in & out, and an Ethernet port?
|
|
#
?
Dec 5, 2017 19:01
|
|
|
The ZCU102 board has all that but it is still probably $2000 and the HDMI IP is licensed. Also, BYO HDCP key.
|
|
#
?
Dec 7, 2017 13:41
|
|
|
Mr. Powers posted:The ZCU102 board has all that but it is still probably $2000 and the HDMI IP is licensed. My other project is making my FLIR camera wireless and connected, was hoping some of the network streaming bits would come in handy for that one too.
|
|
#
?
Dec 8, 2017 20:09
|
|
|
If the FLIR is one of the Leptons or a FLIR One that you can take apart and remove the Lepton from, it's an I2C/SPI interface to the actual camera core, and you could use just about anything to make it wireless.
|
|
#
?
Dec 8, 2017 20:20
|
|
|
It's a lepton I won at a hackathon, we had a RPi talking to it over SPI. The kit came with an impressive little mounting board with a LCD screen and did the color-correction stuff, along with the module mount with the pin breakouts. I'm trying for something much smaller, got some knockoff ESP8266's that I *think* I can wrangle a SPI bus out of. https://twitter.com/jawnv6/status/938450932395753472
|
|
#
?
Dec 8, 2017 20:50
|
|
|
Here is a link to the schematic to your board, looks like you can get SPI. https://nurdspace.nl/ESP8266#Schema Looks like the PUY-P25Q is a flash part connected via SPI. There is an open chip select GPIO0 pin 15.
|
|
#
?
Dec 8, 2017 21:38
|
|
|
Maybe wrong thread to ask, but I'm thinking of making my own watch, so would need something like stepper motor, a thing to program the logic (microcontroller?), and a battery. I might be too dumb for microcontroller assembly/C, so I guess the next step up is something that allows JS/PHP/Python to run stepper motors? AND runs off a small battery? And preferably flat & tiny, not gonna be making a watch that Woz wears to bed.
|
|
#
?
Mar 21, 2018 18:25
|
|
|
What are your design goals? Accuracy? Battery form factor? Lifetime? Size? If you scaled up and made a USB powered desk clock, I would have more confidence in your success. As it is, the problem I think you're describing is capital-H Hard. Also, pick up an Arduino of some sort and get started with that. It uses C++ish, and I believe in you. You can learn a thing. JS or anything other than c/c++ on embedded systems is still in novelty status, and will take more effort to learn the particulars than just doing it properly from the beginning. Micropython / circuitpython are up and coming in that scene, though.
|
|
#
?
Mar 21, 2018 19:12
|
|
|
ante posted:What are your design goals? Accuracy? Battery form factor? Lifetime? Size? Goal: Make my own wearable watch, preferably one that *doesn't* look like some 2-inch thick, babby's first kit watch. Accuracy: Doesn't have to be atomic-clock accuracy, all watches are imprecise, etc. Battery form factor: Dependent on other components, but preferably something that'll last a month or longer. Size: Apple watch-size I'll see if I can learn a thing and start with a desk clock 
|
|
#
?
Mar 22, 2018 00:46
|
|
|
For babby's first watch, more realistic goals would be losing maybe half a second per minute, ~2 hour runtime, and unless you're spinning your own PCB, pretty chunky. A desk clock is do-able, and will give you an idea of what you can expect for your next project
|
|
#
?
Mar 22, 2018 01:50
|
|
|
The cool part is that you can improve all those aspects of your project as you learn more.
|
|
#
?
Mar 22, 2018 02:27
|
|
|
Switzerland posted:Goal: Make my own wearable watch, preferably one that *doesn't* look like some 2-inch thick, babby's first kit watch. You mentioned a stepper motor which makes me think you are thinking about a mechanical watch, and that is capital-H capital-ARD all-bold HARD. Hit up Youtube for watchmaker videos to get an idea of what you'd be in for. It's far more practical to start digital for sure. quote:Battery form factor: Dependent on other components, but preferably something that'll last a month or longer. Depending on your component choices that might be reasonable, but for a battery the size of a wristwatch you just aren't looking at a zillion milliamp-hours. If you get to the point of choosing components we could help you figure out what power consumption would be in the worst case (tightening up power savings can get quite difficult) and that would give you a reasonable idea of what you'd be looking at. quote:I'll see if I can learn a thing and start with a desk clock Great! I'm sure everyone here would love to help!
|
|
#
?
Mar 22, 2018 03:11
|
|
|
ante posted:For babby's first watch, more realistic goals would be losing maybe half a second per minute, ~2 hour runtime, and unless you're spinning your own PCB, pretty chunky. A desk clock is do-able, and will give you an idea of what you can expect for your next project They make RTC chips for this purpose, so unless you're explicitly trying to only using a microchips internal clock just for difficulties sake then you would want to grab an RTC chip such as a MCP79410 or another I2C/SPI part (Maxim?). You'll also want a coin chip holster that will power your microchip/RTC and some sorta buck regulator. If you go the RTC route which will be far more accurate than an internal micro clock you'll still end up losing probably seconds per-day so don't expect this too be a very accurate watch without regular updating. Popete fucked around with this message at 07:30 on Mar 22, 2018 |
|
#
?
Mar 22, 2018 07:28
|
|
|
Anyone works with LoRa here? I'm looking for advice on what hardware to use for a small form sensor to be carried on a person and battery powered and a simple gateway concentrator module.
|
|
#
?
Mar 22, 2018 08:32
|
|
|
|
| # ? May 5, 2024 21:01 |
|
|
Thanks again for the advice. One question tho re: capital-H HARD - if it's hard, why has nobody come up with a small Arduino-ish thing that takes the hard out of "make your own mechanical-y watch"?
|
|
#
?
Mar 23, 2018 02:00
|
|