|
poll plane variant posted:Someone build an Arduino but running an old PC processor from the garbage heap imo Normal processors need a lot more support electronics then a microcontroller style processor. When I was in college there was an assembler programming course using what was basically an MC68 based board that some lab assistant had built. The only way to communicate with it was over a serial port. And it had the size of a normal pc mortherboard, and probably a similar power consumption. That was around 2 or 3 years before the first arduino released.
|
#
?
May 12, 2021 18:40
|
|
|
|
| # ? May 22, 2024 03:52 |
|
|
poll plane variant posted:Someone build an Arduino but running an old PC processor from the garbage heap imo That's pretty much what PC104 boards are
|
|
#
?
May 12, 2021 19:45
|
|
|
What kind of connector is this? They're just studs that are hollow in the middle, maybe 6-8mm wide. I assume I could just solder directly to them, but I feel like I've seen some sort of snap-on connector I could use instead...  It's on this fancy linear power supply, but the manual doesn't say anything at all about the connection type. Doesn't even say how wide they are or other poo poo I'd think you'd need to know if you were a manufacturer wanting to use this in a product... Shame Boy fucked around with this message at 19:53 on May 12, 2021 |
|
#
?
May 12, 2021 19:51
|
|
|
Lots of replies, sorry have been busy! Thanks for all the feedback, I'm just thinking right now so feel free to call me an idiot, there's no point doing it if it's not an improvement in some way.Shame Boy posted:I'm sticking with "use a mirror". Yeah I should look more into galvos, or at least use a pen and paper (or CAD program) to work through why I imagine it might be a lot harder to get everything to line up. As you say galvos are used in lots of places where accuracy is still important (like some SLA and all SLS 3D printers for example) and they seem to make it work... Sagebrush posted:I'm just kinda curious about the optics of it. You're saying that you want to avoid the wet-mounting of a drum scanner...but that wet-mounting is one of the major reasons that drum scanning is so good. Film is flexible and curls up and that ruins the perfect focus that you need for a good scan. Mounting it on a drum flattens the film out onto a very smooth, precisely made surface, eliminating a ton of potential optical artifacts. So to get the best results from your scanner you're still going to want to stick it down to a sheet of glass with mounting fluid, and then you're most of the way to a drum scanner. I don't think wet mounting is often the reason people want a drum scan although it is basically required as part of the process. You can wet mount on flat-bed scanners too but most people don't bother because the additional hassle despite the better results you can get with it. The most often cited benefit of a drum scanner is the very high dynamic range you can scan and low noise level in shadows as well as high resolution. These are all as a result of the motion system and high-quality sensor. Film perpendicularity and distance consistency to the sensor optics is definitely important but depending on the aperture of your lens it's not super important as long as you're in the ballpark. The V700 flatbed scanner film holders I use for my DSLR scanning for example just grab the film by the edges in a plastic frame but there's no support in the middle and they work perfectly fine. M_Gargantua posted:If you are flat mounting the film there’s no reason for anything to be rotating like that. Drum scanners work by spinning the film over the scan head so you cover all the surface, but if the film is flat there is no reason to spin the scan head instead. Just sweep it linearly across the XY like all the other modern CNC devices with our modern precision position encoders. As I mentioned before the reason to not do an x-y cartesian arrangement is that having to accelerate and decelerate the optics at the start and finish of every pass would massively add to overall scan times. The drum system elegantly eliminates this because you never have to decelerate either axis once you're in motion. When you get to the end of the film on one scan you automatically wrap back around to the start of the next line without slowing down. KnifeWrench posted:Yeah, I hate to join the pile on, but if you're rotating the sensor, wouldn't that mean you're still mounting the transparency to a cylinder, but just the interior surface? So you've turned a benefit (simplified sensor movement by spinning the transparency) into a cost (needing to design a data channel and power solution that can spin) by inverting the paradigm, but you haven't really made the mounting any easier? My goal is for there to be no 'cylinder' that you have to mount the film to, either on the inside or the outside. The plan would be for film to slide into curved guides which touch onto either edge of the film and curve it into the cylindrical shape, but the middle part of the film is not supported and in free space. Similar to how film loads onto spiral reels for development. The natural tendency for the film to want to resist the curve you're bending it into forces it outwards onto the back-side of the curved guides which should result in a fairly accurate and repeatable location and good flatness.
|
|
#
?
May 12, 2021 22:35
|
|
|
Shame Boy posted:What kind of connector is this? They're just studs that are hollow in the middle, maybe 6-8mm wide. I assume I could just solder directly to them, but I feel like I've seen some sort of snap-on connector I could use instead... Those look like hollow turret terminals. I've only ever used turrets as a big target to land clips on. I don't know if anybody makes connectors that are designed to mate with them. E: I should mention that the usual way to make a permanent connnection to a turret is to wrap your wire around it and solder it on. Stack Machine fucked around with this message at 23:48 on May 12, 2021 |
|
#
?
May 12, 2021 23:26
|
|
|
Dominoes posted:
switch to less common parts that no one designs in 
|
|
#
?
May 12, 2021 23:55
|
|
|
Ambrose Burnside posted:this is outside the Thread Mandate but if anybody has any reputable VOIP provider suggestions that a canadian can use, please kick em to me, apparently google voice requires a US cell/landline to register Voip.ms isn't google voice, at all, but they provide service to canada If that thing is wired like an arcade joystick (probably?), then black is ground and the other four wires correspond to the four directions. The disc thing on the joystick shaft that actuates the switches looks pretty trashed though
|
|
#
?
May 13, 2021 00:25
|
|
|
Possibly not the correct thread, but I'm going to ask anyway: Does anyone have a preferred software tool (in Win10) for sniffing out what's going from a running program to a USB to UART bridge? I've got one of those plug-and-play multi-sensor USB DAC devices (in my case, a photoplethysmography sensor module attached to a USB communication module, both from the NeuLog brand). Their ecosystem is designed to be compatible with a wifi module, so you have to run their API client, poll a local-host address corresponding to your desired commands, grab the JSON-ish output, and pull your info out of that. The actual communication between their sensor and the OS is done with a Silicon Labs CP210x USB to UART Bridge, as that pops up as a sub-installation during the API program install. I'd like to figure out what their API is sending to and receiving from the CP210x so I can just send that directly from my code instead of having to involve a closed-source, web-server man-in-the-middle. A rep from the manufacturer said they'd ask their software team for info on what's actually being sent out, but I haven't heard back in over a day so that may be a dry hole. Any advice or software tool recommendations would be appreciated.
|
|
#
?
May 13, 2021 02:53
|
|
|
At work I use Device Monitoring Studio to snoop on COM ports. It works really well but it’s not freeware. If you’ve got a logic analyzer that can handle the voltage levels and has a UART protocol dissector you could always hook up leads between the USB dongle and the serial device 
|
|
#
?
May 13, 2021 03:38
|
|
|
Yeah, pick up that $6 logic analyser off AliExpress / Amazon. If your OS is picking up the chip properly, then it is just spitting out UART in an extremely hackable format
|
|
#
?
May 13, 2021 04:22
|
|
|
VictualSquid posted:Normal processors need a lot more support electronics then a microcontroller style processor. People can (and I want to) build 68k based boards that are a lot smaller than that (though, yes, bigger than an Arduino) https://github.com/74hc595/68k-nano The giant rear end chip there is an oldschool 64 pin DIP package original 68000. It's maybe a bit over a couple of inches long. feedmegin fucked around with this message at 15:34 on May 13, 2021 |
|
#
?
May 13, 2021 15:32
|
|
|
csammis posted:At work I use Device Monitoring Studio to snoop on COM ports. It works really well but it’s not freeware. I really don't want to open this thing up to poke around inside it with a logic analyzer, and the program you linked costs more than the device did, but it looks like there are some freeware tools that do something similar so I'll investigate that this weekend. Apparently the software devs for this company are in Israel which, in light of recent events, would explain why the rep I talked to hasn't heard back from them, so I'll poke around in the COM port and see what I can find. Thanks. (And I definitely will be getting a logic analyzer at some point in light of how inexpensive they are since I last looked for one. Wild.)
|
|
#
?
May 13, 2021 18:47
|
|
|
Pick up literally any other device using the same chip, and convince your host driver that it's the same device, and then logic analyser Usb analysers themselves are insanely expensive and hard, especially considering you don't actually care about the USB aspect
|
|
#
?
May 13, 2021 19:01
|
|
|
poeticoddity posted:I really don't want to open this thing up to poke around inside it with a logic analyzer, and the program you linked costs more than the device did, but it looks like there are some freeware tools that do something similar so I'll investigate that this weekend. Dunno if it still works but I used Portmon (https://docs.microsoft.com/en-us/sysinternals/downloads/portmon) when I was developing an application using a serial port about 10 years ago
|
|
#
?
May 13, 2021 19:13
|
|
|
com0com is a software package that's primarily intended to make software-only serial ports and loop them back into the same computer, but it's got some things for doing stuff like forking a port into two outputs, one of which could be a virtual port looped back into your laptop. It isn't as good as a dedicated software monitor though, a good one will do stuff like see non-serial details about how programs are reading from ports (read sizes, configuration changes, etc...). If you just want to see the bits on the wire, you could also just cut up a serial cable, strip part of the insulation in the middle of the TX/RX lines and clip a scope to those (or solder on wires and run them back to a normal DE-9 into a laptop). It will mess stuff up electrically a bit to have a T shaped wire, but if cables are short & baud is slowish, it will still probably still work. People also make dedicated passive RS-232 taps that will do that with connectors and buffers ICs. Foxfire_ fucked around with this message at 20:50 on May 13, 2021 |
|
#
?
May 13, 2021 20:47
|
|
|
mewse posted:Voip.ms isn't google voice, at all, but they provide service to canada Actually it's in great shape. But the main reason I picked it up was I was hoping it used potentiometers. But hey, look at this new addition to my "shop" today, I'm so excited:  Looks like about a horse or two. Am I right in thinking it just needs a rheostat to give me a speed control?
|
|
#
?
May 14, 2021 02:38
|
|
|
What kind is it? Synchronous or induction? You can half-rear end speed control on an induction motor for some loads with a rheostat, but it's actually just reducing torque. A VFD to synthesize different frequencies is the better way to control an AC motor
|
|
#
?
May 14, 2021 03:28
|
|
|
Foxfire_ posted:What kind is it? Synchronous or induction? All I know is it's from Dayton Motors, it's heavy as hell and pretty loud. I was thinking of putting a drill chuck on it and using it with a few cutting and grinding bits now and then. I think you've answered my question pretty well though so thanks. I'm very excited about a number of projects and hope to build a couple of fun toys here and in the DIY musical instruments forum. I know I'm not operating on the level of most posters ITT but I really really appreciate any help and advice I can get here. petit choux fucked around with this message at 04:14 on May 14, 2021 |
|
#
?
May 14, 2021 04:07
|
|
|
What use cases do y'all recommend DMA for? My understanding is, anything that involves lots of IO benefits from it. It turns out that (with memory safety in mind), coding it is tough! Much tougher than normal peripheral access. Can't dodge this forever though.
|
|
#
?
May 14, 2021 17:56
|
|
|
The whole point is any kind of communication stuff. Have a whole bunch of UART data to send? Just write to RAM, point the DMA peripheral to it, and ignore it until it's done. Sounds complicated, but it's actually way easier and cleans up your code a lot.
|
|
#
?
May 14, 2021 18:02
|
|
|
And a/d sampling. Set up read, get 200 samples direct to memory, get an interrupt when done.
|
|
#
?
May 14, 2021 18:31
|
|
|
Another common case is CRC/hash peripherals. Can also be used for async memcpy in some cases. Pretty much always worth using. You can acheive much faster transfer rates than by polling and with much less CPU usage. Usually you can put the core to sleep while the DMA continues to run for fairly large power savings too. I wouldn't even spit on a microcontroller without DMA
|
|
#
?
May 14, 2021 18:43
|
|
|
If I am remembering past stuff about your software design right, most places where you are using interrupts or multiple tasks, I will use DMA instead if I have channels available. I think it is much easier to design and test programs where the code path is entirely deterministic and has no parallelism, unless there is little choice. Until things have to become more complicated, I favor designs of "Single thread, no interrupts, one loop runs exactly every N ms" and then use DMA so that each loop can produce/consume more than one thing per IO peripheral per loop.
|
|
#
?
May 14, 2021 18:45
|
|
|
Thank you. I'd like to be able to use these in future projects; sounds like a better (and at worst no worse than non-DMA) way to do things with comm protocols, ADCs+DACs etc. I'm currently trying to code it into my HAL. Doing the reg writes by following RM recipes doesn't seem too bad, but there are subtle memory safety issues that are non-trivial to get right, at least when exposing a general API. I'm not too good with memory management; I just know there's a magical boundary that gets crossed between the land of abstract code logic, and making hardware do things. My Charon has been peripheral access crates, which wrap code that does ptr::write_volatile(), performing this eldritch transformation. Foxfire_ posted:If I am remembering past stuff about your software design right, most places where you are using interrupts or multiple tasks, I will use DMA instead if I have channels available. Dominoes fucked around with this message at 18:57 on May 14, 2021 |
|
#
?
May 14, 2021 18:54
|
|
|
Yep, the DMA controller can also do things like move data from the SPI Flash to whatever peripheral needs it without the CPU being involved in any way other than putting in the order. It's probably MUCH more difficult for Rust to make its guarantees when you're using the DMA controller though, since it causes a bunch of stuff to happen out of band to the program context, which I'm guessing is the issue you're running into. Edit: Rust can call C binaries can't it? Honestly, I'd probably do stuff like the DMA in an "unsafe" library and call it from your main program. Keep program logic out of the DMA library where Rust can't guarantee things and you should be good Forseti fucked around with this message at 18:57 on May 14, 2021 |
|
#
?
May 14, 2021 18:54
|
|
|
Awesome. Rust has good C FFI. I haven't used it yet. Could do that, or make liberal use of unsafe in Rust. Concepts like "Is this safe?" and "did I use the `unsafe` keyword?" aren't as clear-cut here as in other areas. If I understand correctly, wrapping C code would be more like moving complications into a set of stacked plastic Target tubs in the corner of the guest bed room closet than removing them. There appears to be a continuum of approaches here, with varying degree of safety and abstraction. The Rustomnicon link I posted above goes into detail, but I don't understand much of it. Re battery life: Still having some mystery struggles there, so it's good to know DMA might help by allowing shorter wake periods. Already (temporarily?) pivoted one progject to plugin for initial run. Dominoes fucked around with this message at 19:46 on May 14, 2021 |
|
#
?
May 14, 2021 19:37
|
|
|
I'm not super experienced in Rust and unaware of the ins and outs of their design philosophy, but in general I would consider features like unsafe sections in otherwise safe languages to be primarily for interfacing with unsafe external libraries, for example system calls on a desktop OS. You probably could write everything in Rust, but if it's something that's inherently unsafe it's probably easier to write it in an unsafe language and call it from your Rust program. As a side benefit, this makes clear the separation of concerns in your head, even if only subconsciously. For what it's worth, C code isn't inherently dangerous, it's just that with Rust you've offloaded a lot of the burden to the compiler double checking you rather than relying entirely on the developer to know what is and isn't safe. So if it's something that is easy to express in that way, you might as well use Rust and take that help. It's a good way to reduce the amount of work the developer has to do most of the time, but some things are just don't fit that paradigm well.
|
|
#
?
May 14, 2021 19:53
|
|
|
Dominoes posted:Thank you. I'd like to be able to use these in future projects; sounds like a better (and at worst no worse than non-DMA) way to do things with comm protocols, ADCs+DACs etc. I'm currently trying to code it into my HAL. Doing the reg writes by following RM recipes doesn't seem too bad, but there are subtle memory safety issues that are non-trivial to get right, at least when exposing a general API. The underlying DMA hardware usually is more-or-less a pretty simple thing with: - Source address + should I increment it after each transfer - Destination address + should I increment it after each transfer - Number of things to transfer for each event - Is it running right now + how many transfers are left - Event that triggers it Then depending on environment, there are some extra concerns stacked on top of that: - If chip has caches, CPU will need to be told when to bypass them - If chip can reorder instructions, CPU will need to be told when not to - If compiler can reorder instructions, tell it when not to - If compiler can cache access, tell it when not to Dominoes posted:Yep! My programs are all interrupt-based, with near-empty main loops. Foxfire_ fucked around with this message at 20:27 on May 14, 2021 |
|
#
?
May 14, 2021 20:23
|
|
|
I like that mindset and approach, and will work through this with that in mind. I think making too-general-of-an-API is a trap. This is complicated by my coding this through a public HAL, but I can offload things to examples as required. My top priority is making workable, practical solution. I'm happy relegating generality and safety guarantees to second-tier. As you pointed out, this isn't tough on the hardware level - I've already written that code for the STM32 DMA controller (And its Mux on applicable STM32 families), and the UART peripheral. Planning to implement for SPI, I2C, ADC and DAC this weekend. Btw, I'm seeing echos of the Typestate Programming debate. Embedded Rust devs have a boner for something called TypeStates, whereby you make each GPIO and things that use them strictly typed in a way that's a PITA for the auto-generated docs, driver/HAL code, and user code. And buys you the advantage of the compiler throwing an error when you try to set an input pin high. Or do anything outside the most general use pattern with your pins. What a time to be alive. Foxfire_ posted:These are easier to get mostly working, and can be better for battery life sometimes, but they're also harder to reason about and much more vulnerable to problems like "It did a weird thing once in the last 10000 runs, we don't know why, and we can't make it happen again" Dominoes fucked around with this message at 20:40 on May 14, 2021 |
|
#
?
May 14, 2021 20:34
|
|
|
Oh yeah, I forgot to say that you very likely don't even need to write the external unsafe code for interfacing with the DMA controller yourself, the manufacturer has probably provided a C library for you. So the compiler will no longer be able to check it, but you can probably rely on the manufacturer and community to have your back in its place. I would guess the interface would be something like: code:
|
|
#
?
May 14, 2021 20:38
|
|
|
Forseti posted:Oh yeah, I forgot to say that you very likely don't even need to write the external unsafe code for interfacing with the DMA controller yourself, the manufacturer has probably provided a C library for you.
|
|
#
?
May 14, 2021 20:41
|
|
|
Does anybody know of any kits or detailed instructions for Altoid can sized microphone preamps? I am putting together some electret lavalier mics (which are very simple and cheap for the quality) for my brother, and I want to put together some preamps just for funsies. I can find tons of instructables for headphone amps, but barely anything form microphones. Input and outputs would be 3.5mm.
|
|
#
?
May 17, 2021 05:12
|
|
|
Marsupial Ape posted:Does anybody know of any kits or detailed instructions for Altoid can sized microphone preamps? I am putting together some electret lavalier mics (which are very simple and cheap for the quality) for my brother, and I want to put together some preamps just for funsies. I can find tons of instructables for headphone amps, but barely anything form microphones. Input and outputs would be 3.5mm. The CMOY is a perfect little mic pre for just such a purpose. Making a preamp into a "headphone amp" was just "marketing," please excuse the quote marks. It's a perfect little pre.
|
|
#
?
May 17, 2021 10:46
|
|
|
They’re mostly just all-in-one IC amplifiers these days. Things have been miniaturized and combined and mass produced. Hell they probably make a SOT-23-6 or even smaller one that would be overkill now. You’re thinking too big. The altoid can is a three day battery pack attached to a rice grain
|
|
#
?
May 17, 2021 10:49
|
|
|
M_Gargantua posted:They’re mostly just all-in-one IC amplifiers these days. Things have been miniaturized and combined and mass produced. Hell they probably make a SOT-23-6 or even smaller one that would be overkill now. .. touches hand to ear in classic newscaster stance, "I've just been told a 3-day battery is overkill, you don't want to end up at the end of whatever it is you're recording and have surplus electricity left over."
|
|
#
?
May 17, 2021 10:59
|
|
|
Just did some checking and they have <$2 ones with AGC and all now. But if you want AGC you need a “large” DFN package for example. Technically I’m sure a microphone amp could consume 2W? A 1S altoid can sized lithium would be like 6000mAh so a rather excessive 8 hours of continuous use at peak power.
|
|
#
?
May 17, 2021 13:58
|
|
|
M_Gargantua posted:Just did some checking and they have <$2 ones with AGC and all now. But if you want AGC you need a “large” DFN package for example. If you did some checking, can you share what you found with us?
|
|
#
?
May 17, 2021 14:15
|
|
|
The MAX9814ETD was the first result of my search and that’s good enough for what I was looking for
|
|
#
?
May 17, 2021 14:39
|
|
|
To answer your question more specifically, here's one: https://www.headphonesty.com/2017/03/cmoy-amp-kit-headphone-amplifier-kit/ And you may be able to find them as readymade kits or preassembled. I was recording meetings and hearings for years and kept a CMOY altoid tin amp as a backup. Nice clean sound. Stereo. And here is this but I think it's way too costly. When the CMOY was really popular you could get them a whole lot cheaper. Probably still can. Granted, this one is rechargeable, which is a plus if it can hold enough charge. https://jdslabs.com/product/cmoybb-diy-kit-rechargeable/ petit choux fucked around with this message at 15:33 on May 17, 2021 |
|
#
?
May 17, 2021 15:26
|
|
|
|
| # ? May 22, 2024 03:52 |
|
|
Sure you could make a far inferior opamp & protoboard version, but why? Things being through-hole protoboard doesn’t really make it any easier of a DIY project like it would be 20 years ago
|
|
#
?
May 17, 2021 15:34
|
|