[HN Gopher] BeagleV-Ahead RISC-V board
___________________________________________________________________
BeagleV-Ahead RISC-V board
Author : abawany
Score : 168 points
Date : 2023-07-12 15:09 UTC (7 hours ago)
(HTM) web link (beagleboard.org)
(TXT) w3m dump (beagleboard.org)
| glimshe wrote:
| For a lot of applications this is really not competitive. You can
| get an Intel/AMD mini PC on Amazon for a little over $100 these
| days, running fully supported Linux.
| eek2121 wrote:
| Do you understand that these boards are the size of a credit
| card? Those mini PCs are far larger than these. I can take a
| Raspberry Pi and stick it inside a picture frame, for instance.
| I actually built an e-reader using a Raspberry Pi Zero 2 W.
| Even a full size Raspberry Pi would have fit in the case...an
| x86 'mini-PC' would not. Sure, I could probably get something
| x86 that would, but I'd have to spend a ton of money (like
| hundreds of thousands or millions)
| jeroenhd wrote:
| If you rip the motherboard out of a NUC you'll probably end
| up with a board of a very similar size. The laptop style
| cooler takes up more space than the board.
|
| The dimensions are different (more square, more USB ports, no
| GPIO) but they're not as big as you may think. A NUC is about
| twice the size of a Beaglebone with much better performance
| and software support, plus the advantage of being able to
| pick your own RAM and storage options.
|
| For something like a picture frame you can easily use a NUC.
| For an e-reader you'd run into form factor issues for the
| cooler, but for something that low spec an ESP32 would be
| even more compact without sacrificing much.
| glimshe wrote:
| That's why I said "for a lot of applications" instead of "all
| applications". Many people buy these ARM boards for regular
| computing roles, such as file server, game emulation etc. And
| even in embedded roles, sometimes the application can
| accommodate the slightly increased size, with the MASSIVE
| advantage of using widely available builds and commodity PC
| hardware.
|
| Also, check this out: https://www.amazon.com/GMKtec-
| Nucbox5-Desktop-Computer-Windo...
| blacksmith_tb wrote:
| That depends, something like this 'GMKTec'[1] is Intel, and
| not really any bigger than an RPi 4 in a case? Obviously you
| can get smaller with an RPi Zero W, but in a case it'd still
| be half as big.
|
| 1: https://www.amazon.com/GMKtec-Nucbox5-Desktop-Computer-
| Windo...
| sylware wrote:
| 64bits RISC-V: yes yes yes.
|
| H.265/H.264: Where is AV1? Coze risc-v is worldwide royalty free,
| not h.265/h264.
|
| HDMI: same issue than H.265/H.264, I should see a dedicated
| display usb-c connector (displayport).
|
| But I am being excessive, it is going in the right direction, the
| next step is to remove H.265/H.264 and HDMI royalties.
|
| That said, has the GPU a lean, plain and simple C written,
| vulkan3D open source driver?
| palata wrote:
| If I may ask (I'm pretty bad with hardware, but learning):
|
| What does "RISC-V" is royalty free mean? Does that make an RPi
| more expensive because they have to pay ARM?
|
| What do the H.265/H.264 encoder/decoders do? Is that important
| when connecting a USB camera (converting from whatever the
| camera provides to H.265/H.264)? And then is it the same thing,
| i.e. that an RPi is more expensive because it has to pay to use
| H.265/H.264?
|
| More than the royalties, shouldn't we care about binary blobs?
| The more open the hardware is, the easier it is for the
| community to maintain it, right?
| darkclouds wrote:
| Is this a 100% totally transparent open source sbc?
| Narishma wrote:
| No.
| WhereIsTheTruth wrote:
| What's up with their pricing? It's way too expensive compared to
| the competition
| swetland wrote:
| Okay, so is there actual documentation for the SoC used on this
| critter? I mean a full Databook / Technical Reference Manual, not
| maybe 30 pages of overview, maybe a list of register base
| addresses (if you're lucky), and a pile of Linux kernel patches
| (upstream if you're lucky, but still of less value to someone
| wanting to actually write code for / port something to the SoC)
| or an "SDK" containing a bunch of low quality vendor code for the
| peripherals.
|
| I'd love to see a RISC-V SoC (not just a dinky little MCU) that
| has real / complete documentation. So far I have yet to find any
| for any of the various RISC-V based SBCs that have shipped.
| MisterTea wrote:
| In addition to all that, is the GPU documented? Clicking
| "Request technical specs" on the Imagination website brings me
| to a page asking me for my business name, business email,
| business...
| yuumei wrote:
| Agreed, the best I have found so far is the SiFive Unmatched:
| https://www.sifive.com/boards/hifive-unmatched which is a full
| mini-itx motherboard. It's not a SoC though.
|
| As far as I can see, the only thing that isn't documented is
| the DDR startup/training code, which is a binary blob in
| u-boot. There are a few registers that are undocumented which
| need to be set to start up but I think the rest is well
| documented.
| swetland wrote:
| SiFive has pretty good documentation for their cores and
| chips -- they are more PC/Server class (some lowspeed
| peripherals plus PCIE and Ethernet) than SoC style. The
| databook does not have register level docs for PCIE and
| Ethernet but both look like off-the-shelf IP (hopefully
| documented somewhere -- I haven't investigated) but otherwise
| seems pretty thorough.
|
| https://www.sifive.com/documentation
|
| In addition to a documented RV64 SoC, it'd be cool to see
| some RV32 MCUs that are a little beefier -- more competitive
| with the mid-range Cortex M4 and M7 stuff (more peripherals,
| more SRAM, etc) -- instead of the existing stuff that looks
| similar to very tiny M0/M3 devices.
| kramerger wrote:
| This is a Wujian 600 from Alibaba (!). To my knowledge there is
| currently no publicly available documentation from the chip
| manufacturer.
|
| Was the idea of an open ISA leading to an open SoC was just
| wishful thinking?
| pclmulqdq wrote:
| Not entirely, but the process is very slow.
|
| RISC-V (and SiFive) caught a moment where it could be used is
| a way to squeeze ARM on pricing. It doesn't really
| meaningfully create openness on the interesting parts of the
| stack (core architecture, SoC architecture, etc.) on its own.
| In that sense, the hype is overblown.
|
| It does _enable_ open-source cores to some degree, but that's
| it, someone has to take the leap to make a production-ready
| one. A few companies are trying, but an open-source SoC is
| even further down the road.
| MisterTea wrote:
| The link they liisted to the SoC is also broken:
| https://t-head.cn/TBD
| panick21_ wrote:
| Open ISA is necessary but not sufficent. One step on a long
| journey.
| flyingcircus3 wrote:
| I've been very disappointed with the rollout of their most recent
| board, Beagleplay. There are all of these self-congratulatory
| videos of Jason Kridner at trade shows talking about they're
| making Embedded Linux more accessible/simple. Yet 4 months after
| release, the quickstart guides are mostly notes to future
| quickstart guide editors, or otherwise describe workflows that
| don't actually work.
| kaelinl wrote:
| Yeah, I had the same experience with the BeagleBone AI-64.
| Their documentation is extremely lacking. To make it worse, the
| whole point of the board is TI's ML inference accelerator, and
| TI's documentation and sample code for it are completely
| useless.
|
| The Beagle hardware is great but it seems to me they just don't
| have the resources or focus to support the hardware they
| release.
| synergy20 wrote:
| I think the newer AI board from beagleboard is "BeagleBone
| AI" without the "64"?
|
| Anyway I was thinking about buying it, but ended up with
| buying Nvidia's Jetson instead, due to software and
| documentation difference.
| reesul wrote:
| I believe the 64 variant is the newer part. The older one
| is a 32 bit architecture IIRC.
|
| Jetson has a big edge in software and documentation, no
| doubt. Poor documentation and SDKs seems to be the norm for
| a lot of embedded processors, especially for the AI
| acceleration piece.
|
| I'm curious for this new beagle board if there's enough
| documentation / software to use the AI accelerator.
| st3fan wrote:
| Wow $235 CAD. Why is this board so insanely expensive?
| neilv wrote:
| > _System on chip: Alibaba T-Head TH1520_
|
| Why is this not a TI SoC?
| LeifCarrotson wrote:
| TI does not make any RISC-V processors.
|
| I've been quite happy with the documentation for the AM335x
| processors on the standard, ARM-based Beaglebone Black.
|
| But the readme at [1] is exactly why I'm reluctant to pick this
| board:
|
| > Tracking mainline u-boot/kernel with T-Head patches as needed
|
| > Additional SoC details (Chinese language is good) - pointers
| to licensed IP is fine
|
| > Clear legal path to usage:
|
| >> Verify the IP in the SoC is licensed for use
|
| >> Verify the IP _user_ documentation can be public [emphasis
| original, why not the developer documentation?]
|
| >> Signed 3P agreement
|
| > SDK source required to test board
|
| > Documentation needs to launch:
|
| >> Additional SoC details (Chinese language is good) - pointers
| to licensed IP is fine
|
| You'll pay more for an NXP, TI, or ST-branded SOC than for an
| Allwinner, Rockchip, or "T-head" one, but even if all you're
| paying for is documentation it's well worth it IMO.
|
| Edit: It's great that the processor core is an "XuanTie C910
| open-source RTL RISC-V". Open-source RTL, wow! The Verilog is
| up on GitHub [2]! You'll never get that from TI! But the
| processor core is only a small part of the SOC, there's a ton
| of other peripherals and other closed-source, closed-
| documentation IP to run them.
|
| [1]: https://git.beagleboard.org/beaglev-ahead/beaglev-
| ahead/-/bl...
|
| [2]: https://github.com/T-head-
| Semi/openc910/blob/main/C910_RTL_F...
| my123 wrote:
| Note that OpenC910 isn't the same core as the shipped one on
| this device. OSS version doesn't have RVV where the closed
| one that is actually shipped has RVV 0.7.1 for example.
| neilv wrote:
| Agreed. And in addition to these development feasibility,
| sustainability, and open source concerns/requirements, some
| applications will also have to look at provenance.
| delfinom wrote:
| TI doesn't make RISCV anything.
|
| It's why they called it the BeagleV ;)
| SoftTalker wrote:
| Nitpicking but they really need to have someone proofread their
| copy.
| magios wrote:
| $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
| rcarmo wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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
| progbits wrote:
| 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 wrote:
| 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 wrote:
| Who should require it? And how will it be enforced?
| progbits wrote:
| 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 wrote:
| 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.
| joezydeco wrote:
| As someone that has actually shipped RPi-like boards and
| clones, I'll tell you that it's just part of the job
| description.
|
| They ALL suck, some just suck less than others. Broadcom,
| Renesas? The worst. ST, NXP, TI? Slightly better than fully
| sucking. Look to the chipmaker (ST, NXP) and not the board
| maker (Orange) for a guide in how well things go.
| colechristensen wrote:
| But the RPi _is_ broadcom and arguably the best supported.
| Obviously this is special.
|
| From experience I agree with you, the chipmakers suck
| because they utterly fail to be open source when they're
| one of the groups that needs it the most. It is to the
| extent that I would advocate for laws in the theme of
| right-to-repair to force chip vendors to provide source for
| necessary code to use their products to consumers. (in this
| case open source in the narrowest definition, they can keep
| their copyrights but would be required to distribute source
| to end users in a form and with a license that makes them
| usable)
|
| If the question is "are any of the SBCs worth the trouble?"
| and the default answer is no unless I have a really good
| reason and want to dedicate the time to building the janky
| software stack (I don't), or they're from a small list of
| vendors I'd trust won't be a mess (RPi, nvidia, beagle, ...
| that's it off the top of my head)
| joezydeco wrote:
| Were the kernel and BSP improvements and ongoing support
| for RPi produced by Broadcom, or by the user community?
| colechristensen wrote:
| There is some sort of close relationship between Broadcom
| and the raspberry pi foundation which is not entirely
| clear, they are a bit more than just customers although
| companies use the "partnership" label to mean just about
| anything.
| joezydeco wrote:
| The relationship is very clear: Upton was a Broadcom FAE
| that started the RPi Foundation. The secondary story was
| that he found a use for an orphaned SoC and embarked on
| an 'educational' quest to make small computers for
| classrooms.
|
| The real question is if Broadcom is devoting internal
| software resources to improving the ecosystem, or if it's
| coming from the devoted users. I don't track commits on
| kernel.org enough to know what's what.
| tmchu wrote:
| Please excuse my ignorance here, but are you saying that
| the board makers have no say on what chip they want to
| incorporate into their board? And those chips firmware are
| not open or at least accessible to the board makers?
| joezydeco wrote:
| What I'm saying is treat the board as a development
| harness to get your project going. If you have issues
| with the processor don't take it up with the board maker
| because they're usually just as clueless. The exception
| would be boards like RPi or Beagle where the designers
| are tight with or owned by the chipmakers themselves.
| jvanderbot wrote:
| Right, which is what GP was saying: stick to those that
| are able to support longer than zero time horizon.
| joezydeco wrote:
| But the fundamental difference here is that most people
| buying SBCs are treating them as self-contained COTS
| compute modules.
|
| As someone that has worked with these EVKs for decades,
| you _never_ treated them as part of your final product.
| But with the advent of Beagle and RPI, that 's where we
| are now.
|
| But when you buy an RPi or Beaglebone as the core of your
| industrial smelter and expect support for that module
| comparable to, say, a module from Kontron? You're going
| to be disappointed.
| jvanderbot wrote:
| Support is the S in IOT.
| HeyLaughingBoy wrote:
| I thought that.... oh, Security is the _other_ S. Got it!
| opless wrote:
| Board support packages very rarely get updated and
| usually target a very specific kernel version.
|
| You move off that kernel version, no BSP, no boot. sad
| times.
|
| This is one reason why you don't get android phones
| supported past the android release shipped.
|
| You're completely at the mercy of the SoC provider.
| Promises of 'n' years support are quite often quietly
| dropped after 18 months, when they realise all the
| engineers have moved to working madly to get the latest
| SoC's BSP out of the door.
|
| Rinse and repeat.
| KingLancelot wrote:
| [dead]
| magios wrote:
| 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 wrote:
| Beaglebone Black is used in industrial applications. At
| scale, those price differences add up.
| cozzyd wrote:
| 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).
| bagels wrote:
| Yes, for the application I used them in, we were
| concerned about both the upper and lower limits (heat
| from operation + cold when turned off in the winter).
| Outdoor installation, with hundreds of units per site.
| bitwize wrote:
| I keep saying, the first cheap Chinese manufacturer that
| ships a SystemReady board is going to slaughter the
| competition.
| jona-f wrote:
| Wait, I used OrangePi's with Allwinner chips before precisely
| cause of their cheap price and mainline linux support. At the
| time (~5 years ago) Rpi was worse, foss-wise. Here is a wiki
| documenting the efforts: https://linux-
| sunxi.org/Linux_mainlining_effort What am i missing?
| Cyder wrote:
| i use orangepi prime boards in production as remote NIDS. i
| used Armbian (a great debian porting project that does what
| the maker should have done ) until orange released their
| Debian 10 img. I put an endurance rated sdcard in those pis
| and they run like the little pink bunny! Love these little
| orangepis. I have tried a handful of other boards ( beagle,
| raspberry, banana , have a whole stack. too many to
| remember) but the oranges are solid. On a lot of these
| little SoCs, you can use the raspberry pi gpio software
| since many of these boards follow the same gpio standard &
| plug in/out.
| eek2121 wrote:
| The VisionFive 2 developers are working on getting things
| upstreamed/open-sourced for their board. IIRC the kernel has
| already mainlined many (if not all) of the patches.
|
| Some of the real issues are as follows:
|
| 1) Most companies use Debian as a base. Debian has a
| notoriously slow release cycle. This means it takes loads of
| time to submit patches -> get approval -> get merged in a
| merge window -> wait for debian to use new kernel with new
| code.
|
| 2) The GPU situation is a mess. No decent (compatible)
| vendors with open source GPU drivers exist. Imagination is
| said to be working on open source drivers, but with no real
| release date, we are stuck using closed source blobs. Once
| drivers and Mesa get updated, we then have to wait for a new
| release of Debian to pick these up.
|
| 3) Far fewer people use these boards over a Raspberry Pi.
| This means community support takes longer to develop. The VF2
| has other distros like Arch and Ubuntu, for example, but no
| real active community behind them. Last I checked, hardware
| GPU acceleration was not working in these distros.
| unwind wrote:
| Surely this:
|
| _50GFLOPS, 3Mpixel /s Imagination BXM-4-64 graphics processing
| unit (GPU)_
|
| Has got to be a typo? 3 million pixels per second is not very
| impressive, to understate things a bit.
|
| Edit: also, in Sweden Digi-Key want almost $180 for this which
| was more than I expected. Wow.
| WatchDog wrote:
| Any benchmarks of the CPU?
| ur-whale wrote:
| No USB-C port.
|
| No NVME port.
|
| Price tag is too high.
|
| Shame because the rest of the H/W looks nice.
| Jamesmoorez wrote:
| [dead]
| pjmlp wrote:
| Ah Beagleboard, what everyone was reaching for, before Arduino
| and Raspberry Pi got famous.
| nvy wrote:
| I have a few Beaglebone Blacks kicking around the house and
| they're great. I've always felt the Beagle boards were superior
| to Raspberry Pis, and that the RPi mostly succeeded because of
| better marketing and outreach efforts.
|
| It's nice to see the project still chugging along
| rootbear wrote:
| The linux image on the beagleboard site for the Black is three
| years old. Is it possible to just boot generic ARM linux on the
| Black now? Is there another site for official images?
| m0th87 wrote:
| I've heard Beaglebone Blacks are great (never used them), but
| have to say the experience with Blue was awful. I had a
| hardware defect that's apparently commonplace. It gave me the
| feeling (maybe unjustified) that there's a low bar for slapping
| the Beaglebone label on a product. In contrast, none of my
| several RPi's have had any hardware issues, and I'm pretty
| brutal with them.
| squarefoot wrote:
| PRU aside, BeagleBoards/Bones mount eMMC memory which offers
| much higher reliability compared to microSD cards. RPis are
| great for tinkering and prototyping, but I wouldn't feel safe
| employing them where uptime is important.
| tracker1 wrote:
| Agreed there, I've seen horrible reliability on (micro)SD
| cards for these little project boards. For RPi, usually use
| SSD over USB for primary boot, there are some nice case
| options for this, if you don't mind the space.
|
| Over the pandemic, started using more of the mini intel boxes
| in the sub-$300 space, just because of availability and price
| gouging.
| genmud wrote:
| You can get CM4s with eMMC memory now, but if I was doing a
| CM4, might as well just use an nvme ssd.
| 542458 wrote:
| I'd also say it's that the RPis are generally much cheaper and
| also offer (subjectively) better I/O.
|
| For example, A BeaglePlay costs about twice what a Pi 4 Model
| B/4GB does in my local market. The BeaglePlay has half the ram,
| only one USB 2 port to the Pi's two, none of the Pi's USB 3
| connectors, way fewer GPIOs, only one HDMI, no audio, etc. I do
| like that BeagleBoards have onboard flash though.
| bsder wrote:
| > I'd also say it's that the RPis are generally much cheaper
|
| _IF_ you can actually get one. That 's a _REALLY_ big _IF_.
|
| RPis have been subsidized for a long time. The fact that the
| subsidy is gone means that they don't seem to be willing to
| release them to we plebians very much anymore. They're fine
| releasing them to T-Mobile, though.
|
| Anybody not a pure hobbyist left the RPi space long ago.
| mlyle wrote:
| > Anybody not a pure hobbyist left the RPi space long ago.
|
| Actually, the constrained supply is because during COVID
| and aftermath they decided to support industrial customers
| to the detriment of hobbyist supply.
|
| They're currently cranking out a million units per month
| and supply is returning to retail. https://rpilocator.com/
| was completely bare a few weeks ago, and now there's a lot
| of retailers with stock (though it's still not where it
| should be).
| cozzyd wrote:
| It depends on the application. BBBs come in industrial
| variants (the Pis don't, so good luck using them in certain
| contexts), and have more UARTs, i2c and SPI buses, not to
| mention the PRUs...
| nomel wrote:
| My favorite part of the BeagleBoard are the PRU's: two little
| 200Mhz realtime coprocessors. [1]
|
| [1] https://beagleboard.org/pru
| rasz wrote:
| I dont see PRUs mentioned for this one tho
| cozzyd wrote:
| they're a TI thing, so very unlikely they exist here
| spott wrote:
| BeaglePlay also has sub-1Ghz wireless, (along with 2.4Ghz
| programmable wireless), a PRU (essentially a built-in
| microprocessor suitable for realtime I/O work). The core
| processor supports CAN, and a bunch of other features, but
| I'm not sure if these are broken out in a way that is usable.
|
| Beagleboards are just different than RPis. They aren't really
| trying to be the same thing. RPis are small computers with
| simple GPIO meant for turning on and off things, Beagleboards
| are computer/microprocessor hybrids with GPIO meant for doing
| realtime I/O.
| jgalt212 wrote:
| Are PRUs their version of the RP 2040's Programmable IO
| (PIO)?
| MisterTea wrote:
| The 2040's PIO is indeed similar but the PRU has features
| the PIO doesn't like IOs directly wired to CPU register
| bits so the result of an instruction is immediately
| available on IO lines.
|
| edit: also Ti's PRU has been around waaaay longer than
| the RP2040 so the PRU is likely an inspiration for the
| PIO.
| nvy wrote:
| PRU stands for Programmable Real-time Unit.
|
| The soc on the original Black had two 200MHz PRUs which
| ran independently of the main processor and could be used
| for signalling and sensing tasks that require tight
| timing guarantees, and can then trigger interrupts on the
| main CPU.
| jgalt212 wrote:
| so yes, then.
| m00x wrote:
| It's kind of a middle ground, it looks more like a
| barebones MCU.
|
| RP2040's PIO is extremely limited with only 9 available
| instructions, this looks a bit more involved, but
| functionally it's very similar.
| jchw wrote:
| > RPis are small computers with simple GPIO meant for
| turning on and off things,
|
| Maybe you didn't mean this in a way to diminish how handy
| Raspberry Pis are, but I've used it in tons of situations
| that are more interesting than turning LEDs on and off. It
| being a usable computer is icing on the cake. I have RPis
| for all kinds of things: Home Assistant using the Bluetooth
| module (+ external Z-wave/Zigbee controller via USB),
| OpenJVS for running arcade I/O emulation (GPIO for serial
| communication), I doubt I need to explain how useful it is
| to have a FlashROM setup, I've gotten a Pi to drive a
| Commodore SID...
|
| I can see based on the RPi Pico which seems to have similar
| functionality to the Beagleboard in terms of I/O that in
| fact there is so much more that COULD be done, and I'm glad
| that we have these now. That said, I don't want people to
| think that RPi is a toy! Having a moderately powerful small
| form factor computer connected to all of this I/O lets you
| do things that you couldn't even when GPIO is involved. Not
| to mention, you can bitbang the GPIO really fast on a
| Raspberry Pi, which can come in handy.
| RF_Savage wrote:
| CAN is likely doable via the PRU's.
| 542458 wrote:
| > Beagleboards are just different than RPis.
|
| Yeah agreed, and I don't think I communicated that in my
| comment above. It's not that the Pi is universally better
| in all cases, but it is better suited for many common
| consumer applications... Which logically leads to it being
| the higher selling device.
| cbm-vic-20 wrote:
| "2GHz quad-core RISC-V 64GCV Xuantie C910 central processing unit
| (CPU)"
|
| The datasheet doesn't mention Vector (V) extension support. Is
| this an error on the Beagleboard page?
| camel-cdr wrote:
| Maybe it's because the C910 + V is now sometimes called C920, I
| think they changed their branding on that.
| linmob wrote:
| No, unfortunately not - the TH1520 SoC comes with some Vector
| extension support - but rev 0.7 (IIRC), not 1.0 which one would
| rather want.
| camel-cdr wrote:
| Note that there are currently no consumer rvv 1.0 cores out
| there. You also can't expect much support for pre
| ratification rvv. I needed to patch vector support into the
| ubuntu build for my MangoPi MQ pro board, and use an old
| toolchain to be able to compile and test my rvv 0.7.1 code.
| jauntywundrkind wrote:
| Overall nice looking board.
|
| I used to scoff at PowerVR GPUs as being unsupportable &
| worthless, but progress has been quite good lately. Only 3 SoC
| supported & not this but porting should go relatively smoothly
| now.
|
| Price feels high.
|
| Elephant in the room: what the heck is that USB micro 3.0
| connector doing there? Yikes! What an ugly relic. And that's the
| only USB on the board.
| prabhu-yu wrote:
| Agree, Any reason why is the Type-C not used?
| johnwalkr wrote:
| Yeah, that is my comment as well. It looks like it's also not
| enough to power it, you need to use the barrel jack.
|
| On the original beaglebone and beaglebone black, a nice feature
| is you can connect it by microusb, and this provides power to
| the board but also bridges your internet connection. So with
| one cable you get power, ssh into the device, and an internet
| connection on the device.
| snvzz wrote:
| Yet another TH1520 board.
|
| Note there's several, by different vendors, with different
| connectivity (e.g. PCIe, M2, wifi/bt) and RAM (4-16GB range).
|
| The CPU is a XuanTie C910, which is somewhat faster than SiFive
| U74 used in the JH7110 (VisionFive2), and adds pre-spec vector
| extension (0.7.1).
|
| I would still recommend VisionFive2 or Star64 to most people, due
| to its maturity and much better upstream support[0].
|
| 0. https://rvspace.org/en/project/JH7110_Upstream_Plan
| synergy20 wrote:
| Here is Beagle board list:
|
| https://www.arrow.com/en/research-and-events/videos/comparin...
|
| At the moment I have no plan to acquire yet another beagleboard,
| i.e. this BeagleV, a bit pricey for potential projects at scale,
| and I don't need those media related ports, though the AI NPU
| seems nice for edge AI.
___________________________________________________________________
(page generated 2023-07-12 23:00 UTC)