[HN Gopher] Unihiker, an $80 single-board PC with 2.8" touchscre...
___________________________________________________________________
Unihiker, an $80 single-board PC with 2.8" touchscreen, quad-core
ARM Cortex-A35
Author : nathanasmith
Score : 287 points
Date : 2023-06-15 14:48 UTC (8 hours ago)
(HTM) web link (www.unihiker.com)
(TXT) w3m dump (www.unihiker.com)
| Animats wrote:
| _" The built-in IoT service on UNIHIKER allows users to store
| data through the MQTT protocol and provides real-time data access
| via web browser."_
|
| That reads as "comes with integrated backdoor you may not want."
| It may or may not be any good from a security standpoint, but
| it's a risk.
|
| > This is designed as an embeddable component for learning,
| prototyping, and OEMs.
|
| It's trying to be a lot of things at once. It has connectors on
| all four sides and no screw holes for mounting, which is a
| headache when you need to build it into something. That layout
| started with Arduino, continued into Raspberry Pi, and continues
| to be a headache. It's fine for desktop prototyping, not good for
| deployment.
|
| Note how vague the site gets when they talk about applications.
| sbierwagen wrote:
| >It has connectors on all four sides and no screw holes for
| mounting
|
| There's three nuts soldered on the back:
| https://www.unihiker.com/wiki/dimension
|
| >That layout started with Arduino, continued into Raspberry Pi
|
| Pre-2010 Arduino boards had three 1/8 inch mounting holes,
| post-2010 ones had four:
| https://blog.adafruit.com/2011/02/28/arduino-hole-dimensions...
|
| The Raspberry Pi 1 had two mounting holes located in stupid
| places, but the Pi 4 has four: https://www.robot-
| advance.com/userfiles/www.robot-advance.co...
|
| >Note how vague the site gets when they talk about
| applications.
|
| It's a DFRobot product. I used to work for a company that
| distributed DFRobot products in the US, and this is broadly
| consistent with their corporate philosophy. Their designers
| crank out _thousands_ of products to keep ahead of other
| Shenzen companies who are fast-following them. (Notably
| Seeedstudio) You can view their full catalog here, and it 's
| quite the sight to see:
| https://www.dfrobot.com/category-48.html
|
| They generally take the OEM reference design, put it on a pcb,
| and add connectors. The API will be minimal. Compatibility is a
| joke. (For instance, they make no effort to avoid I2C address
| collisions-- how could they, when most of them are hard-coded
| by the device vendor, and they only make the PCB? You have to
| be careful when stacking several different Arduino shields,
| since they'll very often be talking on the same pins. There
| will be no warning of this on the product page, of course, so
| the end user must carefully examine the board schematic. Etc
| etc etc.)
|
| When I was working with them, I had the impression there were
| maybe three people who spoke English at the company, and they
| spent most of their time writing product pages. Email support
| was hopeless, and their forums were the usual mess.
|
| DFRobot products are best thought of as a convenient way to get
| a sensor or microprocessor without having to design and reflow
| your PCB. If you don't like reading manufacturer datasheets,
| then you won't like DFRobot. They're not legos, and they're far
| from the kind of integrated product family you'd expect from a
| US company.
|
| The unihiker.com webpage has a California startup website
| aesthetic, so you might expect a small company built to support
| this one board, but DFRobot literally has dozens of SBCs just
| like this: https://www.dfrobot.com/category-184.html I would be
| surprised if they even have one person dedicated to this
| product. An easy guess is they're already moving on to the next
| board launch, with yet another small ARM chip from another
| vendor.
| Animats wrote:
| > There's three nuts soldered on the back:
| https://www.unihiker.com/wiki/dimension
|
| Oh, is that what those round things are. From the picture it
| looks like they're big pins.
| FlyingSnake wrote:
| Sigh... one more device to buy and put in my shelf with
| RaspberryPis, Arduinos, eInk devices and ESP32s.
| hawski wrote:
| So do not buy it.
|
| Sell the stuff you are not using. It is ok to leave one thing
| that you wish to tinker with in the future, but it is not
| advised. While we're at it, a clean up of files on your
| computer is also way overdue. I should not mention hundreds of
| opened tabs in your browser.
| GrumpyNl wrote:
| You missed the pine64, great choice.
| ethanpil wrote:
| I love to see one of these come with the ability to fit into a
| gang box on the wall... to use in a place where one would usually
| have light switches, etc.
| deeesstoronto wrote:
| Have you looked at the Sonoff nspanel?
| Matsta wrote:
| This is a good idea. You don't want to have a full-on Linux
| distro controlling your lights. You want something you can
| set up and forget.
|
| You will feel a world of pain when there is some bug, and it
| will take you 8 hours to figure out the issues so that you
| can turn your lights on. The simplier, the better for these
| kinds of applications.
| sosodev wrote:
| Are you able to run your own software on that? It looks fully
| integrated to me
| vardump wrote:
| Bluetooth 4.0, insecure enough that they might as well omitted it
| entirely.
|
| Only 512 MB RAM is a bit limiting in 2023.
| 908B64B197 wrote:
| So, like all other "raspberry pi killers" this is running a
| patched kernel released by some company in Shenzhen with no plan
| to upstream changes or get them into the main kernel tree.
|
| E-Waste in less than three years!
| MartijnBraam wrote:
| Looks like it's based around the Rockchip RK3308 so it's likely
| not that bad. I'm sure this ships with some old patched vendor
| kernel but the SoC is already supported in mainline.
|
| I've not gone through the other components but this probably
| doesn't take too much time to get to full mainline linux
| support.
| BlackLotus89 wrote:
| I remember a few sites that had arm soc comparison lists. This
| would check none of my boxes...
|
| Basically I'm looking for
|
| 1) a homeserver board with low energy consumption, m.2/sata,
| maybe a usb3 port and fast ethernet
|
| 2) a lightweight desktop with hdmi/dp, usb c, m.2 and good
| software support (media codecs anyone?)
|
| 3) something cheap for projects the "cheap" pis, esp32 and so on
| are my go to option
|
| For 1) and 2) I'm looking at cheap pi4 compute module boards...
| but tbh is the pi4 always short of being good enough
| anaganisk wrote:
| Used Lenovo think center I bought off eBay has, Intel 7th gen
| with vPro, 8GB ram, 256GB nvme, all of that for 76$ including
| shipping, pi can even beat that price.
| BlackLotus89 wrote:
| One of the rhings I would like are arm or risc v, but tbh if
| the power consumption is around pi level it is tempting
| progman32 wrote:
| What's the power consumption like?
| WhereIsTheTruth wrote:
| Is it open source? Can't find that information on the website
| xwdv wrote:
| I've become very cynical of these types of tiny computer
| products. These computers are like puppies that tech nerds will
| gush over and buy impulsively, do a couple small things with,
| then never use again.
|
| It seems like the smaller it is, the crazier people get.
| darkwater wrote:
| Unrelated but trying the HN wisdom here: any suggestion for a
| cheap touchscreen with a CPU attached and a battery that can be
| used as a control panel for Home Assistant? Yeah, probably some
| Android tablet but something that actually works well for this
| job and costs as less as possible? I cannot power it properly
| where I want to put it so it needs battery and then I can charge
| it as needed. Suggestions?
| youngtaff wrote:
| Something like a SenseCap from Seeed Studio?
|
| https://www.seeedstudio.com/SenseCAP-Indicator-D1S-p-5645.ht...
| doctorpangloss wrote:
| You can find used iOS devices that run iOS 15, and therefore
| modern safari, for like $80.
| Matsta wrote:
| Agree with this. You want something with the least headaches
| as possible. You should be able to run the the Home Assistant
| App as well.
|
| If you get a old iPhone and buy a replacement battery still
| more than likely be cheaper than buying a Rpi + screen +
| lipo-hat + battery.
| yjftsjthsd-h wrote:
| Does it even need to be a current version? If it's _only_
| used to access the web interface of a local device that you
| trust, I 've wondered if you couldn't get away with an even
| older device/OS/browser. The only problem I can think of is
| if ex. HA ships an update that uses newer browser features,
| and even that wouldn't be a problem if you did the dashboard
| custom.
| anigbrowl wrote:
| m5stack.com
| HeyLaughingBoy wrote:
| I _love_ M5Stack and in fact just shipped my first project
| with an M5 Tough. However, those screens are tiny. Even 3 "
| would be a huge improvement.
| anigbrowl wrote:
| True that. They do have a phone-size e-reader device which
| is great, but obviously is subject to the limitations of
| e-ink. I suggest reaching out to them, they're _very_
| responsive on Twitter and @lovyan3 has developed a
| universal graphics library for the ESP32 stack and works
| closely with them.
| HeyLaughingBoy wrote:
| I just got a couple of ESP32-S3 devices direct from China
| (AliExpress), one with a 5" TFT screen and the other with a 7".
|
| I don't know what home assistant is, but these will run C++ or
| MicroPython just fine. My application is an industrial
| controller and they are really nice. Dirt cheap at around $30
| each shipped (arrived in just over 2 weeks) to USA.
|
| [edit] They have very little I/O since the display is driven in
| parallel mode and that takes up most of the EPS32 pins. There's
| a SPI connector and a couple other pins that could probably be
| redirected for I2C. I haven't gotten around to to checking
| that. I did use one of the available pins for serial input to
| read a GPS module and that was trivial to setup though.
| nick__m wrote:
| I use an stm32f103 as an io extender for my esp32-a1s, they
| cost about 2$ per board and the chip programmer cost about
| 10$. I use I2C to communicate between the esp32 and the
| stm32.
|
| I do my development in VSCode using platformio with the
| Arduino framework and FreeRTOS. It is really convenient to
| have the same os and framework used for all the MCUs of a
| project. That's why I use the 2$ stm32 instead of a 1$ stm8.
| lbotos wrote:
| I mean, You are spot on -- A cheap android tablet sounds like
| the fastest/best/most aesthetically pleasing option. Otherwise
| Waveshare screen + some PI board is the "easy hacker-aesthetic
| way"
| thesh4d0w wrote:
| Kindle tablets with fully Kiosk browser.
| regularfry wrote:
| You'd be able to strap something together with a Pimoroni
| Hyperpixel and a raspberry pi with a lipo hat, if that was a
| direction you wanted to go in. It's a very nice little screen.
| No idea about how power efficient it is, though.
| ck2 wrote:
| Um, it looks like a $20 android phone without the case or
| battery?
| janoc wrote:
| Because that's pretty much what it is.
| Hexigonz wrote:
| I'm sorry this is off topic, but I love the homepage design. Have
| too many rPIs to justify buying this, but something about a nice,
| light, internet blue, simplistic design really makes me happy.
| Too many sites with their dark mode BS trying to be super serious
| and deep toned today.
| CodeWriter23 wrote:
| Makes the cards pop really nicely
| theamk wrote:
| My usual question for small cheap boards is: what will happen to
| OS support in 3 years? Is it using regular distro or is this a
| custom fork which will likely be never updated? The website says:
|
| > The UNIHIKER comes with a Linux operating system based on
| Debian and various built-in features, which will be upgraded from
| time to time.
|
| ... don't expect OS upgrades here. If you want to play with it
| for a while then put it away forever, go ahead and do it; but if
| you want to build something long-term, better find a different
| board.
| squarefoot wrote:
| In my opinion the vendor supplied OS distros are to be taken as
| just a starting point, nothing to rely on more than the time
| needed for the port of one of the well established distros
| (Armbian, DietPI, stock, etc) to appear for a given board,
| which often happens quite fast when driver blobs and lack of
| documentation don't get in the way (the RK3308 used here is
| well supported along the WiFi chip). My usual approach when
| looking for a board is to check first if there's some support
| from the above distros, or wait. It may seem odd, but it's just
| the same reasoning we're used to in the PC world translated to
| the embedded world: whoever would expect Gigabyte, Asus, etc.
| to create and supply the Linux distribution that runs on their
| PC mainboard?
| thanatos519 wrote:
| It's not just small cheap boards. It's small expensive
| computers, too: I was burned just like this with the Sony VAIO
| 720P and the PlanetComputers Gemini PDA. Awesome hardware,
| pretty good drivers for the current kernel/distro, and then ...
| nothing.
| reaperducer wrote:
| _If you want to play with it for a while then put it away
| forever, go ahead and do it; but if you want to build something
| long-term, better find a different board._
|
| I think it depends on what you want to do with it.
|
| If you're building something that won't access the network, or
| will be isolated to the LAN, then it's fine.
|
| Not everything needs or wants to be connected to the internet.
| rostakagmfun wrote:
| Slightly unrelated, but I wonder what is a preferred OS for
| similar boards: a buildroot or yocto -based system vs a full-
| blown Debian-based distribution with desktop and package
| managers?
|
| When I looked into (now deprecated) Jetson Nano I was surprised
| to find out there was no straightforward and documented way to
| build your own system and cross-compile for it. Is that because
| for many people using SBCs means doing everything on the target
| (e.g. compiling software), or am I missing something?
| Eisenstein wrote:
| Armbian or DietPi.
| CoastalCoder wrote:
| I've never done a project using a board like this, so out of
| ignorance:
|
| Does LTS support usually matter, if you're using the device for
| a stand-alone application such as a lighting controller or
| front-door camera?
| idiotsecant wrote:
| depends on whether you care about vulnerabilities or not, I
| suppose. Presumably that lighting controller talks to
| something. If it talks to a local network only and it's
| impossible for external traffic to reach it, maybe not such a
| big deal. If that's not true it might be significant. That's
| also true of all IoT junk anyhow, it's all running some linux
| variant under the hood and security / updating is rarely a
| major concern.
| CoastalCoder wrote:
| That's what I was thinking.
|
| I was assuming that e.g. the lighting controller would only
| have 3 modes of access enabled:
|
| (1) USB commections
|
| (2) wired ethernet during admin
|
| (3) ZWave via a USB adapter
| yjftsjthsd-h wrote:
| This is actually one of the reasons I like
| bluetooth/zigbee/z-wave/IR/etc. so much - it puts a
| significant barrier to attacking devices even if they
| don't get patches. Of course, you still _should_ pay
| attention to security and update them if possible because
| local and /or proxied attacks are still a thing, but it's
| much less likely to get hit.
| [deleted]
| oneplane wrote:
| It's dead on arrival; currently runs Debian 10 with custom
| patches and binary blobs. It's an RK3308 so not entirely
| impossible to run on a normal distro, but you'd have to bring
| your own firmware and device tree etc.
| anigbrowl wrote:
| This is designed as an embeddable component for learning,
| prototyping, and OEMs. A lot of people here are just sniffily
| dismissing it as 'DOA' when what they mean is 'I would not
| want to maintain this.'
| ilyt wrote:
| Dude, Debian 10 goes out of support in a year. Debian 12
| already released.
|
| It's 4 years out of date at release, why would you want
| that for "learning and prototyping", let alone start a OEM
| device with soon unsupported software versions.
| oneplane wrote:
| No, it's DOA. Embeddable components need support too. As do
| OEMs and prototyping scenarios.
|
| It is presented as a viable commercial product, but it
| actually is an old SoC with no ecosystem. If anything, it
| teaches people not to use this type of thing.
|
| The only way it would not be e-waste is if it had a future,
| and it doesn't and that's why it's bad. At this price point
| there are so many community and commercial alternatives
| that do have an ecosystem and support it's just pointless
| and most likely an attempt to dump overstocked Rockchip
| parts. Even an ancient i.MX 6 is a better choice.
| snarfy wrote:
| Why does it need continuous, perpetual support? Most devices
| like this get built, software installed, and never updated
| again. When is the last time you updated the ECU software in
| your car? I built a small arcade cabinet using an old raspberry
| pi 2b. Once I built it I've never needed to upgrade anything on
| it. It works fine and plays all the old games. I have backups
| of the SD card in case anything craps out.
| ilyt wrote:
| If it is not connected to the internet in any way, sure.
|
| But we got of TVs that are now useless because originally
| they just needed to "display a simple web page" but:
|
| * no new TLS support, near-everything dropped old TLS
|
| * sites that did not, use CA that's not on the device's list
| scheeseman486 wrote:
| If there's a vulnerability in any of the software or firmware
| that connects and interfaces with anything over a network,
| there's the possibility of something worming it's way in or
| out of it.
|
| For something intermittently used like a game box that might
| not matter. For IoT-focused hardware that is connected to the
| internet continuously by design where, say, a malformed TCP
| packet could cause a buffer overflow in the network stack
| that wiggles it's way into root code execution by chaining
| through a bunch of unpatched vulnerabilities on a "never
| updated again" system? That's a problem.
| kristopolous wrote:
| Network updates are an amazing trainwreck.
|
| No matter how elegant you seem to be, you'll always be
| running like half a dozen versions in the wild.
|
| For any large deployment that kind of work will be on your
| shoulders anyways. Stuffing in security updates or whatever
| to that isn't crazy
|
| Unless you're saying you want multichannel overlapping
| upgrade schedules where you have some NxM cadence matrix to
| test and support (as in ssh x+/-{1,2,3} AND your software
| x+/-{1,2,3} etc).
|
| I've had to make and manage automated test rigs for those
| types of deployment as well.
|
| That's an entire room full of whatever machines your
| deploying and a full time job.
|
| Anyways, this stuff is hard for the out in the wild
| devices. Putting security updates in a monolithic release
| package is really the easier way to go and at that point
| it's on you.
| dotnet00 wrote:
| If it can connect to the internet, it will need security
| updates.
| RobotToaster wrote:
| Won't the firewall on most domestic routers stop any
| incoming connections?
| ianburrell wrote:
| Connections are only part of the danger. Browsers need to
| access the internet and they can have security bugs.
| Also, people download files and the programs that process
| them have bugs. People download programs and those can be
| dangerous.
|
| For the kernel, it is important that it protect against
| dangerous programs running on the system to keep them
| isolated.
| ilyt wrote:
| It will also need update of CA lists, and if any
| vulnerability will be found in TLS1.3 it will need to
| update SSL libs to even _access_ anythign
| piyh wrote:
| In most cases, yes, in all cases, no. There's a lot of
| variants of "enumerate all devices on a private network
| if you visit a malicious webpage" exploits.
|
| https://medium.com/@brannondorsey/attacking-private-
| networks...
| kyberias wrote:
| Why would a connection to internet need security updates?
| bee_rider wrote:
| This question doesn't really make sense, did you forget a
| couple words?
| gizmo686 wrote:
| Because as an industry, we are bad at our jobs. The
| network facing software has critical security
| vulnerabilities. Even security folks accept that as the
| way of the world.
|
| At the point the software is released it has (hopefully)
| no known security vulnerabilities, which is a reasonably
| secure situation to be in.
|
| However, eventually some of them will become known, and
| that is not safe.
| VyseofArcadia wrote:
| But a "critical security vulnerability " depends on the
| use. My daily driver? Yes, I want all of the security
| updates. A raspberry pi for playing arcade games that I
| occasionally scp a ROM over to? I really don't care if
| someone hacks in.
|
| We, as an industry, are bad about pushing "every device
| that is on the internet needs to be as up to date as
| possible all the time" when it reality there is a lot of
| unimportant stuff on the internet.
|
| It's like locks. I wouldn't secure my house with a bike
| lock, but it's fine for my bike. My bike is less full of
| important stuff.
| dotnet00 wrote:
| Well, a common thing with open computing resources these
| days is cryptominers. Sure, you don't care about updates,
| until someone puts a miner on it and you have to go in
| and try to fix it. It wouldn't matter that your single
| device doesn't have enough processing power when there
| are tens of thousands of similarly vulnerable devices to
| hijack.
| yjftsjthsd-h wrote:
| > I really don't care if someone hacks in.
|
| At _best_ , that means you're externalizing the costs,
| i.e. now your device is part of a botnet and becomes a
| problem for other people. But of course that assumes that
| it doesn't become a problem for you as well; a
| compromised device on your network is a great launching
| point for local attacks and a way to send illegal traffic
| out through your internet connection.
| reaperducer wrote:
| People like to shout "cryptobotnet!" every time someone
| questions the need for absolute security with devices
| connected to the internet.
|
| You _might_ get 2C/ in about 40 years mining with my IoT
| light bulb. Good luck with that.
| elabajaba wrote:
| If it has a camera, it can be used to steal your security
| keys if it can see the power LED on your device (or
| potentially even just if something connected to your
| device has a power LED).
|
| https://www.nassiben.com/video-based-crypta
| reaperducer wrote:
| Fortunately, none of my computers have power LEDs. Also,
| I don't live in a nuclear weapons facility where I need
| "security keys."
| margalabargala wrote:
| There are plenty of reasons not to want your IOT bulb to
| be insecure that are unrelated to people mining crypto.
|
| A pwned IOT lightbulb can be used to help DDOS sites. It
| can relay DDOS traffic, eating your own bandwidth. It can
| be constantly probing the other devices on your network
| looking for vulnerabilities, until it pwns something else
| and is able to slurp down your passwords and credit card
| numbers.
|
| Are you seriously suggesting that having an actively
| malicious computing device inside your home network is no
| big deal?
| TheMode wrote:
| All software have many dependencies (IMO for very wrong
| reason), if you can find a way to build a static system where
| nothing need to be updated good for you, but I doubt that
| this is the majority of use-case.
|
| Will this device be able to load any web page in one or two
| decades? It would likely be slow, but the impossibility would
| be a pure software limitation.
| dmitrygr wrote:
| > Why does it need continuous, perpetual support?
|
| Because there are no schematics or data sheets posted on that
| page. Good luck bring up anything else on it...
| imtringued wrote:
| Because that is the nature of these SBCs. They aren't some
| generic queryable platform running UEFI. Instead you have a
| bespoke OS fork for each individual board. This means that
| vendors need to give a lot of attention to the software
| because there isn't a foundation or company taking care of
| all SBCs at once. The device becomes obsolete very quickly if
| you can't install recent software. SBC performance hasn't
| increased much. There are still plenty of boards with A53
| cores that have been used for more than a decade.
| ianburrell wrote:
| First, this advertises this as a PC which have longer
| lifetime and higher security requirements than embedded.
|
| Second, embedded systems have reliability requirements.
| Something will not work and will need support and updating to
| fix. The big advantage of normal distribution is that
| somebody has probably already fixed it.
|
| Third, devices get repurposed. My five year old Raspberry Pi
| has had multiple jobs, and when it is done running Home
| Assistant, I'll find some other use. Plus, with normal
| distribution, I can easily install the packages I need.
| theamk wrote:
| Few years ago, you built your arcade cabinet, and decided to
| put some nice launcher like RetroPie. It works fine for a few
| years, and then your friends tell you about Pico8 support..
| nice, it is supported by RetroPie release! not nice: retropie
| requires ubuntu 18.04 or later.. let's hope your device
| supports it.
|
| Few years ago, you built a weather station. Sadly, the
| weather backend you had was discontinued. You found a great
| new one, and it even comes with SDK and sample code! Sadly,
| the SDK requires python 3.8 or later. Does your device
| support it?
|
| Few years ago, you built the home automation server. But
| recently, you got the set of remotely-controllable disco
| balls for each room which use FOOBAR protocol. Good news:
| Linux kernel supports FOOBAR protocol since 5.14. Bad news:
| your device kernel is much older.
|
| Few years ago, you built the smart controller. You don't want
| to manage your infra, so you decided to go with AWS IOT, it
| is super each if you only have a few devices. But AWS
| announced they are dropping AWS IOT.. does your OS support
| newer system?
|
| There are definitely cases when you set up the device once
| and never have to touch it again, but there are also a lot of
| networked things out there, and you often want to control
| them..
| snowAbstraction wrote:
| Some boards have decent support. I've got an odroid C1
| released in 2015 and I saw there is at least an Ubuntu 20
| image for it!
| Dnguyen wrote:
| I wish the RAM could be a bit more, at least 1G or 2G, so I can
| have a database on there without having to ship my data to the
| cloud. Then the system can really run isolated as much as
| possible, for security and privacy.
| wongarsu wrote:
| SQLite would still be a good option. It's incredibly
| lightweight, and if you set the database to WAL mode it also
| works well for a database file accessed by multiple
| applications on the same device.
| Narishma wrote:
| It has 16GB of flash. Can't you put your database there?
| lostgame wrote:
| This. Back in the day when we lacked RAM, especially on *nix
| based systems, it's absolutely normal to use the disk/flash
| as pseudo-RAM. This was just...a normal part of computing at
| the time, heh.
|
| Of course, applications would respond shit slow this way, but
| in the case of a DB it'd be more than fine, no?
| amelius wrote:
| Since when is _less_ modularity a good thing?
| CobrastanJorji wrote:
| To nit pick on the website itself, the caption "Black and white,
| it's colorful" is a terrible way to convey information.
| dmitrygr wrote:
| The "documentation" page is a joke. I cannot eve find if the
| touch screen is resistive or capacitive. I see no schematics,
| making bring up if your own OS in it unlikely. I see no data
| sheets either. Just another piece of e-trash waiting to end up on
| a landfill..
| ytjohn wrote:
| Nothing special, it's touchable.
| samstave wrote:
| [flagged]
| anigbrowl wrote:
| Please get treatment. Just because a thing can be used that way
| doesn't mean that's its sole valid purpose. You are like a
| person looking at a metal tube and yelling that a mass shooting
| is imminent.
| samstave wrote:
| [flagged]
| samstave wrote:
| [flagged]
| anaganisk wrote:
| Ugh, u may not like the following but the devices you are using
| to get on the internet, are used to collect a treasure trove of
| information, to conduct information warfare. And regardless of
| whatever your bullshit political specrum is.... this is a
| platform for stalking, propaganda, tracking and killing Human
| Beings.
|
| Period.
|
| Street Cred: I have common sense.
|
| There is only one outcome: Defense spending, Military Death.
| jedberg wrote:
| This seems like a somewhat related place to ask this: Does anyone
| know where I can get a 3" _round_ screen?
|
| I have a Star Wars clock from the 1970s that has a ton of empty
| space in the base. I want to put a small computer in it and
| replace the 3" clock face with a round screen, so it can show the
| time and maybe some fun Star Wars animations.
|
| But I just don't know how to find a 3" round screen without
| buying 1000 of them from China.
|
| How do I get just one 3" screen that I can attach to a Raspberry
| Pi or equivalent linux computer?
| joshmarinacci wrote:
| I think Waveshare has some. I've been messing with their 1.28
| in round ones and I like it. Just be aware that they will use
| SPI (think Arduino level) for the connection, not something
| video oriented like HDMI. Thus they can be used on a Raspberry
| Pi with a custom driver, but you won't be getting 60fps.
| HeyLaughingBoy wrote:
| LilyGo has an ESP32 with an attached round TFT screen that's (I
| think) 2.8" diameter. You can buy single units on Amazon.
|
| One of the demo applications is a clock, but it shouldn't be
| difficult to load a bitmap.
| jedberg wrote:
| Looks like it's 2.1", but thanks for the tip!
| gadgetoid wrote:
| Our (Pi compatible) HyperPixel Round is just shy of 3" if you
| count the thick, black border around the edges. Actual screen
| is 2.1" but diameter is 71.8mm.
| jedberg wrote:
| Ok wait, so when it says 2.1" that doesn't include the bezel?
| So the problem all along has been me reading it wrong? Thank
| you!
| gadgetoid wrote:
| Bear in mind I'm just reading the product page specs here
| but if you want me to measure mine I can dig it up!
| Tepix wrote:
| This device is similar to many hacker festival badges from the
| recent years. Just a bit more expensive.
|
| For example:
|
| - the Camp 2023 flow3r badge
| https://events.ccc.de/2023/06/05/camp23-the-flow3r-badge/
|
| - the MCH2022 badge https://wiki.mch2022.org/Badge
|
| - the SHA2017 badge with E-Ink
| https://wiki.sha2017.org/w/Projects:Badge
|
| - the Camp 2011 badge R0ket
| https://events.ccc.de/camp/2011/wiki/R0ket
|
| The first three have ESP32 CPUs, not sure how it compares to the
| ARM Cortex-A35
| dmayle wrote:
| "If your badge has been hit by ransomware, see how to enter
| Safe mode."
|
| What a world we live in...
| lostgame wrote:
| It was a joke and part of the actual hacker festival.
| solardev wrote:
| Wait till your brain integration gets malware and your
| thoughts are locked away...
| RobotToaster wrote:
| Never gonna give you up
|
| Never gonna let you down....
| dcow wrote:
| I'm pretty sure that was a game/gimmick and part of the
| conference badge challenge. But maybe not. Regardless it is a
| security conference after all and I'd totally expect people
| to be playing around like that. I don't think it would have
| been seen as malicious.
| spicyjpeg wrote:
| The ESP32s belong to a completely different category of
| processors, they are microcontrollers optimized first and
| foremost for cost and power efficiency rather than raw
| performance or the ability to run Linux. The Rockchip SoC used
| here, on the other hand, is more akin to what you would find in
| a cheap Android tablet or set-top box: it has Cortex-A cores, a
| proper GPU and can use far more memory than the mere hundreds
| of kilobytes of SRAM built into ESP32 chips. Of course it also
| requires far more external components and draws significantly
| more power when running at full speed, so it's in no way a
| drop-in replacement for microcontrollers in products where
| Linux is not a hard requirement but BOM cost and battery life
| are.
| shadowpho wrote:
| One small addition...
|
| > they are microcontrollers optimized first and foremost for
| cost and power efficiency
|
| ESP32 is only optimized for cost. Other wireless MCU are
| significantly lower power... they are just more expensive
| (and tend to have worse docs then ESP32).
| lelanthran wrote:
| > ESP32 is only optimized for cost.
|
| Are you sure? I'm plaing around with the deep-sleep mode of
| an ESP32-3C and it appears to sip _almost_ negligible
| current.
| anigbrowl wrote:
| ESP32 is great for low power apps, you can switch off most
| of the chip subsystems, rely on watchdog timers etc.
| steve918 wrote:
| Compared to what?
| __void wrote:
| they are very different, esp32 is an advanced microcontroller
| (with wifi/bt) and is comparable to an arduino on steroids,
| whereas this board uses cortex a35 and is more comparable to a
| raspberry
|
| esp32 has 520 Kb of ram, while this board has 512 Mb!
| StillBored wrote:
| "comparable to a raspberry"
|
| Well, slightly worse, as A35's are smaller and lower power
| than the A53's in something like the pi zero-2, but also
| slower. The devices slight clock advantage probably doesn't
| make up the difference.
|
| So, its probably a great embedded system, but it should be
| running something lighter weight than a normal linux distro.
| Otherwise it becomes like all these gas station pumps, point
| of sale terminals that all seem to take 10+ seconds to do
| things that older devices didn't lag and pause with.
| Gys wrote:
| This thing runs full linux and requires 3.3V, 2000mA (max). A
| badge is probably not the best use case.
| kevin_thibedeau wrote:
| This definitely puts the STM32F429 Discovery board to shame with
| its now inflated $80 price tag.
| LeifCarrotson wrote:
| The STM32F4 is a Cortex-M4 microcontroller. You have direct
| access to optimally do whatever you want with the CubeIDE and
| GCC libraries.
|
| This is a platform, if the things you want to do are possible
| with the entire stack of Debian, the pre-existing touchscreen
| menus, the PinPong Python libraries, etc. then sure, use
| this...but that's a lot of wasted efficiency and a very large
| dependency.
|
| The STM32F4, for example, can be configured to enter deep sleep
| and run for a long time on a battery. This likely cannot.
| dmitrygr wrote:
| That dev board has a schematic and data sheets for all parts.
| This one has a flashy website with no such thing. That's what
| you pay your $80 for
| isoprophlex wrote:
| You flash the OS (okay, admittedly, debian which is nice) onto it
| from windows with some lugubrious .exe
|
| https://www.unihiker.com/wiki/burner
|
| No linux/macos tool available. No thanks.
| squarefoot wrote:
| Holy crap, I totally missed that requirement. This product now
| goes straight in my do-not-buy list. Yes, one could install a
| Windows VM, set up a passthrough USB port and do everything
| from there, but seriously, what's the logic behind requiring
| Windows for a board that runs only Linux?
| lostgame wrote:
| Hah. Way too misread the room, are they serious?
|
| Who even develops Windows-exclusive apps these days, anyway?
| Even the average user these days seems to find it simply
| abhorrent.
|
| It's so simple to create cross-platform applications these
| days, there's literally no excuse.
|
| I can't imagine the thought process that went behind this
| beyond greed and profit, a little mind-numbing.
| WheatMillington wrote:
| Greed and profit? You can't honestly believe these were the
| motivation behind this decision, can you? That is honestly
| your most generous take?
| mynameisvlad wrote:
| Image burning is certainly more involved than your run of the
| mill cross-platform Electron app. It likely uses lower-level
| system calls that might not even be possible in most cross-
| platform frameworks. Additionally, the screenshots make clear
| mention of a driver, something that would _certainly_ be
| different depending on the OS.
|
| You simply assumed there is "no excuse" because you couldn't
| think of one, but you weren't in the room when the decision
| was made, and don't know the reasonings behind it. My blurb
| above could certainly have been one of several reasons
| brought up.
|
| You can choose not to agree with the decision, that's fine,
| but you're attributing a whole lot of malice to what is
| ultimately a decision they made based on factors which you
| are not privy to.
| lelanthran wrote:
| > It likely uses lower-level system calls that might not
| even be possible in most cross-platform frameworks.
|
| So? I made a Qt-based low-level flashing utility at a
| previous job. Or do you consider C++ callign C functions
| not low-level enough?
| mynameisvlad wrote:
| I mean, my "so" was quite clearly outlined.
|
| > You simply assumed there is "no excuse" because you
| couldn't think of one, but you weren't in the room when
| the decision was made, and don't know the reasonings
| behind it. My blurb above could certainly have been one
| of several reasons brought up.
|
| Just because you did it doesn't mean everyone knows how
| to do it. And that was my entire point.
|
| Maybe you should offer your services to them.
| wepple wrote:
| Lugubrious: adjective
|
| looking or sounding sad and dismal.
|
| "his face looked even more lugubrious than usual"
| markstos wrote:
| The video says "No coding skills? No worries. Just write your
| code with ChatGPT."
| ape4 wrote:
| Hey ChatGPT, hire me a programmer
| Retr0id wrote:
| I'm incredibly curious what the experience of trying to write
| code with ChatGPT is like, if you have no prior knowledge.
| Obviously, it's impossible for me (and most others reading
| this) to un-know everything and approach it with fresh eyes.
| Are there any good real-time videos of non-programmers using
| ChatGPT to write code? (seems like the best way to understand
| what it's like)
| joshuakogut wrote:
| Well, it is helpful for learning new frameworks and stuff
| when you already have a grasp of general programming.
| Retr0id wrote:
| Right, but what's it like if you know nothing about
| programming?
| willcipriano wrote:
| Sort of like using Google translate for a language you
| don't speak a word of I'd imagine. "I just said what the
| computer said to say and now the computer/waiter is mad
| at me"
| Ireallyapart wrote:
| [dead]
| idiotsecant wrote:
| I am an engineer, but not a software engineer. I write python
| sometimes to help me do engineer-y things in my domain but I
| am absolutely not very fluent, just enough to get by. chatGPT
| often transforms a frustrating multi-hour stack overflow
| session into a 5 minute query.
|
| The result is definitely not something you'd want to maintain
| and probably has built in inefficiencies and edge cases I
| don't know about but it did it's job, which was to do the
| thing I wanted it to do so I can go on with my work.
| advantager wrote:
| Similar situation here. I usually can hack something
| together in python, but end up spending a couple hours
| reading stack overflow posts, and often meeting with co-
| workers to debug my code. Chat-GPT can often write simple
| code for me and honestly saves some time.
| circuit10 wrote:
| Honestly for tasks it's able to do easily ChatGPT code is
| probably more maintainable because it's more well-
| commented, formatted etc. than code a human would write if
| they're just trying to quickly hack something together
|
| Sometimes I think "you can tell this part of my code was
| generated by ChatGPT because it's actually good, unlike the
| rest of it"
|
| Of course it's likely to make subtle mistakes that are hard
| to debug if you ask it to do anything complicated because
| it can't test its own code (well, I've heard something
| about a code interpreter in the Plus version but I don't
| know how well that works)
| Beached wrote:
| it's hell, I have been trying it for a couple.months, and you
| can't really get anything of note built. it's buggy AF, and
| gets stuck in loops and can't debug itself.
|
| it works ok as a starting point of " I have no freaking clue
| how to approach this" to "ahh I can see how that will work"
| and then you go write your own code with the lead.
| markstos wrote:
| I don't know Rust well and was having trouble the finding the
| docs I needed, so I asked AI for help. Google Bard, I think.
| It had real difficulty producing code that ran and worked.
|
| The problem was that there were breaking API changes across
| versions of the library, but it was just using probabilities
| of method names being correct, and it didn't ask me or tell
| me which version of the library it was targeting, so it was
| just a mismash of incompatible code.
|
| But the code LOOKED good and the AI was confident it was a
| good answer. Overall, it felt like wasted time sifting
| through confidently-wrong answers.
| cooljacob204 wrote:
| Google Bard isn't the best when it comes to writing code in
| my experience. Try GPT, you should get very different
| results.
| NhanH wrote:
| Hard to image OpenAI not at least trying that out, so if we
| haven't heard any thing from them, it's safe to say it
| doesn't work.
| iamflimflam1 wrote:
| I suspect that people would fail at the first hurdle and not
| even be able to run the code.
|
| I also wonder if they'd even know what to ask.
| specproc wrote:
| I've got a colleague who's been doing it with some success.
| Nothing fancy, just a bit of doodling around in Python for
| fun.
|
| He's been leaning heavily on the repl.it Copilot thingy, so
| it's more autocomplete than code blocks. He uses ChatGPT
| for working out error messages.
| Retr0id wrote:
| Reminds me of a (perhaps fake) screenshot of a conversation
| I saw that went:
|
| Person A: I just used AI to make my own website, you're
| gonna be out of a job soon.
|
| Person B: Oh? Let me see it.
|
| Person A: Here it is C:\Users\Bob\Desktop\index.html
| asimovfan wrote:
| You can ask ChatGPT to explain pieces of code.
| djbusby wrote:
| I'm helping another fella who's new to coding, he's using GPT
| to make some code. Most of what it produces won't even
| compile. Building for sensors on an ESP32 platform. BUT! GPT
| will get a good way there, a main with some sub-routines,
| stuff like that. I don't think it's good enough to teach.
|
| If you can already code, then GPT can ramp you up on a new
| project faster, or accelerate and existing project
| anonzzzies wrote:
| It's pretty good depending on what you are doing. With Python
| and JS/TS, the last checkpoint for training datasets really
| matters. These api's for no reason at all to me, rot
| incredibly fast, so the code it generates was valid in
| September 2020, but now it is almost completely incompatible.
|
| I was raised with (80s/90s); never break the public api
| unless you have to and make a migration path if you do; now
| it is 'let's definitely break the public api, with any minor
| version change and just waste everyone's life fixing it, we
| don't care'. And gpt doesn't know this. It usually does make
| up code that's close to correct and relatively easy to fix
| though, but you need to know how to read the docs and not
| panic that actually everything is spitting errors.
|
| If you ask it for C, Java or vanilla js it fares better but
| there you suffer from the memory window; now with 16k tokens,
| we are seeing massive improvements. The api deprecation
| (read; we just throw away or change without warning) issue
| remains and is a huge issue; I cannot even see how they would
| properly fix that in LLMs. They are going to have outdated
| versions in their search space; how do they know to ignore
| them? And next to that there are the hallucinations.
| [deleted]
| cmrdporcupine wrote:
| I am wondering why people seem to think it's so great for
| this. It's fine for I guess boiler plate code construction
| but totally falls over when I give it e.g. complicated Rust
| borrow checker problems. And if you tell it a mistake it's
| made, it just buries itself deeper branching off into spirals
| of more and more incorrent solutions.
|
| To me, it's like a junior developer I have to coach
| constantly.
| Hextinium wrote:
| Link to the pin out of the bottom connector:
|
| https://www.unihiker.com/wiki/board-overview
|
| Looks like a neat board, I could see making expansion modules
| that plug into the bottom and running like a IR blaster or other
| stuff off the SPI/UART bus.
| BeefySwain wrote:
| > The UNIHIKER's pins are compatible with micro:bit
|
| They really bury the lede here, awesome that there is already
| an ecosystem that exists for the edge connector.
| Tepix wrote:
| Hey, that's really cool!
| tmaly wrote:
| Aside from pins, does this mean you can program with this
| MakeCode ?
| DWakefield wrote:
| It's the same connector as on the BBC Micro:bit, right?
| adolph wrote:
| I was thinking the same, and it is!
|
| _Edge Connectors Pin numbers are compatible with
| micro:bit, 19 independent I /O (Support 1 xI2C, 1xUART,
| 2xSPI, 6x12-bit ADC, 5x10-bit PWM)_
|
| https://www.unihiker.com/wiki/specification
|
| _Note: The edge connector on the back has no electrical
| connection._
|
| https://www.unihiker.com/wiki/board-overview
| [deleted]
| LeifCarrotson wrote:
| Where's the schematic?
|
| If I want to program and debug real-time routines in the
| coprocessor, rather than using the built-in userspace drivers,
| how do I do that?
| zihotki wrote:
| Just like with many other RPi "killers" from China - you don't.
| They all suffer from the same issue with software :(
| driggs wrote:
| With "hiker" in the name, I had hoped to see onboard GPS. Nope!
| sbr464 wrote:
| [flagged]
| nashashmi wrote:
| The next iteration of RPi. Finally.
| oneplane wrote:
| As usual, looks good on papier but no ecosystem and the current
| stack that it comes with is dead on arrival.
|
| Boards need to come with mainstream distro support or with an
| ecosystem (or both), otherwise it will just die. And with
| internet connected devices, you can't set-and-forget, so it needs
| to have live support.
|
| Edit: a RockPi S (same SoC) can be had for $35 and a touch LCD
| for $11... Granted, it doesn't come with the same integration and
| headers, and doesn't have a microphone by default, and no RISC-V
| MCU. But the point of integration is a useful product that stays
| useful, and it doesn't if there is no ecosystem.
|
| As for 'adding' mainstream support, it takes quite some effort
| and active ownership. Out of the many rockchip boards and add-ons
| this is the set that made it to some level of standard inclusion:
| http://ftp.debian.org/debian/dists/stable/main/installer-arm...
| ano-ther wrote:
| The bottom connector looks like a BBC micro:bit so there is an
| ecosystem at least on the hardware side
| [deleted]
| CommanderData wrote:
| I purchased a few ARM boards in the past and won't do it again.
| All became e-waste.
|
| Rockchip notably, great hardware on paper. Try developing
| something that needs hardware acceleration and it's a paper
| weight.
|
| It's a common cycle of broken promises to provide drivers by
| manufactures, rinse and repeat. The exception being raspberry
| pi or expressif. Depending on the application.
| sosodev wrote:
| I've had the same experience with non Raspberry Pi boards.
| They've become useless thanks to endlessly broken software
| and zero support. My rpi's have been useful for years and are
| still getting regular updates.
|
| I think I too was drawn in by the performance claims made by
| those other manufacturers. I realized though that raspberry
| pi are very powerful computers. We just take the scale of
| modern computing for granted and our software is the real
| problem.
| Klinky wrote:
| Even Raspberry Pi has struggled with GPU/HW acceleration,
| but at least its distro is maintained & updated.
| sosodev wrote:
| The pi4's GPU at least supports OpenGL ES 3.1 and Vulkan
| 1.2 now. That's decent even if not powerful.
| joshmarinacci wrote:
| Yup. It's RPi or nothing. It's the software that makes
| these valuable, not hardware specs. If I wanted to sell an
| ARM board I'd make it as Pi compatible as possible.
| Eisenstein wrote:
| The problem is that Broadcom won't sell you the chips
| they use so you can't.
| ignoramous wrote:
| > _...just take the scale of modern computing for granted
| and our software is the real problem._
|
| I was thinking how I constantly find myself using GPT and
| Bard to prettify source code. Surely, not the most
| efficient use of compute.
|
| Like some crude Parkinson's Law joke on more proficient
| algorithms.
| ttymck wrote:
| Excuse my ignorance, but what sort of applications benefit
| from hardware acceleration on limited SoC resources?
| sosodev wrote:
| Inferencing neural networks is a big one. It's hard to get
| near real-time performance without it. Depending on the use
| case of course.
| chaxor wrote:
| Why on earth would you run ML on a potato?
| microtherion wrote:
| To give one example, Raspberry Pi are often used to
| control 3D printers and attached webcams, and there are
| ML systems that supervise the webcam feed for evidence of
| a print failure. Being able to run these systems on the
| SBC would be an advantage, but that's typically not
| realistic today.
| bkirkby wrote:
| _inference_ , object detection for one.
| schreiaj wrote:
| What should we run it on if we want to deploy it on
| mobile systems with limited access to network and
| extremely restricted power budgets?
|
| For a hobby project I'm trying to find a solution - Power
| budget for multiple is sub 200w. Need to run inference on
| a lower resolution video stream (or multiple, that be
| nice) to do object detection. Cost is a factor because I
| need to have multiple angles to determine where in
| relation to a mobile platform the target object is. I'm
| looking at the Coral.ai board because RPi like boards
| lack the ability to do ML tasks at reasonable FPS and
| NVidia seems to have abandoned the lower cost side of the
| market since the Jetson Nanos seem to be less and less
| available. (Not that Coral.ai boards are available at
| all...)
| Eisenstein wrote:
| Check out the Luxonis Oak products. I use an Oak-1 Lite
| to do real time 2 stage object detection and recognition
| (~23FPS at 1080P inference on device with two custom
| yolov5n models). With a bit of python and a Pi (or a
| Rock64 or similar) you can get it up and running in a
| day. They also have a decent community and are actively
| developing the API/SDK and hardware.
| schreiaj wrote:
| Thanks, I've got one of their depth cameras that's been
| ok. I didn't realize they'd expanded their line so much.
| Glad to hear about the API/SDK improving, last time I
| mucked with it a year or so ago it seemed like it was
| underdeveloped.
|
| Going to have to dig into the sensors they use - had
| passable luck with non ML tasks using dirt cheap camera
| modules from laptops running at low resolutions right up
| until I started moving the cameras at all and then it
| became a blurry mess because they were so small their
| exposure times were high. (I'm trying to also avoid
| having to put a bunch of illumination near the cameras so
| it doesn't entirely look like a biblically accurate
| angel)
| Eisenstein wrote:
| Well, you can control the camera ISP and they use very
| decent IMX modules, so it really shouldn't an issue like
| it was with the cheapos, as long as you can do the coding
| to your needs.
|
| EDIT:
|
| * https://docs.luxonis.com/projects/api/en/latest/samples
| /Colo...
| oneplane wrote:
| It would probably not run on this potato directly, but on
| an accelerator (be it in-SoC or a separate thing like a
| Google Coral). The management and control of a Coral
| needs to happen on a CPU somewhere, but the actual work
| doesn't involve the CPU much, if at all.
|
| So if you have a thing that has all the data and all the
| work done on an engine elsewhere and you just need to
| have a SoC to turn the thing on and off and get the data
| in and out, that's where a potato-SoC could work. Of
| course, the potato would need good distro support with
| up-to-date kernel, drivers, python, libraries etc. and if
| you're connecting it to the network, best make sure it's
| also getting patched consistently.
|
| So, as far as ML Potatoes go, that's about it. It is a
| totally valid question by the way, even if asked in jest.
| oneplane wrote:
| You're actually answering your own question here ;-)
|
| Because a SoC with limited CPU-core resources can't do
| everything in software, the chip contains many system
| components (hence System-on-Chip or System-on-a-Chip) that
| handle things the CPU cores then no longer need to do.
|
| Think protocol handling or memory; instead of spending many
| clock cycles on handling the USB bus, you can leave that to
| the USB controller and only deal with what is actually
| relevant to your USB device. Same with the VOP (Video
| Output Processor) block, instead of spending many clock
| cycles on putting the right bits in the frame buffer you
| tell the VOP that you'd like the background to be orange
| and then only spend time setting the right bits for black
| text (for example). So instead of having to deal with many
| millions of bits, you only have to deal with less than 1%
| of them because every bit you don't set becomes orange. For
| other things like I2C, I2S, DMA, networking, cryptography,
| SD-IO, GPIO, PWM etc. the same applies. Instead of
| constantly spending time setting the right bit at the right
| time many times each second, you just tell a dedicated
| block on the SoC to do a thing in a certain pattern and it
| will do it for you, consuming on CPU core resources.
|
| This also allows slow CPU cores that wouldn't be able to
| decode video in real time to offload the entire decoding to
| a video decoder block, and then tell the GPU part of the
| SoC that you're drawing a green rectangle somewhere and
| that's where it has to put the decoded video frames. Why
| would one do all of this? Because it's cheap and power-
| efficient, and that's how you make a big pile of money.
|
| I have no idea how accurate or up-to-date this PDF is, but
| it should at least give you some idea as to what a SoC can
| do without bogging down the CPU cores: https://dl.radxa.com
| /rockpis/docs/hw/datasheets/Rockchip%20R... Check chapter 9
| for example, all of those boxes are things you don't have
| to spend CPU cycles on. If you did use the CPU, it would be
| super slow.
| jancsika wrote:
| Is this in the purview of the panfrost driver stack?
| oneplane wrote:
| I think that's only for ARM's own GPU IP, not for the VOP
| (it's more of a LCD driver than an actual GPU -- I'd
| compare the VOP to say, GameBoy-color level of graphics
| capabilities, which is cool but not even close to a bare-
| bones VESA or UEFI framebuffer).
| gadgetoid wrote:
| I'm still trying to get a Rock 5B to boot from NVMe. By all
| appearances they included a USB Type-C port that doesn't
| work, so the system never pulls sufficient power not to boot
| loop. Apparently even after a firmware update.
|
| To be totally fair to the up-and-coming boards, the Pi was
| pretty poorly supported on day 1 and the community did (and
| still does) a lot of heavy lifting. I'm still waiting for a
| contender, but I don't have the time or energy to devote to
| another SBC.
|
| Despite being a super prolific maintainer of Pi-stuff and
| related projects I haven't had a single SBC manufacturer
| reach out to me and say "hey what do you need to support
| this?" They just don't seem to care beyond shoving product
| out the door and hoping for the best.
| death_syn wrote:
| You need to get a dumb brick for that Rock 5B. Looks like
| you got one of the ones with a bad firmware. When it
| negotiates the power drops out. There're tons of forum
| posts.
| Rediscover wrote:
| If You have not tried what the other reply-post suggests
| (dumb brick), I have a 5V 4A dumb brick I can loan for a
| quick test. Seattle area. It has worked on quite a few
| boards here. Or purchase one from where-ever, they are
| really useful outside of SBCs (though they are usually 5.3V
| and 4.xA, so watch out with sensitive parts).
| 3np wrote:
| Armbian is a saving grace for boards that it supports.
| MisterTea wrote:
| > As usual, looks good on papier but no ecosystem and the
| current stack that it comes with is dead on arrival.
|
| There is no standard Arm ecosystem to boot on which is the real
| issue - every board needs a custom kernel and booting.
|
| I blame Arm for never cooking up a PC like spec that defines
| hardware configuration, firmware and booting. This is why x86
| is going to stick around for a while - its dead simple to
| bootstrap a random x86 machine (well, almost).
| Retr0id wrote:
| I naively assumed that device trees had solved this problem,
| but clearly they haven't in practice. How come?
| Teknoman117 wrote:
| For one, you have to provide one specifically for your
| board to boot at all. There is no "common" one that'll get
| you to a shell on any board.
|
| The main issue is that most SoC vendors just dump a heavily
| hacked up Linux kernel source intended for Android on you,
| along with binary blobs (firmware, android hal services,
| etc.). The drivers aren't in the kernel per se, just enough
| of a stub for the proprietary blobs to talk to the
| hardware.
|
| So if the goal is to run a standard Linux distro on the
| board, you're pretty screwed unless you have the time and
| resources (or a community) to reverse engineer the android
| bsp into drivers for the mainline kernel.
|
| The thing that makes the RPi great is that there's actually
| an entity paying for this development to happen, along with
| the community. It's certainly far from the fastest ARM
| board, but even the decade old RPi 1 still gets kernel
| updates.
| cosmojg wrote:
| Assuming it's small enough for your needs, a used Intel NUC can
| get you loads more mileage than pretty much any ARM SoC at an
| equivalent price.
|
| Currently available on eBay:
|
| * $49.95 for an i5-5300U at 2.3GHz, 4GB of RAM, and 128GB of
| SSD storage
|
| * $89.00 for an i3-7100U at 2.4GHz, 8GB of RAM, and 256GB of
| SSD storage
|
| * $135.00 for an i7-5557U at 3.1GHz, 16GB of RAM, and 256GB of
| SSD storage
|
| ...all loaded with ample driver support, extensive connectivity
| options, and bog-standard x86-64 instructions.
| StayTrue wrote:
| Most people seem concerned about software, ecosystem and
| community. After my experience with Raspberry Pi, my top concern
| is investing in a platform that may leave me hanging for supply
| reasons.
___________________________________________________________________
(page generated 2023-06-15 23:00 UTC)