|
if your ALU ops are drawing a significant amount of power because bitflips near zero, just bias the stupid thing and make up for the difference in the cloud where power doesnt matter btw hope you're also choosing instruction patterns based on what doesn't flip opcode registers, using the low part of the address space or making sure to jump to not cause flips in the PC, and every other ridiculously useless micro-optimization ostensibly justified by "IoT needs to save power"
|
#
?
Jul 30, 2017 18:16
|
|
|
|
| # ? Apr 27, 2024 05:29 |
|
|
IoT things can best save power by not existing
|
|
#
?
Jul 30, 2017 18:40
|
|
|
Sweevo posted:IoT things can best save power by not existing
|
|
#
?
Jul 30, 2017 19:31
|
|
|
but if they don't exist how will we sell 80 billion devices by 2030 and grow grow grow forever
|
|
#
?
Jul 30, 2017 19:49
|
|
|
ok so here is a tough one I've been trying to figure out, maybe smarter people than me can patiently explain. I'll be honest, it's a work project. I've been trying to do capacitive sensing of a large object. Basically, a set of bike handlebars made out of steel. They're part of a larger steel structure (10' tall steel post), but electrically isolated - the handles mount to a heavy duty plastic piece which mounts to the other steel. Doing testing at the shop, I managed to get a pretty good signal/noise ratio. In the real application though, it was a mess. There's too much noise, and when I do manage to get something to seem to be right, the sensor misunderstands and re-calibrates when it senses a touch. The setup is basically an Arduino and one of these: https://www.adafruit.com/product/1982. I've also used this in the past: https://www.adafruit.com/product/1602 but the documentation from Microchip is much harder to follow, and I've found more luck with the MPR121. It's very easy to read the data directly from and get a better idea of what is actually going on. So, there's a few things I've tried: 1) Using a shielded cable for the connection to the touch object - doing this basically made it act like a grounded the entire touch object (something I tried) (basically the signal flatlines and responds to nothing) 2) Grounding the steel structure that is near my object - didn't really help much 3) Keeping the wire short between the touch object and controller - I managed to get the distance down to about a foot, which seemed to work as a test, but then totally failed when setup fully. 4) Messing with various charge/discharge/filtering options manually (mixed results). One thing I will note is that once I turned off the power to the controller by accident, and it was running purely off my USB connection to my computer, which was running off battery at the time. The signal was beautifully easy to see. My guess is that mostly I'm dealing with EMI, but I'm not sure how to go about getting rid of it. Should I be doing more to isolate my DC power supplies to this thing? Should I be doing it some other way? I've done Capacitive touch a few times before, and generally smaller = better. I've had the thought to cut the handles off and replace them with heavy duty delrin wrapped in copper foil underneath a foam grip, which I suspect would be much easier to read as it's a smaller object.
|
|
#
?
Aug 1, 2017 01:10
|
|
|
yo should i buy the psoc 4 and 5 dev kits for 4 bux or tenbux i am electronics moron and the graphical ide speaks to me
|
|
#
?
Aug 1, 2017 02:32
|
|
|
Fanged Lawn Wormy posted:Doing testing at the shop, I managed to get a pretty good signal/noise ratio. In the real application though, it was a mess. There's too much noise, and when I do manage to get something to seem to be right, the sensor misunderstands and re-calibrates when it senses a touch. whatever driver you're using that recalibrate on a touch is probably getting in the way. like you mentioned below, you need to get raw values and do the processing yourself quote:1) Using a shielded cable for the connection to the touch object - doing this basically made it act like a grounded the entire touch object (something I tried) (basically the signal flatlines and responds to nothing) my crude understanding was that they hooked up a charge pump to the input, waited for the pad to charge up to a threshold voltage, grounding it, then counting how many times that cycle could repeat before reporting that number out. i can't really follow what your sensing element is, but it sounds like "a big chunk of metal"? minimizing the sensing element would probably help before changing the composition of the bars, surrounding it with a ground is recommended for cap sense buttons. grounding both sides won't work, it'll make it impossible for the sensing to work. quote:One thing I will note is that once I turned off the power to the controller by accident, and it was running purely off my USB connection to my computer, which was running off battery at the time. The signal was beautifully easy to see. My guess is that mostly I'm dealing with EMI, but I'm not sure how to go about getting rid of it. Should I be doing more to isolate my DC power supplies to this thing? Should I be doing it some other way?
|
|
#
?
Aug 1, 2017 02:59
|
|
|
DC Supply is a 12V 1A generic power brick, since I'm running a little LED display that requires more power (the program works, but the display doesn't, when I run off USB). I may grab something nicer just to try it out.JawnV6 posted:whatever driver you're using that recalibrate on a touch is probably getting in the way. like you mentioned below, you need to get raw values and do the processing yourself quote:my crude understanding was that they hooked up a charge pump to the input, waited for the pad to charge up to a threshold voltage, grounding it, then counting how many times that cycle could repeat before reporting that number out. Yeah, the element is almost literally a bike handlebar made of steel tube. Surprisingly, at our shop it worked great - I could even sense it through some foam handles with no issues. I was feeling warily confident it would work on site, even though production never got me the structure until I was installing. But I think all the stuff going on in this area is just too much. During install, I resolved to drop the cap sensing in favor of getting the program running, but it looks like there may be some other issues, so I may try and fix the feature when I return to address those. My big idea right now is to turn down some delrin rods and lop off the very end of the handlebar to make a specific grab zone that will be much easier to tune. I think the other thing to do to try and get the sensor to do what I want is: 1) Push out a lot of charge 2) Wait a (relatively) long time for the charge to dissipate 3) make sure to use lots of samples for a baseline in the filtering process. I think something else I didn't try yet is to connect the controller ground to building ground directly.
|
|
#
?
Aug 1, 2017 05:05
|
|
|
Malcolm XML posted:yo should i buy the psoc 4 and 5 dev kits for 4 bux or tenbux NO
|
|
#
?
Aug 1, 2017 12:53
|
|
|
never forget this universal truth: every graphical design "helper" for embedded work is a pile of trash. on the particularly good ones they'll support ~90% of the chips capabilities and if you're lucky you'll be within that 90%, and it'll only be a mostly tedious and incredibly painful process that doesn't get you much over just configuring it yourself in code. on bad ones that only support ~80% or if your task requires something outside the supported set you're hosed because they're a) never set up to work in a modern programming environment with source control and automatic builders and b) often want to control everything and are tough to impossible to integrate your own code into. i mean if it's for loving around sure it's $10, but psoc creator in particular is a callback to the bad old pre-cortex days of every arch requiring its own godawful vendor-"supported" toolchain. poster otto skorzeny used to rant all the time about this one in particular too
|
|
#
?
Aug 1, 2017 12:57
|
|
|
i've been using psoc 5s for a couple of years now and they're ok. just because it has a 'graphical ide' doesn't mean that you can do poo poo in it. you can make some connections between components and some basic changes to things, but everything still needs to be done in c++. iirc bloody had some awful problem with them years ago but i've had no issues with mine. they're nice for prototyping scientific instrumentation since they have an onboard 20 bit adc and many other commonly used things. usb for communication is a pain in the rear end compared to rs232 so keep that in mind. for $10 tho you could do worse i guess
|
|
#
?
Aug 1, 2017 14:41
|
|
|
Phobeste posted:never forget this universal truth: every graphical design "helper" for embedded work is a pile of trash. on the particularly good ones they'll support ~90% of the chips capabilities and if you're lucky you'll be within that 90%, and it'll only be a mostly tedious and incredibly painful process that doesn't get you much over just configuring it yourself in code. on bad ones that only support ~80% or if your task requires something outside the supported set you're hosed because they're a) never set up to work in a modern programming environment with source control and automatic builders and b) often want to control everything and are tough to impossible to integrate your own code into. lol i am crafting a cmake system that ingests the output of STM's CubeMX tool at this very moment
|
|
#
?
Aug 1, 2017 16:15
|
|
|
Minnesota Mixup posted:i've been using psoc 5s for a couple of years now and they're ok. just because it has a 'graphical ide' doesn't mean that you can do poo poo in it. you can make some connections between components and some basic changes to things, but everything still needs to be done in c++. iirc bloody had some awful problem with them years ago but i've had no issues with mine. they're nice for prototyping scientific instrumentation since they have an onboard 20 bit adc and many other commonly used things. usb for communication is a pain in the rear end compared to rs232 so keep that in mind. nope wasn't me, havent used em
|
|
#
?
Aug 1, 2017 17:04
|
|
|
Fanged Lawn Wormy posted:DC Supply is a 12V 1A generic power brick, since I'm running a little LED display that requires more power (the program works, but the display doesn't, when I run off USB). I may grab something nicer just to try it out. Fanged Lawn Wormy posted:yeah, reading the data sheets on these things their examples are always little tiny pcbs. I'm like, but what about.... cast bronze boats the size of a shoe? no guide for that??? im sure this is apparent by now, but cap sensing is all relative. one reading in isolation will never make sense, you need to set a baseline. my device sampled once a second at the highest rate, dropping down to once a minute to save power, but to avoid a massive switch right at the hour mark i'd collect 15 minutes worth of 'baseline' from the previous hour
|
|
#
?
Aug 1, 2017 17:18
|
|
|
Minnesota Mixup posted:iirc bloody had some awful problem with them years ago but i've had no issues with mine. they're nice for prototyping scientific instrumentation since they have an onboard 20 bit adc and many other commonly used things. usb for communication is a pain in the rear end compared to rs232 so keep that in mind. nah, you're thinking of Otto, his problems were around building super sensitive analog equipment and getting 18+ ENOB's out of the claimed 20
|
|
#
?
Aug 1, 2017 17:19
|
|
|
lol if your 20 bit adcs cost less than 50 bucks a pop
|
|
#
?
Aug 1, 2017 17:27
|
|
|
JawnV6 posted:nah, you're thinking of Otto, his problems were around building super sensitive analog equipment and getting 18+ ENOB's out of the claimed 20 ah ok. its actually pretty uncommon for adcs to produce whatever bit they are as ENOBs without extensive oversampling from what i've seen. you can probably get 20 bits from the psoc but you need to oversample, which means its slow. i think i usually see around 18 enobs but i also use a separate better vref than what is built in. ive been playing with the ads1263 and its pretty great. nice having the 32 bit and 24 adc together with plenty of channels with the vref built in.
|
|
#
?
Aug 1, 2017 18:23
|
|
|
apparently there's some sort of world wide resistor shortage?  a supplier for resistors on our boards is quoting an 80 week lead time!
|
|
#
?
Aug 1, 2017 23:47
|
|
|
JawnV6 posted:nah, you're thinking of Otto, his problems were around building super sensitive analog equipment and getting 18+ ENOB's out of the claimed 20 can confirm psoc adc's are garbo e: they're okay to develop software for tho. at least, they're no worse than average for microcontrollers
|
|
#
?
Aug 2, 2017 01:56
|
|
|
hobbesmaster posted:apparently there's some sort of world wide resistor shortage? psssh just etch some bare fiberglass and go over it with a #2 pencil
|
|
#
?
Aug 2, 2017 02:33
|
|
|
I'm sure the FCC would love RF circuits built that way
|
|
#
?
Aug 2, 2017 04:55
|
|
|
fcc doesn't give a poo poo about quality
|
|
#
?
Aug 2, 2017 05:02
|
|
|
Bloody posted:fcc doesn't give a poo poo about quality I didn't realize the FCC took lessons from your posting.
|
|
#
?
Aug 2, 2017 05:05
|
|
|
Bloody posted:fcc doesn't give a poo poo about quality well if your tolerances mean you're transmitting ar too high power or on a regulated band you're kinda hosed
|
|
#
?
Aug 2, 2017 05:10
|
|
|
you're using a pencil! it's the most tunable resistor! just use the eraser or scratch a little more if u got a multimeter youre gonna be fine
|
|
#
?
Aug 2, 2017 05:23
|
|
|
this idea’s going over like a lead balun!
|
|
#
?
Aug 2, 2017 09:14
|
|
|
is ST's toolchain better than the NXP kinetis line? because hoooly poo poo it was a colossal pain to figure out how to use NXP's peripheral configurator to set up my PLLs, and the resulting code wouldn't even compile
|
|
#
?
Aug 2, 2017 16:10
|
|
|
just use keil and cmsis or gcc edit: for the STs, I assume those toolchains are just fine for nxp as well though
|
|
#
?
Aug 2, 2017 17:31
|
|
|
stmcubemx is a lot better than older kinetis poo poo (stay away from processor expert at any cost) but free scales modern approach that's basically a cmsis drop is fine, honestly I'm stuck with MQXlite (their old licensed rtos) and processorexpert (their old graphical configurator that was built in to an eclipse distribution) and it's the worst thing in the world, it's actively hostile to collaboration and source control
|
|
#
?
Aug 3, 2017 01:49
|
|
|
hobbesmaster posted:just use keil and cmsis i'm a poor, not gonna drop $$ for keil plus, my open sources  as for cmsis, how do i get started with that shiat? is it easier/better than sperging over the processor guide and writing my own drivers for stuff?
|
|
#
?
Aug 3, 2017 02:53
|
|
|
keil is free under 32kb so you're good for small m0 projects cmsis-core is a simple hal that gives you C functions for common tasks on a mcu and lets you not have to muck with the precise register values for enabling the HSE or whatever http://arm-software.github.io/CMSIS_5/Core/html/using_pg.html you can also go up another abstraction layer on some processors and use ARM's mbed project. it makes it really simple and gives you for example an AnalogIn class that'll initialize an ADC with "reasonable" defaults. you're still free to directly access registers if you want another fun thing is that you don't actually have to use mbed to use arm's free web ide at https://developer.mbed.org your target does need to be on an mbed board though.
|
|
#
?
Aug 3, 2017 03:39
|
|
|
hobbesmaster posted:just use keil and cmsis keil satan
|
|
#
?
Aug 3, 2017 04:35
|
|
|
JawnV6 posted:this idea’s going over like a lead balun!
|
|
#
?
Aug 3, 2017 04:36
|
|
|
Poopernickel posted:is ST's toolchain better than the NXP kinetis line? Gcc works fine if its a imx processor. Not sure about their other ones though.
|
|
#
?
Aug 6, 2017 16:52
|
|
|
if you're using an stm32 just use the cube. if you hate the little configurator, it drops all the drivers in a folder you can just copy out of if you want
|
|
#
?
Aug 7, 2017 05:21
|
|
|
gently caress device trees gently caress raspberries pi gently caress everything i ain't got time to get a phd in whatever semi-undocumented stupid mmio layout description language the linux gophers are using this week
|
|
#
?
Aug 11, 2017 22:07
|
|
|
|
|
#
?
Aug 11, 2017 22:07
|
|
|
Sapozhnik posted:gently caress device trees gently caress raspberries pi gently caress everything 
|
|
#
?
Aug 11, 2017 22:12
|
|
|
Sapozhnik posted:gently caress device trees gently caress raspberries pi gently caress everything wait device tree is pretty good, it's just documented very poorly  make sure you look in linux-x.y.z/Documentation/devicetree/ and linux-x.y.z/Documentation/devicetree/bindings for examples of various devices' uses in your .dts file
|
|
#
?
Aug 11, 2017 23:43
|
|
|
|
| # ? Apr 27, 2024 05:29 |
|
|
device tree is documented so poorly it's often more useful to go find the driver code and read it. that makes it actively worse than boardfiles because at least board files are in c not some hellspawn of an xml pile of trash
|
|
#
?
Aug 12, 2017 14:46
|
|