11 ms·

$150-$180 seems expensive for 4gb ram and 16gb flash when you can get an sbc with the same soc, the sipeed licheepi 4a with 16gb of ram and 128gb flash for $180

by magios 3y ago

$150-$180 seems expensive for 4gb ram and 16gb flash when you can get an sbc with the same soc, the sipeed licheepi 4a with 16gb of ram and 128gb flash for $180, or $120 for 8gb ram and 8gb flash, or $135 for 8gb ram and 32gb flash

progbits 3y ago
How's the software support for sipeed stuff? Every time I opted for cheaper clone of beagleboard or RPi I ended up regretting it when I inevitably had to spend hours building custom kernel patches and struggling to get it working reliabily. The more expensive boards usually work out of the box with mainline kernel. For some that can be worth the extra $50.
- magios 3y ago
  well, if the soc is the same, thus same cpu, gpu, and npu, kernel and userspace support should be also roughly equal, tho the device tree will differ between the two devices. i do agree that many of these sbc computers have poor initial support and many end up remaining that way. perhaps we should be requiring that mainline linux support, and working drm drivers, for gpu, exist before the product is released.
  - mat_epice 3y ago
    Who should require it? And how will it be enforced?
  - progbits 3y ago
    If it is just device tree that should be less painful, and probably also faster to upstream. I'm just hesitant to buy one of those without having some 3rd party confirm everything works well out of the box, and the more obscure the device the harder to find such accounts.
