|
designed my first PCB recently because i wasn't willing to use 120+ jumper wires on a breadboard. i used Fritzing and it was a painful, buggy and slow experience. but i learned a lot and the end product works!  
|
#
¿
Oct 27, 2017 18:14
|
|
|
|
| # ¿ Apr 25, 2024 17:13 |
|
|
looks pretty great, i'm checking it out now
|
|
#
¿
Oct 27, 2017 19:17
|
|
|
the technical manual is a fun read. sometimes prideful, sometimes utterly ashamed of the nightmarish bugs that infest every single aspect of the devicequote:The tour de force of the Blitter is its ability to generate Gouraud shaded polygons
|
|
#
¿
Nov 2, 2017 02:05
|
|
|
you can't use this instruction in this memory address range you can't put this instruction after this other instruction. or this one. or that one. or... you must put this instruction in front of this instruction, sometimes, but never other times don't divide and then divide again this way. only the other way multiply followed by multiply is okay. but not multiply and read the result. obviously clipping doesn't work properly "in a fairly random manner" clipping doesn't clip "may corrupt other data in RAM" memory access every six cycles. sorry i know i said it was two hey kids! what's the deal with byte strobes??? you're not strobing bytes! "This may move the problem [...] which may still cause problems." don't jump in external memory. don't call in external memory. don't use external memory at all. kill you are self
|
|
#
¿
Nov 2, 2017 02:18
|
|
|
speaking of DMA, someone tell me if this is normal i'm doing some graphics stuff on an nxp lpc4357. basically i'm using the dma as a scanline rasteriser using the scatter gather mode. i made a benchmark to see how much i can wring out of this thing and it's not as good as i hoped: code:
|
|
#
¿
Nov 22, 2017 21:37
|
|
|
what io module has an accelerometer, gyroscope, rgb led, multitouch pad, 6 potentiometers and 14 buttons, but only needs four wires? learning how to usb!
|
|
#
¿
Mar 8, 2018 22:40
|
|
|
got everything working including the rumble and touchpad. feelin pretty good the touchpad is impressively accurate, about 2000x1000 resolution on a 2x1 inch device. there's a lot of bad information on the internet about the gyro/accelerometer. but it's easy to see what the values mean by rotating the controller on its axes and looking at the USB data. Spatial fucked around with this message at 22:24 on Mar 9, 2018 |
|
#
¿
Mar 9, 2018 22:21
|
|
|
it's an NXP LPCxpresso board with an LPC4367 on it. kind of a cool chip with heterogenous cores, 1x cortex m4f and 2x cortex m0. i also have a different one with an LCD controller but one less m0 core. i'm going to make a terrible game console out of it for fun.
|
|
#
¿
Mar 10, 2018 07:14
|
|
|
i spent a while setting up the memory protection unit in my M4. now instead of jumping to NULL and happily executing until it fucks itself up, i'll get an interrupt telling me not only when, but where it happened! i'm approaching 1988 technology here!
|
|
#
¿
Mar 18, 2018 22:09
|
|
|
this M4 only fires electrons another nice trick is allocating the stack at the start of memory instead of the end. can't overflow and corrupt memory because the MPU will catch it. at my workplace the conventional wisdom is to put it at the end. that's not using your noggin fellas
|
|
#
¿
Mar 18, 2018 22:21
|
|
|
~for my technology~ i work with bare metal where's there's generally only one stack, i guess it's different in an RTOS where there's lots of stacks and their sizes may even be dynamically allocated you could change the MPU regions during context switch. but there are all sorts of limitations that make it real awkward, like needing power of 2 sized naturally aligned regions, and there are only 8 of them.
|
|
#
¿
Mar 19, 2018 00:54
|
|
|
actually that reminds me, the newer Cortex M23 and M33 have dedicated registers for detecting stack overflow. it's a good feature. they can detect stack corruption with a hardware-generated stack canary as well.
|
|
#
¿
Mar 19, 2018 01:09
|
|
|
speaking of aural fun, i'm working on the audio mixer for my babby console now. i've worked a lot with audio in the past but not at this level of farting around with the individual bits. it's pretty fun. i'm aiming for 44.1 KHz on 16 channels with independent volume, panning and frequency + linear resampling. real state of the art stuff from before i was born it's a bit of an optimisation problem because that's 705,600 samples per second with several DSP operations on every sample, and this is a microcontroller with no audio accelerator. that's a lot of cycles. i can always lower the peak channel count but that's no fun i'm outputting over I2S to a Cirrus Logic CS4344 DAC. surprisingly good quality for $1.50!
|
|
#
¿
Mar 28, 2018 23:55
|
|
|
scopin' dat audio
|
|
#
¿
Mar 29, 2018 19:29
|
|
|
i got to know the M4's DSP instructions and made the core of the mixer in assembly. > Channel mixed in 1856 cycles (14.5 cycles/sample). maybe i can afford reverb after all 
|
|
#
¿
Mar 31, 2018 23:01
|
|
|
Sagebrush posted:well i started to reprogram the display but i am not sure it's happy about it
|
|
#
¿
May 10, 2018 00:37
|
|
|
lol have you considered not solving the problem and having even less money than before
|
|
#
¿
Jul 1, 2018 19:45
|
|
|
i got a PL2303TA usb-uart chip with a supposed max rate of 6 megs. actual max i was able to get: 480k. $1.20 folks tried an FT232R with a max of 3 megs. works perfectly at the absolute max. $4.50 well spent
|
|
#
¿
Aug 15, 2018 20:45
|
|
|
lol windows waits 16ms after receiving data on the COM port to tell you about it not so good when you have a device that responds in 0.003ms.
|
|
#
¿
Aug 16, 2018 21:02
|
|
|
code:
|
|
#
¿
Aug 16, 2018 23:50
|
|
|
incredibowl
|
|
#
¿
Sep 11, 2018 19:41
|
|
|
SSE2 can do 16 of those per cycle. it's some variant of PSUB. that includes the saturation btw Spatial fucked around with this message at 14:19 on Oct 15, 2018 |
|
#
¿
Oct 15, 2018 14:14
|
|
|
 full motion video, the latest in computer entertainment. it's 24hz 480x272 running on a Cortex M4. i could play the entire movie if i bothered to encode it. not shown but you can seek through the video using the PS4 touchpad the colour is perfectly accurate in real life but looks extremely blue when recorded on my crappy phone camera. although i did have to colour correct the image for the LCD screen anyway, the blue level of the LCD is more than 200% of normal and looks like rear end otherwise
