|
That's how I've solved that problem, yes. You've got your cable spool, pull a couple feet off, wrap a couple times around your encoder-spool for friction, and then take off running down the warehouse.
|
#
?
May 29, 2020 06:07
|
|
|
|
| # ? May 9, 2024 20:02 |
|
|
Yep, that's how I would do it as long as you can ensure there is no slippage/tolerate some amount of inaccuracy. Rubber wheels on both the encoder and an idler, with the cord running through the middle, seems like it would be more accurate than just a pulley. e: or wrap a couple of times around the spindle, sure, again if the slippage/tolerance line up for you
|
|
#
?
May 29, 2020 06:10
|
|
|
You could do all kinds of crazy stuff, but I imagine your idea to just have it rotate a pulley you know the dimensions of is easiest. Or do it the way old sailors did. Mark the rope every few whatever measurements you want and use a color/light sensor to count the markings.
|
|
#
?
May 29, 2020 06:14
|
|
|
mobby_6kl posted:I'm also a bit confused about the power though. The red block with C4/C5 is based on Espressif's recommendation but wouldn't the capacitance be just the sum of them, so almost imperceptible addition to C4, and wouldn't I get the same result by just increasing C2? There are a couple of things going on. - Every IC should have a decoupling cap located right next to it. When the transistors inside it switch, there is a momentary spike of current. The decoupling cap will supply the energy for that rapid spike and then be refilled over a slower timescale. Or from an alternate point of view, the high frequency current passes through the capacitor forming a small loop instead of being have to take a big path back through the far away supply. - Real capacitors have parasitic resistance and inductance as well as capacitance. Impedance drops with increasing frequency up to a point, then rises again as the inductive part dominates. Larger capacitance values have the minimum impedance at a lower frequency, so they will not react to high frequency current demands as well as smaller ones. This is why you will often see banks of capacitors in parallel with values like 0.1uF, 1uF, 10uF, 100uF. The smaller ones provide smoothing for higher frequencies and the larger ones are slower but have more energy capacity. The doubled 10uF is probably for BOM simplicity, but replacing it with a single 20uF one would also change its frequency response. mobby_6kl posted:They're also suggesting the green block for pulling "Chip enable" up, but the R1 and C3 values were TBD. I guess a 100k for R1, but I don't see if/why C3 is necessary anyway if I just need to pull up the pin to run it. C3 and R1 make a RC circuit. When the power supply starts switching on, the IC won't be enabled until the capacitor charges up. This will keep the chip in reset while the power supply rises and stabilizes. Appropriate values would depend on how quickly the power supply comes up. edit: There are MCU ground pins on your schematic that are marked NC. Sure those aren't required to be connected? edit2: If the thing is going to be something you handle in daily life and plug/unplug stuff into regularly, stick some ESD protection on the connectors or it'll probably get zaped eventually. Foxfire_ fucked around with this message at 06:26 on May 29, 2020 |
|
#
?
May 29, 2020 06:20
|
|
|
Cojawfee posted:You could do all kinds of crazy stuff, but I imagine your idea to just have it rotate a pulley you know the dimensions of is easiest. Or do it the way old sailors did. Mark the rope every few whatever measurements you want and use a color/light sensor to count the markings. I'm using kevlar kite string right now which doesn't take markings at all, sadly. Anchor chain still takes paint pretty well even today.
|
|
#
?
May 29, 2020 06:27
|
|
|
That Works posted:I'm no expert, but the wiring to the motor controller etc and to the Pi all seems good, I don't think it's a loose connection. It's all premade jumper wires that work fine or alligator clipped wires. I would absolutely run a line from +5V to your 5V rail on the Pi. I suspect you're not getting reliable toggle on the optoisolators and something's going into saturation. The 5V line powers the control logic on the board. With that line, anything above 2.5V should be "ON" and anything below 1V should be "OFF". Without, then who knows what's going on?
|
|
#
?
May 29, 2020 11:48
|
|
Forseti posted:Oh, I thought it was in the next one over at a glance, oops. It's probably good enough for testing, and if it were an intermittent connection I wouldn't expect it to have such a repeatable failure mode. It sounds like something is capacitively coupled. Is that board providing +5V power or meant to be connected to a +5V source? I'm guessing provides from the voltage regulator I see there. Test it with a multimeter if you have one but if it's giving you regulated +5V I'd power the Pi Zero from that instead of the USB and give it a try. For now I am using the Canakit provided USB power supply, the plan eventually was to power the Pi with a 12v to USB buck converter that I had gotten working previously ITT. I am under the assumption that the provided power source was pretty decent. Might try another one and see. Or, like you say the board has a 5V out. I just need to figure out how to wire that to the Pi today and give that a go as well. insta posted:Check the crimp on your alligator clip leads. I had a cheap set that didn't have any exposed copper and just relied on the puncture through the insulation. I could easily see that causing problems with non-zero amperage. Thanks I will check that out when I get back into the shop today, much appreciated. It's frustrating when your errors / failure modes are "kind of works" instead of "does not work at all". E: babyeatingpsychopath posted:I would absolutely run a line from +5V to your 5V rail on the Pi. I suspect you're not getting reliable toggle on the optoisolators and something's going into saturation. The 5V line powers the control logic on the board. With that line, anything above 2.5V should be "ON" and anything below 1V should be "OFF". Without, then who knows what's going on? Sounds like a plan!
|
|
|
#
?
May 29, 2020 11:53
|
|
|
Ok I worked through a couple of suggestions and made some Voltage measurements as well. tl:dr, my GPIO pin7 output off the Pi was loving everything up. Could be bad solder, could be bad Pi, dunno yet but everything works now if I just move to a different pin. 1. Check alligator clips. I pulled the rubber booting back and saw clearly where each wire was soldered to the clip on each end, tested each with continuity tester, tried a new pair of wires and they also passed inspection, used the new pair for the remainder of the below work.  2. Wire the Pi off the 5V rail. Done. Using 5V power to the #2 GPIO pin on the pi, and the ground from the center rail of the blue block above to #6 GPIO pin. Pi booted up fine. Ran the script, motor ran for 3 seconds and then stopped. Waited the full 40s then immediately ran script again. Motor did not start at all. 3. Measured voltage at: Battery = 12.4v 12V to ground on the board = 12.3v 5V out and ground = 5.02v Across motor A leads = 0.02v when motor not running. Across motor A leads = 10.01v when motor IS running. From there I disconnected the motor and ran the script again. Across the motor A leads I measured 12V when the script started but within seconds this went to 0.00 / 0.02v Next I tried to put the Pi back on its original source and removed the 12V jumper pin, nothing worked when I did that, no voltage to the motor leads etc. 4. Took the motor off, just started measuring voltage at motor A leads, found that I would now get 12v on the leads when the script started but within seconds this would go back to zero. So, at least it's not the motor. 5. Moved wiring to different pins, tested motor B leads. Found same as above. 6. Decided to test 3.3v coming off of each GPIO pin while the script ran. I had used GPIO7 to the "Enable" pin on the board and either pin 11 or 15 for the open or close scripts respectively. Lo and behold, when I ran the scripts I found that I would get 3.3v for the full length of time on pins 11 and 15, but not on pin 7. I changed the scripts to replace pin 7 with pin 16, tested 3.3v on pin 16 and it held 3.3v for the full 40s. From there I reconnected everything and bam, both scripts ran the motor for the full duration! So, either my pin7 is faulty or when I soldered the headers on I hosed that one up somehow. I'll take it out of the case later and have a look with a magnifying glass. In better news, this means I don't need to even worry about using the Buck converter and with this step now working, I think everything is done. I need to connect my temperature sensor again and make sure that still runs while the Pi is also hooked up to the motor controller and make sure that running the scripts there don't somehow interfere with the sensor output or connections. I think for all that I can move over to the Pi thread if I have trouble.
|
|
|
#
?
May 29, 2020 13:35
|
|
|
This sounds vaguely like something else might be fighting for control of that gpio pin. Sometimes (especially with poorly written library code) two conflicting programs try to use the same pin and wierdness like this can happen. Just a common troubleshooting steps to think about when you see issues like this.
|
|
#
?
May 29, 2020 15:18
|
|
|
Glad you got it working! FWIW the Pi power supply I have is also a CanaKit and it's the one that makes my Pi work great. Pretty much anything actually intended for the Pi should be fine I think, it just gets picky about using chargers and random cables as a power supply. Not sure if the Zero is anywhere near as fussy though, I mostly run into low voltage warnings on my 3B+. Agree with the assessment that maybe something else is fighting for control of that IO as well like maybe a status LED or something, who knows. Maybe the setup of the pin also (source, sink, pull-up/down), I didn't look at the code at that link you sent.
|
|
#
?
May 29, 2020 15:28
|
|
Ah I wasn't using any of their code. I was just running the below code:Good to know that other things might fight for that pin though. Will keep in mind if I have to troubleshoot further once I get the temp sensor running alongside the motor control.
|
|
|
#
?
May 29, 2020 15:43
|
|
|
Forseti posted:
 Foxfire_ posted:There are a couple of things going on. quote:C3 and R1 make a RC circuit. When the power supply starts switching on, the IC won't be enabled until the capacitor charges up. This will keep the chip in reset while the power supply rises and stabilizes. Appropriate values would depend on how quickly the power supply comes up. quote:edit: There are MCU ground pins on your schematic that are marked NC. Sure those aren't required to be connected?  they are of course connected on the reference design, I'll try to ground them too.
