|
Cory Parsnipson posted:Some complaints I have is that the framerate of the small LCD is about 20fps because fbcp does a manual copy of the graphics card buffer to the screen since this LCD isn’t “officially” supported. This is too slow for games and also cuts into the CPU and power consumption of the device. Also you’ll need to turn on the LCD manually every time you start the Raspberry Pi with the modprobe command and then restart fbcp. The right way to do this is to create what’s called a dts overlay so that the device is recognized automatically. That’s a bit too much work for me right now because I’m planning on replacing this LCD with a bigger one and the replacement is going to be a very different screen. That's probably an SPI limitation, raw video data gets huge fast. Some dude made a library that optimizes it a bit by updating the parts that change rather than sending the full screen every time. Dunno if the screen you'll be using next is still SPI but if it is you might want to look into this: https://github.com/juj/fbcp-ili9341 The device tree isn't the most intuitive or well documented thing IMO but you'll probably have to mess with it at some point in your project. Basically ARM boards don't have a standardized way of querying unknown hardware to see what driver and system resources a piece of hardware needs to work. They used to hard code it into specific header files for every board back in the day but that got unwieldy fast so they came up with the device tree as a standardized way to describe what hardware is there and how it's connected. Good luck, cool project! If you haven't actually bought the display yet, https://waveshare.com and https://buydisplay.com are good vendors for displays.
|
#
¿
Nov 12, 2020 02:43
|
|
|
|
| # ¿ May 15, 2024 23:27 |
|
|
I know enough to fake it anyway  Definitely a lot of knowledgeable folks around these parts though who can point you down the right path though. As you are discovering there is a lot of difference between various displays! The basic problem with SPI is just that it's not all that fast. Not sure what the color depth is on that display but even 256 color would require 128px * 160p * 1 byte * 60fps =~ 1.2MB/s in raw data even for that small screen. 320px*240px*2byte*60 and you're looking at =~ 9.2MB/s for a 320x240 display with 16 bit color. There's definitely some protocol overhead to account for, especially if the driver isn't doing a bulk transfer of all that data. Depending on how much noise those jumper wires/breadboard are introducing you might get clock stretching slowing down the bus to see through the noise. Or the driver could be just bit banging SPI over GPIO if there's not an actual hardware SPI controller being used, which would be a lot slower (and eat a good bit of your CPU resources). That driver I linked to above is taking advantage of the LCD's controller chip having its own memory and just sending the the parts that changed from the last frame to greatly reduce the amount of data being sent. It probably needs tweaking to work with each specific driver chip but it looks like support for a lot of the usual suspects is already there. DSI is definitely much faster and will have hardware controllers to reduce the overhead on it. Honestly, if your display with the PCB has an HDMI port and you can fit it alright, it's not a bad way to go. HDMI will always have first class support in Raspbian since it's by far the most common way people are hooking up a display, so it should always work really well. At the very least it's a good development platform and a good way to remove variables and isolate the cause of any issues. Edit: Ooops, re: clock stretching it's actually i2c that has that built into the protocol where the device you're talking to can slow down the bus speed in the face of noise. The driver still might just set a slowish SPI baud rate by default or bump it down if it gets errors though. Forseti fucked around with this message at 17:51 on Nov 12, 2020 |
|
#
¿
Nov 12, 2020 17:44
|
|
|
If you can, try to figure out what displays are used in those cheap emulator hand helds on aliexpress (or any other cheap and popular thing on aliexpress that has an LCD) and you can probably find those displays cheap on eBay/aliexpress/various retailers. For example, displays based on the ILI9341 are really cheap on eBay and it has a DRM driver in mainline Linux. Caveat is that it uses SPI for its connection which is slow, but that optimized driver I mentioned a few posts ago manages to get pretty good results from it still. I didn't know that about DSI on the RPi that really sucks. I would have guessed that it would be the ideal way since it's intended for the purpose, but doesn't really matter if you can't get a good display for it at a good price  Personally, I'd probably look into something like this 4.3" 480x272 Display at $18 with a carrier board. You'd need to use the DPI Interface on the RPi which will use up a lot of pins, but if you can still find a way to connect everything else you use, the parallel interface is much faster than SPI and you shouldn't have any frame rate issues. It's also plumbed right into the GPU on the SoC so it should have less overhead. 480x272 is the same resolution as the PSP I'm pretty sure, and I'm pretty sure can show things like the SNES without any scaling, but not 100% on that so double check me there. I haven't poked into the datasheet but if it lets you use RGB565 that'll save you some pins, and that would still be 65k colors. SPI clock on the RPi appears to be limited to 3.6MHz if you're running from 5V and 1MHz if you're running at 3.3V. That gives you a best case bit rate of 3.6 Mbit/s without overclocking it (and not accounting for any protocol overhead), which won't go far for raw video data. USB 1.0 Full Speed data rate is 12 Mbit/s as a comparison. In other words, you pretty much need to use that optimized driver that sends the delta per frame to get reasonable performance from SPI and you'd still be limited probably to 320x240.
|
|
#
¿
Nov 15, 2020 00:26
|
|
|
Has Analogue's portable actually been shipped to anyone or tested by blogs or anything? I'm curious what the battery life is like because in general, FPGAs are considerably more power hungry than general purpose CPUs. Very cool though and has the advantage of being a high quality build by people who know what they're doing. Re LM386, nice work! I think you may know this but the LM386 at this point is ancient and a good learning tool and quick and dirty fix when you want to test something on a bench, but there are much better options out there now. Also, the breadboard is great for prototyping but isn't really a good test for signal to noise ratio and distortion. You essentially have antennas hanging all over the place there and the breadboard connections have very high parasitic capacitance. The antennas will introduce noise and the capacitance will smear out your nice sharp digital transitions for a signal like PWM. Not sure if it makes a huge difference at audio frequencies, but I wouldn't be surprised if you could hear the difference easily. Not sure what you're thinking, but I'd get one of the new fangled class D amplifier ICs made by e.g. Texas Instruments. They'll have all the filtering and such inside and just by the nature of being tiny should be more resistant to noise. They're also WAY more efficient than the LM386 and should help your battery life quite a bit and also be able to go considerably louder. They make a ton of them and other manufacturers besides TI make them too. I've messed with the cheapo modules you can easily find on eBay and they work quite well, but they want an actual audio signal as input. Not sure if you can find them as easily as modules, but from a quick search, there are definitely chips that can take an I2S signal as input (the one that came up that I looked at is the TAS5760L), which means you wouldn't have to go all analog engineer to keep your signal from getting noisy. If you just put the amplifier physically near the speaker it'll probably be pretty low noise. Hell, these things are so popular you can buy them from Parts Express (though I wouldn't because they're the same low buck Chinese boards you find on eBay but marked up).
|
|
#
¿
Nov 16, 2020 21:35
|
|
|
Cory Parsnipson posted:By "actual audio signal" do you mean an analog signal? Yep, apologies for being imprecise there, but that's what I mean. The modules I've personally used have all used analog audio signals, L/R/Common for input. The premade modules are super easy to use, the chip itself might be more complicated to work into a design though. A company like TI will tell you everything you need to know though and will have reference designs (which is what the cheap eBay modules are executions of). At the very least you can use a module pretty much like you'd use an LM386 and just get better efficiency, although I'm not sure how much impact that will have in terms of battery life at the relatively low powers you need.
|
|
#
¿
Nov 17, 2020 17:56
|
|
|
Also China's got your back homie. It does kinda suck that you can't get everything in a nice breadboard friendly package anymore but on the other hand there are things like the ESP8266/ESP32 that are unbelievably capable for next to nothing and they put tons of stuff on breakout boards that you can get on eBay for next to nothing now that kind of fill in the gap for no DIP packages of the actual ICs. Something like the "blue pill" stm32f103 board absolutely crushes the giant 40-pin PIC's we used to make robots in high school and is like $2-3 ea on eBay, less than the PICs cost. They're even passing on the cheap manufacture aspect of surface mount these days, they're happy to stuff the board for you and it's actually not even that much money if you stick to the list of parts that they keep stocked. You can order prototype boards for literally a couple bucks and have the option to get the solder stencil so you can squeegee on the paste, plop the parts down, and then pop it onto a hot plate to solder everything as long as you keep everything mostly on one side. The PCB fabs will make boards stupidly cheap for smaller board sizes too and you start to realize "oh yeah, this is why everyone uses surface mount" when you can get 250 pieces of a gumstick sized PCB for $30 at your door. Embrace it man! I think it's a golden age for electronics hobbyists 
|
|
#
¿
Nov 26, 2020 16:46
|
|
|
|
| # ¿ May 15, 2024 23:27 |
|
|
Yeah, you have pull-down resistors there and they'll work as you described. The two pins that are always connected are common (the wiring inside looks like an H where the middle bar is a switch) so that wiring is a bit confusing because you have to know how the switch looks inside to know that, but is electrically valid. Do you mean you have the pull-up resistors in the MCU turned on as well and they're fighting with the the pull down? That would make a voltage divider so technically when the switch is open it would be somewhere between ground and Vcc but if the resistor values are far apart that might not be apparent. When closed, there's no resistance to Vcc so it'll win or destroy something trying (ie: don't press a button if the pin happens to be set to output mode and low).
|
|
#
¿
Dec 18, 2020 23:30
|
|