|
|
#
¿
Jan 30, 2019 12:57
|
|
|
when you don't know kung fu
|
|
#
¿
Jan 30, 2019 12:59
|
|
|
a little on how it works, since i like reading about these things maybe you will too! the movie is dumped to raw pixels using ffmpeg, and then i encode it into a format that's simple enough to practically use on a microcontroller. each 480x272 frame has its own 256 colour palette and each pixel is one byte that indexes into it, a bit like a GIF with no compression. this is then written to an SD card. the video data is streamed onto off-chip SDRAM via DMA from the SD card controller. the drivers for the DMA and SDC were so bad i had to rewrite them from the barely-documented hardware specs - all SD operations were blocking, which is terribad because there can be hundreds of milliseconds of latency at random intervals. smooth video is impossible under those conditions. on each vsync interrupt from the lcd controller i start rendering a new frame. the palette is loaded first and then the inner loop loads 96 pixels at a time: the byte sized pixels are loaded into CPU registers, unpacked, their colour is looked up and they're written into the video buffer. the palette is loaded into fast single-cycle on-chip SRAM because SDRAM has very poor random access performance - when you consider that the indirect palette lookup runs 130,000 times per frame it really adds up. once all the pixels are blitted the double buffering pointers are swapped and the cycle repeats. i wrote the video blitter in assembly and it cranks out a frame in 2ms, leaving lots of time to do other things besides drawing the video. it was an interesting optimisation exercise and is about five times faster than the C equivalent.
|
|
#
¿
Jan 30, 2019 14:14
|
|
|
does the IronWolf® come with a free t-shirt?
|
|
#
¿
Mar 14, 2019 13:45
|
|
|
anyone know where i can get a board that converts parallel RGB to something like vga or hdmi? i want to output a microcontroller's TFT display to a monitor. the opposite of this board on Adafruit pretty much
|
|
#
¿
Jun 30, 2019 20:11
|
|
|
the last one looks like it's sparkling because of the colour shifts, it's a very lively and cool look. also very demoscene
|
|
#
¿
Jul 11, 2019 00:55
|
|
|
i was looking into making a circuit to drive a VGA output from my micrcontroller. turns out this is easy in theory because you can use a single component to do it, like the ADV7125. i thought, hey, computers output 320x200 and that works so i can just pass that through directly. what i didn't realise is that VGA controllers do pixel doubling to do that, and monitors can't understand such a low pixel clock. apparently only the really old 80s style ones can do this. i can drive 640x480 from the MCU and that would work, but it would take too much memory bandwidth and reduce the capabilities of the device too much for what i want to do (a lovely game console). so now what i'm going to do is something stupid. add another microcontroller that just does the upscaling and nothing else! 320x200 is slow enough (~6MHz) to sample if the GPIOs are hooked up appropriately. then that MCU can output the vga compatible signal. anything is better than designing an fgpa circuit, at least!
|
|
#
¿
Jul 13, 2019 00:06
|
|
|
longview posted:VGA monitors have no way to know what the pixel clock is though, if your sync pulses have valid timings the pixel data can be as slow as you want there's no reason a monitor can't accept any old resolution, but it seems like they use simple designs that just try to detect a few known formats from a table.
|
|
#
¿
Jul 13, 2019 16:24
|
|
|
oh cool, thanks for taking the time to explain it. i didn't quite realise what they were getting at.  drat nifty trick if i can pull that off on my MCU!
|
|
#
¿
Jul 14, 2019 06:27
|
|
|
ah nuts. one thing i can't replicate with my setup is dividing the vertical counter to match up the timing like he does. on mine the video output is generated by a hardware block that doesn't have that degree of flexibility. i can match the horizontal timing but not the vertical. on the other hand, i can replicate the vertical timing by changing the framebuffer to be double height and duplicating the lines when i'm done drawing. it's a chunk of memory bandwidth but it's more acceptable to double it than to quadruple it like i would've needed to do before
|
|
#
¿
Jul 14, 2019 20:42
|
|
|
anyone know how tolerant HDMI/DVI are of very low resolutions? kinda curious what happen if i sent 320x200 through a HDMI transmitter
|
|
#
¿
Jul 16, 2019 18:20
|
|
|
i don't mean the connector but the actual HDMI transmitter IC. some that i've looked at only support a very specific subset of resolutions, most don't specify what they can do at all. i did find one that does what i want though! quote:7.13.1 Pixel repetition
|
|
#
¿
Jul 18, 2019 04:53
|
|
|
in the meantime i learned kicad and designed the VGA output. last time i made a pcb was with fritzing and it was absolutely terrible. this was much easier, kicad is pretty cool
|
|
#
¿
Jul 18, 2019 05:03
|
|
|
it sure looks like real HAM, the horizontal smearing is dead on
|
|
#
¿
Jul 31, 2019 11:31
|
|
|
Spatial posted:in the meantime i learned kicad and designed the VGA output. last time i made a pcb was with fritzing and it was absolutely terrible. this was much easier, kicad is pretty cool i had this manufactured! the real deal:  it works too! 
|
|
#
¿
Aug 16, 2019 22:23
|
|
|
Sagebrush posted:since i can't go flying i've been designing a much more complicated PCB than i've ever done before. this is a development board / lovely game console based around a Cortex M4 microcontroller. there's a small FPGA to upscale the LCD video output of the MCU and output it to a HDMI transmitter. the front port USB is for a game controller. also like 20 LEDs, you gotta have them lights i got a bit carried away and added everything i thought would be cool. it's been a hell of a learning experience.  many such layers 
|
|
#
¿
Apr 10, 2020 23:48
|
|
|
while i'm waiting for my last project to get manufactured, i tried making a development board that is very small but still usable and cheap to make. this is the result: it's based around the stm32g030, a 64mhz cortex M0+ with 8k sram and 64k flash. the pin headers expose 2x I2C, 2x UART, SPI, multiple 2msps 12-bit ADCs and up to 14 gpios. i added an 8-bit DAC and 2 megabytes of spi flash to make it more useful out of the box. also two buttons and leds for tinkering. can be powered over usb or directly from a li-ion battery costs less than 10 dollars to make even in tiny quantities, which is less than many of the ICs on the boards i typically make
|
|
#
¿
May 5, 2020 22:15
|
|
|
|
| # ¿ Apr 25, 2024 17:13 |
|
|
a key factor is that the choice of data encoding is made per row of the image. it's really slow to try all permutations so normal tools often use a heuristic. some just use a fixed encoding choice for all rows, usually paeth since it results in the best average compression rate. good old DEFLATE is used for compression which has an effort setting of 0-9. saving PNGs is very slow even now so lots of tools compromise on that especially older ones, which is another avenue for improvement. i've written a parallel PNG encoder before that massively speeds up encoding because i needed to deal with very large images. it compromises compression rate by <1% as a tradeoff because it has to split the data into multiple DEFLATE streams. i don't know how common this is then there's a bunch of redundant headers tools can add. that probably only matters for tiny images.
|
|
#
¿
May 25, 2020 11:44
|
|