riskable 3y ago
As someone who's bought many RPi-like boards and clones let me tell you: Minor differences in price/performance are unimportant. There's another factor that's so much more important it makes boards like the Beaglebone and RPi seem like ultra high performance bargains in comparison: Software/kernel support. Every goddamned RPi-like SBC seems to require a very, very specific version of the Linux kernel that has been patched to hell and back. Almost always bundled with binary blobs/firmware that only work with that very specific version of the kernel. None of these patches get upstreamed and the binary blobs/ultra proprietary who-knows-wtf-its-doing required firmware never get updated after the release. This means that you'll be stuck with whatever version of the kernel that shipped with the device forever. Complete with all the bugs and vulnerabilities that get discovered later. Never again! Either the vendor needs a history of staying on top of things or they need to make some serious promises about upstreaming kernel patches and drivers. Example of a terrible SBC vendor you should never buy from: Orange. All the OrangePi SBCs are exactly as I described. You can expect any bug or security issue that exists at release to be a problem with that board forever. They will never get fixed. They might release an update or two within a few months of release (if it's real bad) but that's all you'll ever get.
- magios 3y ago
  i agree, that is a problem, mainline linux and working drm, that is direct rendering manager, drivers should exist before release of the product.
- bagels 3y ago
  Beaglebone Black is used in industrial applications. At scale, those price differences add up.
  - cozzyd 3y ago
    yes, especially because there is an industrial variant that works down to -40 C. We use them in our detectors in Greenland. rpi's sometimes work at low temperatures, but are not spec'd for it (plus they use tons of power compared to the BBB).
rcarmo 3y ago
I came here to say exactly that. Right now ARM SBCs (especially the RK3588 ones) are pretty competitive -- but, ironically, so are Intel 5xxx and N100 mini-PCs.
dekhn 3y ago
do those SBCs have digital IO (GPIOs) and a realtime operating system? The reason I'd buy a Beagle (well, really an ESP32) isn't the price, it's the convenience of havng real time GPIOs.
- johnwalkr 3y ago
  I don't think this one does, but the other models such as beaglebone black have 2, 200Mhz microprocessor cores that can access GPIO and shared memory in realtime (without an RTOS). It's a killer feature, you can have the best of both worlds. For example, a python program running in userspace, interacting with a microcontroller doing GPIO stuff quickly and in realtime.
  - dekhn 3y ago
    I known the BB can do this. T he question is if any of those SBCs do realtime gpios. Raspi SBCs have gpios but you can't trivially write an interrupt handler than runs in kernel space
- brucehoult 3y ago
  Sure there are GPIOs -- didn't you see the "cape" connector? The SoC had quad C910 OoO cores (similar to A72) as the application processors. There is also a simple E902 (in-order, 2 pipe stages, RV32EMC ... basically Cortex M0 equiv) in the Always-On subsystem and a C906 (64 bit in-order, 5 pipe stages, used as main applications processor in numerous AllWinner D1, Bouffalo BL808 etc boards) in the "audio" subsystem.
  - dekhn 3y ago
    I don't know what machine you're referring to. The BeagleBone, or some other SBC? Looks like this board (if you mean https://linuxgizmos.com/dev-kit-debuts-risc-v-xuantie-c910-soc-with-a-3d-gpu-and-android-and-linux-support/ https://linuxgizmos.com/dev-kit-debuts-risc-v-xuantie-c910-s... or something like it) runs Linux (android or debian). With the BB, you could at least program the PRUs to handle these problems directly in hardware. With the ESP32 you're writing code that runs in an RTOS. Most SBCs I've seen make you use userspace to access GPIOs. unfortunately for my use case, I have about a 100 nanoseconds to move a signal from one GPIO to another, and if I drop an interrupt, it means part of my data ends up missing.

by magios 3y ago

progbits 3y ago

How's the software support for sipeed stuff? Every time I opted for cheaper clone of beagleboard or RPi I ended up regretting it when I inevitably had to spend hours building custom kernel patches and struggling to get it working reliabily. The more expensive boards usually work out of the box with mainline kernel. For some that can be worth the extra $50.

magios 3y ago
well, if the soc is the same, thus same cpu, gpu, and npu, kernel and userspace support should be also roughly equal, tho the device tree will differ between the two devices. i do agree that many of these sbc computers have poor initial support and many end up remaining that way. perhaps we should be requiring that mainline linux support, and working drm drivers, for gpu, exist before the product is released.
- mat_epice 3y ago
  Who should require it? And how will it be enforced?
- progbits 3y ago
  If it is just device tree that should be less painful, and probably also faster to upstream. I'm just hesitant to buy one of those without having some 3rd party confirm everything works well out of the box, and the more obscure the device the harder to find such accounts.

riskable 3y ago

As someone who's bought many RPi-like boards and clones let me tell you: Minor differences in price/performance are unimportant. There's another factor that's so much more important it makes boards like the Beaglebone and RPi seem like ultra high performance bargains in comparison: Software/kernel support. Every goddamned RPi-like SBC seems to require a very, very specific version of the Linux kernel that has been patched to hell and back. Almost always bundled with binary blobs/firmware that only work with that very specific version of the kernel. None of these patches get upstreamed and the binary blobs/ultra proprietary who-knows-wtf-its-doing required firmware never get updated after the release. This means that you'll be stuck with whatever version of the kernel that shipped with the device forever. Complete with all the bugs and vulnerabilities that get discovered later. Never again! Either the vendor needs a history of staying on top of things or they need to make some serious promises about upstreaming kernel patches and drivers. Example of a terrible SBC vendor you should never buy from: Orange. All the OrangePi SBCs are exactly as I described. You can expect any bug or security issue that exists at release to be a problem with that board forever. They will never get fixed. They might release an update or two within a few months of release (if it's real bad) but that's all you'll ever get.

magios 3y ago
i agree, that is a problem, mainline linux and working drm, that is direct rendering manager, drivers should exist before release of the product.
bagels 3y ago
Beaglebone Black is used in industrial applications. At scale, those price differences add up.
- cozzyd 3y ago
  yes, especially because there is an industrial variant that works down to -40 C. We use them in our detectors in Greenland. rpi's sometimes work at low temperatures, but are not spec'd for it (plus they use tons of power compared to the BBB).

rcarmo 3y ago

I came here to say exactly that. Right now ARM SBCs (especially the RK3588 ones) are pretty competitive -- but, ironically, so are Intel 5xxx and N100 mini-PCs.

dekhn 3y ago

do those SBCs have digital IO (GPIOs) and a realtime operating system? The reason I'd buy a Beagle (well, really an ESP32) isn't the price, it's the convenience of havng real time GPIOs.

johnwalkr 3y ago
I don't think this one does, but the other models such as beaglebone black have 2, 200Mhz microprocessor cores that can access GPIO and shared memory in realtime (without an RTOS). It's a killer feature, you can have the best of both worlds. For example, a python program running in userspace, interacting with a microcontroller doing GPIO stuff quickly and in realtime.
- dekhn 3y ago
  I known the BB can do this. T he question is if any of those SBCs do realtime gpios. Raspi SBCs have gpios but you can't trivially write an interrupt handler than runs in kernel space
brucehoult 3y ago
Sure there are GPIOs -- didn't you see the "cape" connector? The SoC had quad C910 OoO cores (similar to A72) as the application processors. There is also a simple E902 (in-order, 2 pipe stages, RV32EMC ... basically Cortex M0 equiv) in the Always-On subsystem and a C906 (64 bit in-order, 5 pipe stages, used as main applications processor in numerous AllWinner D1, Bouffalo BL808 etc boards) in the "audio" subsystem.
- dekhn 3y ago
  I don't know what machine you're referring to. The BeagleBone, or some other SBC? Looks like this board (if you mean https://linuxgizmos.com/dev-kit-debuts-risc-v-xuantie-c910-soc-with-a-3d-gpu-and-android-and-linux-support/ https://linuxgizmos.com/dev-kit-debuts-risc-v-xuantie-c910-s... or something like it) runs Linux (android or debian). With the BB, you could at least program the PRUs to handle these problems directly in hardware. With the ESP32 you're writing code that runs in an RTOS. Most SBCs I've seen make you use userspace to access GPIOs. unfortunately for my use case, I have about a 100 nanoseconds to move a signal from one GPIO to another, and if I drop an interrupt, it means part of my data ends up missing.