|
|
#
?
May 29, 2020 15:53
|
|
|
The two capacitors in parallel thing for different parasitic properties is also a myth. The same packages will generally have very similar characteristics, so you wouldn't really see any benefit. One 0603 and one 0805 would provide that benefit, however. But it doesn't matter, that's usually not necessary anyway, you'll be fine. Just follow the reference schematic. I am totally "but actually"ing you, ignore me.
|
|
#
?
May 29, 2020 16:22
|
|
|
ante posted:The two capacitors in parallel thing for different parasitic properties is also a myth. The same packages will generally have very similar characteristics, so you wouldn't really see any benefit. One 0603 and one 0805 would provide that benefit, however. I am by no means a capacitor expert, but I thought the parasitic reactances of a surface mount capacitor weren't just from the electrodes on the capacitor package, but were also heavily dependent on the internal electrode structure inside of the capacitor. Like one time I was looking for I think something like a 200 pF surface mount capacitor with a the highest advertised self-resonant frequency, and the best part I found was not a small capacitor, but was an 0805. From that I assumed that the reason why the larger capacitor had a higher advertised self-resonant frequency was because the internal capacitor electrode structure inside of the larger capacitor package was simpler. Am I wrong?
|
|
#
?
May 29, 2020 16:44
|
|
|
ante posted:The two capacitors in parallel thing for different parasitic properties is also a myth. The same packages will generally have very similar characteristics, so you wouldn't really see any benefit. If I make 1uF by jamming 2 500nF caps in parallel and both have the same ESL as the 1uF cap, I now have half the ESL and the frequency range over which the thing looks like a cap is twice as wide. The reality isn't quite this good, but even for the same package larger cap values typically have lower self resonant frequencies.
|
|
#
?
May 29, 2020 16:49
|
|
|
got a question about ballast requirements for UV-C mercury vapour bulbs: I was thinking of building myself a Daily Carry UV Sterilizer, basically a breadbox-sized lockout-equipped enclosure fitted with a few UV-C bulbs, lined with mirrors and using a turntable or drum- combined with a microcontroller-based “cleaning cycle”- to expose as much of the box contents to microbe-destroying doses of UV light as is possible. the idea is to create a low-effort borderline-passive cleaning process for all your everyday items, your phone and wallet and keys and so on, that i will actually make use of every day without having to significantly change my routines or inconvenience myself. it won’t be perfect or achieve Actual Sterility, but it should still greatly reduce the risk of transmission of COVID via the most likely probable vectors that get used both in public and in the home without having to deplete my precious Lysol wipe strategic reserves. The appropriate UV bulbs come in old-fashioned mercury vapour and LED variants. The LEDs are great in every regard except in costing over $100 USD apiece. The vapour lamps are surprisingly cheap and easy to source, so im planning on using those, but they need a ballast, which itself is p pricey from the Water Sterilizing Guys. I can’t find much information at all about what exactly you need from a mercury lamp ballast- are they distinct from common LED ballasts? Is it practical to build your own or salvage it from some particular type of appliance or good? How do you know a ballast is sufficient for your needs without having to buy bulb and ballast together as a matched set? Have UV-C leds gotten less impractical since the last time i researched em?
|
|
#
?
May 30, 2020 17:28
|
|
|
silence_kit posted:I am by no means a capacitor expert, but I thought the parasitic reactances of a surface mount capacitor weren't just from the electrodes on the capacitor package, but were also heavily dependent on the internal electrode structure inside of the capacitor. I don't know what you mean by "simpler" Larger package, wider conductors, lower inductance, therefore device gooder. Stack Machine posted:If I make 1uF by jamming 2 500nF caps in parallel and both have the same ESL as the 1uF cap, I now have half the ESL and the frequency range over which the thing looks like a cap is twice as wide. The reality isn't quite this good, but even for the same package larger cap values typically have lower self resonant frequencies. I mean, sure, you're reducing the impedance at the self resonant frequency by half, but I'm talking about the myth of "use a 100nF and a 1uF in parallel to decouple everything". You'd be better off using two of the higher value (assuming you're using the same packages) 
|
|
#
?
May 30, 2020 18:04
|
|
|
Lee Richey calls that the "Deep-V" approach, putting a huge amount of 0.1-1µF caps on your supply rail does work reasonably well in my experience, especially for low-mid end MCU based designs. IIRC it's inefficient in terms of board space, so you if you're designing for a mid 2000s ASIC from before on-chip bypassing was a thing you might find there isn't enough room for all the big caps to meet the PDN impedance requirement and you have to start messing around with tons of values + plane capacitance. These days most high end chips have some on chip bypassing and the requirements are relaxed to where you can meet them without a ton of different values. For the Zynq-7000 series the requirements were pretty relaxed IIRC, and you can get away with a pretty basic assortment of 0.1-4.7µF 0603 caps for most rails (listed in the design guide).
|
|
#
?
May 30, 2020 19:19
|
|
|
ante posted:I don't know what you mean by "simpler" I mean that the internal shape of the capacitor being more like a simple parallel plate capacitor, instead of a complicated inter-digitated arrangement of electrodes to be able to cram the most capacitance into a small volume. The simple parallel plate capacitors tend to have the highest self-resonant frequencies, I think. I suspect that this is a more important effect than the shape of the electrodes on the outside of the surface mount package. I don't really know though, I have never really studied it carefully. ante posted:I mean, sure, you're reducing the impedance at the self resonant frequency by half, but I'm talking about the myth of "use a 100nF and a 1uF in parallel to decouple everything". You'd be better off using two of the higher value (assuming you're using the same packages) I don't think this is always true. I agree that there is a lot of hokum in how people design bypassing networks. In some kinds of chips, like RF amplifiers, sometimes power supply connections really need to be very good AC ground current returns for the proper functioning of the circuit. I think it is best to copy the datasheet application circuit here, and often in this application, multiple capacitor values are called for--sometimes when you do not copy the application circuit, you can mess up the low frequency response of the chip or induce oscillations in the chip. silence_kit fucked around with this message at 20:40 on May 30, 2020 |
|
#
?
May 30, 2020 19:48
|
|
|
Ambrose Burnside posted:got a question about ballast requirements for UV-C mercury vapour bulbs: I built one of these a few weeks ago. I didn't create a turntable, I just rotate the item(s) manually...much easier and less prone to something breaking without me realizing it and it always just exposing one side of the items to the full dose of UVC. Note that UVC is only weakly reflected so you need to increase your exposure time accordingly. This page has a calculator for exposure time vs bulb wattage and enclosure size. And yes, ballasts for tubes are weirdly specified. I ended up figuring out that you can source ballasts as if it was a regular fluorescent tube at the specified wattage. Of course you have to find the data sheet for every ballast since of course it's not something they just put in the item descriptions. The ballasts I looked at usually had a list of different bulbs and how many bulbs of that type it supported. I ended up with this ballast for a single PL-L55W/TUV 55 watt UVC bulb. I was never able to figure out what actually matters when it comes to driving these bulbs. You'd think you'd be able to just say this bulb requires X watts, Y amps, Z foobars and this ballast meets those requirements. But...all the data I came across was prescriptive in the sense that each ballast often specifies obtuse model numbers of bulbs it supports. It'd be nice if I could verify effectiveness with either a real handheld UVC sensing device or building something with a UVC sensor component but alas they're loving expensive. You should be able to smell ozone when opening your box. Put a safety switch on the lid to your enclosure so it shuts off the lamp when the lid is opened! Big Clive on YT has some videos on validating UVC output. Here's one where he uses a banana! https://www.youtube.com/watch?v=7lzq6LuVWH0 Thermopyle fucked around with this message at 18:47 on May 31, 2020 |
|
#
?
May 30, 2020 19:52
|
|
|
silence_kit posted:I don't think this is always true. I agree that there is a lot of hokum in how people design bypassing networks. Just to be clear, I'm advocating that people follow the application datasheet, because it works. Just know that many of them include theories of design that haven't been true since the 90s. But follow the reference designs, because they work. If you want to go off down your own design path later, that knowledge is helpful, but it's not a first step.
|
|
#
?
May 30, 2020 20:10
|
|
|
The TDK equivalent circuit models for these 0603 & 0805 C0G capacitors seem to suggest that I'm wrong, that the inductance is a property of the package, not of the internal interdigitated structure. The inductance in their models doesn't change with the capacitor value for a fixed package size, but goes up as the package size increases. https://product.tdk.com/info/tvcl/ecm/mlcc_commercial_general_c1608_ecm.pdf https://product.tdk.com/info/tvcl/ecm/mlcc_commercial_general_c2012_ecm.pdf silence_kit fucked around with this message at 20:45 on May 30, 2020 |
|
#
?
May 30, 2020 20:42
|
|
|
Hey dudes. What are your thoughts on using allocators in embedded? I'm a bit hesitant since I think my display buffer is taking up a big chunk the memory, and don't want to risk running out. It would help with text display. I spent a good chunk of today writing code that prints a decimal followed by some chars. Could do it by invoking an allocator and using the lang's built in string formatter, as you would on a PC. The code I wrote involved splitting a float into two ints, using a lib that processes them into string slices, doing a bit of manip on the slices to trim, and assembling them (left side, decimal char, right side, follow-on text) each at a specific pixel location based on a cumulative sum of spacing. Without an allocator, you can only work with immutable string slices, as far as I can tell. What would you recommend? - Just use the allocator - Keep it up; this approach works and will save you memory trouble - Publish a lib that does all this to help out the bros, then call it and pretend you're using a string formatter. The graphics lib is a HAL, so it could be device-agnostic. edit: I wonder if I could have achieved a more elegant soln by manipulating byte arrays directly to merge into a new string slice, instead of relying on drawing text at diff starting pixels. Dominoes fucked around with this message at 23:03 on May 30, 2020 |
|
#
?
May 30, 2020 21:15
|
|
|
ante posted:I mean, sure, you're reducing the impedance at the self resonant frequency by half, but I'm talking about the myth of "use a 100nF and a 1uF in parallel to decouple everything". You'd be better off using two of the higher value (assuming you're using the same packages) Ok, yes. Can't deny that. Those plots imply ESL of 400pH for all listed capacitance values, so using a smaller value cap in parallel instead if two larger caps would only make sense if some other design consideration stipulated less cap. I'll still point out that at very high frequencies where the inductance dominates the smaller cap values are "as good" as the larger ones in terms of impedance. There are cases where halving the impedance at 1GHz but only increasing the capacitive load presented to the power supply by 10% instead of doubling it is very desirable, but when you're that concerned with the cap on your power rail, you don't just wing it with a silly rule-of-thumb.
|
|
#
?
May 30, 2020 23:34
|
|
|
Thermopyle posted:I built one of these a few weeks ago. I didn't create a turntable, I just rotate the item(s) manually...much easier and less prone to something breaking without me realizing it and it always just exposing one side of the items to the full dose of UVC. this is super useful, particularly about potentially substituting less specialized ballasts based on wattage, thanks. i’m not deadset on a rotating drum, but i don’t wanna leave it to manual rotation because that’ll just mean i halfass it after two weeks. a potential alternative that’s less rough on electronics is a turntable with the platform made from a quartz disc- it’s transparent to UV-C so you can effectively put a bulb below and let it shine through. Quartz has issues with being touched though iirc; the skin oils can compromise quartz bulbs at any rate, a1/4” plate might be more durable. and yeah, not gonna attempt this without safety lockouts implemented, not a huge fan of Cancers And Cataracts Aplenty
|
|
#
?
May 31, 2020 03:16
|
|
|
Any idea what those ballasts look like internally? Or rather, what they actually output, in terms of electricity? Like, what would I have to do to take the output of one, and feed it into a standard AC-DC power supply and get me a clean 3.3v?
|
|
#
?
May 31, 2020 05:13
|
|
|
They're just current limited power supplies. Arcs in general are weird, in that they're "negative resistance". since the plasma of the arc is what carries the charge, a bigger plasma carries more, which makes a bigger plasma, which carries more, which... A ballast parks itself in the middle, provides a strike voltage of a few kv, then immediately moderates the current to acceptable levels.
|
|
#
?
May 31, 2020 05:41
|
|
|
Neat, so if I just toss a cheap Meanwell supply module in there, everything will be okay?
|
|
#
?
May 31, 2020 05:44
|
|
|
Get an electronic module (so it's high switching speed) and match the wattage to within 20%. Regular ballasts work on UV-C bulbs just fine, because ALL fluorescents are UV-C under the phosphor coating.
|
|
#
?
May 31, 2020 05:48
|
|
|
Neat, thanks. I'll give it a shot. Worst case, I blow some breakers.
|
|
#
?
May 31, 2020 05:53
|
|
|
Fluorescent bulb 'ballasts' also sometimes do other stuff to strike arcs for startup. Like heating up the electrodes or generating short kV pulses to ignite.
|
|
#
?
May 31, 2020 06:48
|
|
|
I'm a total newbie to the electronics stuff but I do microbiology for a living and we use UV sterilization at times. Just remember when designing / building your device that effectiveness of UV sterilization is subject to the inverse square law so be sure that your design allows your UV source to get as close to the objects as is feasible.
|
|
|
#
?
May 31, 2020 11:34
|
|
|
Dominoes posted:Hey dudes. What are your thoughts on using allocators in embedded? I'm a bit hesitant since I think my display buffer is taking up a big chunk the memory, and don't want to risk running out. It would help with text display. Swing on over to the arduino thread; we're deep in the programming weeds there. To answer your question: If you use good programming practices, you should be fine. I tend to write only in ANSI C for most stuff, with C++ only where it's convenient (prototypes, inline variable declarations, etc). When I'm rolling my own snprintf(), I work with fixed-width byte arrays ("strings") and pass those around. Almost always, the graphics libs are way better at turning text into pixels than I am, but suck at turning non-text into text.
|
|
#
?
May 31, 2020 15:40
|
|
|
Awesome - thanks for the info. I bet that thread's probably applicable for more than Arduino. I reflowed the code to generate str slices instead of using multiple draw events. same result, but cleaner code. Basically, you pass in mutable refs to buffers for the left and right integers, and the resulting str. The fn then fills the str buffer from the l, and r, with a decimal in between. The hardware I'm using has an allocator, and I've successfully tested it. (You add a few lines of boilerplate, then normal things like string formatting, dyanic-size collections etc work), but I'm hesitant, since the setup I'm using will fail without error message if you go over the allotted memory... Not cool.
|
|
#
?
May 31, 2020 22:07
|
|
|
Arduino stuff doesn't have an MMU btw, if you're continually allocating memory, it never actually deallocates properly and frees up the memory, so eventually you'll smash your stack. It might take hours or days and will be drat near impossible to troubleshoot. Only skimmed that discussion though, so that might not be what you're asking at all in which case carry on
|
|
#
?
May 31, 2020 22:22
|
|
|
Absolutely asking, but I ommitted that I'm using an STM32, which has an MMU. I'm using Rust which is notorious for failing to compile vice giving runtime errors, so I'm surprised it behaves this way when when I allocate too much memory statically. I think I don't have something configured right.
|
|
#
?
May 31, 2020 22:52
|
|
|
I don't think any of the Cortex-Ms have an MMU. Some have a memory protection unit and/or "execute in place" capability for external flash/SRAM. Can you write your graphics module in C and just call it from your larger Rust application? Totally different beast but when I was writing FreeRTOS on Motorola HCS12 chips the only way to keep track of the stack was fill it with known value at the beginning and keep an eye on it in the debugger to make sure it didn't write past the end of it. Edit: Oh I guess the STM32MP line is Cortex-A, I was thinking those weren't part of the STM32 line for some reason. Is are you using one of those? Forseti fucked around with this message at 23:39 on May 31, 2020 |
|
#
?
May 31, 2020 23:34
|
|
|
hah, I wrote an RTOS for an HCS12 in school. Yeah, we allocated everything right on startup, and then just didn't touch it again.
|
|
#
?
May 31, 2020 23:49
|
|
|
That Works posted:I'm a total newbie to the electronics stuff but I do microbiology for a living and we use UV sterilization at times. Just remember when designing / building your device that effectiveness of UV sterilization is subject to the inverse square law so be sure that your design allows your UV source to get as close to the objects as is feasible. programming/software is my biggest weakness here so “we shall see” but i was hoping to try to control for as many variables here as i can through the Cycle Configuration, and source distance seems like low hanging fruit in that regard. i want to make the enclosure big enough to offer flexibility wrt what can be processed, which will lead to a lot of potential variation w that variable; my thinking is to compensate by letting the user specify the distance from source (or measure offset automatically? + finally find a real application for all these $2 ultrasonic rangefinder modules) and adjusting the recommended cycle time accordingly
|
|
#
?
May 31, 2020 23:54
|
|
|
|
| # ? May 9, 2024 20:02 |
|
|
ante posted:hah, I wrote an RTOS for an HCS12 in school. To clarify, writing a program using FreeRTOS I meant, I wish I was cool enough to have helped develop it! I really liked using it, I should probably take a look at its current state since that was like 10 years ago.
|
|
#
?
Jun 1, 2020 00:00
|
|