|
i assume that's cause of leakage or tunneling or something as it gets closer to the breakdown voltage of the dielectric?
|
#
¿
Jun 4, 2017 17:40
|
|
|
|
| # ¿ May 16, 2024 20:41 |
|
|
goldarnit. my arduino nano quit responding (must have brushed it with the 12v or something) and i lent my other one to a student (mistake) and she never returned it and now i have no more breadboard-sized AVR usb microcontrollers to test with. how fast can amazon ship these things i wonder e: oh nm i have a teensy 2.0. *digs through drawer of dozens of different mcu boards, complains i have nothing that'll work* Sagebrush fucked around with this message at 20:42 on Jun 4, 2017 |
|
#
¿
Jun 4, 2017 20:39
|
|
|
yeah but that's messy and consumes space 
|
|
#
¿
Jun 4, 2017 20:58
|
|
|
probably better suited for idiot spare time projects thread but this is where i'm posting about mine so whatev it's coming together!! teaser 
|
|
#
¿
Jun 25, 2017 09:15
|
|
|
i may put it in the video i will make when this thing is assembled! it can absolutely do a knight rider/cylon eye scanner effect current state: i finally got the OLED fired up! far too difficult to interface with and the datasheet is, of course, quite poor, but check this poo poo out it's working:    top strip will be the tachometer, bottom will be the indicator lights and/or coolant temperature and/or other stuff. currently working on interfacing with the EERAM that i'm gonna use to store the mileage and other persistent stuff.
|
|
#
¿
Jul 1, 2017 04:04
|
|
|
atomicthumbs posted:otoh, digital things are utterly lame and if your storage scope uses mostly solid state electronics you're a fuckin scrub lol ok whatever dude. can your 564 do this 
|
|
#
¿
Jul 2, 2017 01:23
|
|
|
embedded programming question: if you have a constant in your code, what might be the reasons to use either #define SEXNUMBER 69 vs const uint8_t sex_number 69; ? I tend to use preprocessor directives for those things for no real reason other than that's what i got used to, but they both end up the same way after compilation iirc. is there an advantage to one or the other?
|
|
#
¿
Jul 4, 2017 02:37
|
|
|
Poopernickel posted:
what were they even going for here? if it's something like a 5mm LED you can do it literally as GPIO -> resistor -> LED -> ground why is there one transistor driving the LED and another transistor to drive that transistor (also is this a darlington pair?)? i guess i could see that being a thing if the LED is too powerful for the GPIO directly, and you picked some terrible drive transistor that needs more current to saturate than the microcontroller can provide? mosfets or bust Sagebrush fucked around with this message at 20:04 on Jul 8, 2017 |
|
#
¿
Jul 8, 2017 20:01
|
|
|
probably cause you can still get avrs in 5v DIP packages that are easy to mess around with, and they do the job for a lot of dumb little things and unlike PIC their toolchain isn't garbage
|
|
#
¿
Jul 8, 2017 23:35
|
|
|
got what i imagine is a real simple question: assuming that the goal is to chop a large piece of data into individual bytes, is there a functional difference between byte b = (32_bit_int >> 24); and byte b = (32_bit_int >> 24) & 0xFF; ? I've seen both the bit-shifting alone and the shift-and-mask method and I dunno what is the difference.
|
|
#
¿
Jul 21, 2017 08:31
|
|
|
Sweevo posted:if it compiles to a logical shift instruction then both are the same since logical shifting right puts zeros in at the left-hand side, so there's no need to zero them out later. whereas if it compiles to an arithmetic shift instruction then the left bits will be copies of the MSB of the input value (this preserves the sign in the result), so the leftmost bits might not be zero. it depends on the architecture/compiler, and whether or not the input value is declared as signed or unsigned. if you want it to be portable then shift+mask is more likely to be correct across different systems, but shifting alone is probably correct in 95% of cases. well, it's running on a cortex-m4 and i'm operating only on uint32_ts. using the mask to ensure safety for signed types makes sense. is it one cycle slower to do that, though? good to know that for this case it should work either way, though. that's what it seemed like but wanted to be sure. on a related note, is this the right practice? code:similarly, if i passed a pointer to boobs, would that also recover the MSB because it just reads the first 8 bits from that location?
|
|
#
¿
Jul 21, 2017 22:30
|
|
|
well i am already significantly more confused but  anyway, i'm glad to know that basically as long as it's an unsigned type i don't really have anything to worry aboutanyway, update on the vaporwave motorcycle instrument cluster: alpha version works! https://www.youtube.com/watch?v=GoSAprKVoQg got the whole thing finally assembled and installed and running with the v.0.1 code. still lots of UX things to work on, some industrial design changes I want to make, and lots of little details of calibration (temperature gauges, gamma table to balance the lighting, etc) but the basics do work! i am particularly happy with that analog filter/comparator i built earlier using the advice in this thread. reminder: it takes the incredibly noisy ~350v signal from the spark plug coil and shapes it down to a clean 3.3v square wave with hysteresis so i can have a tachometer. i installed the thing, spent 30 seconds adjusting the trimpot to set the correct threshold, and bam -- beautiful and accurate and i took the bike on a 100 mile test ride and i don't think i saw a single tachometer glitch the entire time. it's so smooth and responsive that i don't even need to filter the data, though i am going to do a really small median filter or something to cut down on the flickering when it's right between two LEDs on the scale.   
|
|
#
¿
Jul 23, 2017 19:31
|
|
|
Yeah definitely going to round the rpm to the nearest something-or-other. It's fairly distracting as is, not to mention impossible to read. Minor details, though -- that's like 10 lines of code obv. Right now the tachometer cycles through red/amber/green/amber/red as it goes through the power band, but I'm thinking of making it just monochrome with red at the redline, yeah. Infinite options for color-coding stuff like that. Personally I would have liked for the whole system to be red, but these OLEDs are only available in green and amber 
|
|
#
¿
Jul 23, 2017 20:47
|
|
|
oh and yes i am going to sync the grid movement with the wheel speed. already have that functionality written, just not active.
|
|
#
¿
Jul 24, 2017 01:15
|
|
|
Sweevo posted:eagle, kicad, and dipstrace are the big three for free pcb design tools. eagle is a weird program with a terrible UI, but has a lot of traction in the hobby scene so you can get help with it easily. kicad and dipstrace are distant seconds in terms of popularity, but are nicer to use. i've tried all three and diptrace is the only one that feels like something written in the last ten years
|
|
#
¿
Jul 25, 2017 20:45
|
|
|
They both feel like exactly what they are Eagle, a CAD program from like 1988 that hasn't had a single usability update since the initial release KiCAD, the same thing but also made by Linux users
|
|
#
¿
Jul 26, 2017 08:27
|
|
|
qirex posted:I saw this on an audiophile website and decided more people needed to see it ok, i guess i'll be the $80,000 that you need to spend on a cable to mitigate noise up to 200khz please ignore that 48MHz dollar-store USB 1.1 in the corner
|
|
#
¿
Aug 18, 2017 01:46
|
|
|
that's what they made the rpi compute module for 
|
|
#
¿
Aug 18, 2017 17:23
|
|
|
The teensy 3 is real and strong and my friend. What is going wrong?
|
|
#
¿
Aug 31, 2017 17:23
|
|
|
|
| # ¿ May 16, 2024 20:41 |
|
|
it sounds like you people are trying to use something other than god's own programming language, C++
|
|
#
¿
Aug 31, 2017 21:21
|
|