The success-story of the BeagleBone Black/Green is absolutely amazing, TI has continued producing it’s AM3358 over the original, designated end of life because it sells so much of this SoC just with the BBB/BBG. So in my opinion it would be quite easy to continue this success story of the BeagleBone Black/Green, but until now all successors are an incredible failure:
there are these AI/64 variants which have a different form factor and are way too expensive
there is the “V Ahead” which is expensive and comes with a more or less undocumented and (from programmers point of view) unsupported SoC
now we have that “V Fire” which is not really cheap but comes with an SoC that lacks msat of the features of the original AM3358 (PWMs? UARTs? QEP? I2C? more or less missing!) - so the expansion interface is a joke, it is only compatible in terms of number of pins and position of the power supply connectors
So what I blame all these developers for, is their selection of the SoC. My question: why not simply using an AM62x from TI? It comes for a low price, has interfaces similar to the AM3358 and provides an incredible computing power for a very good price! What is the problem with the AM62x? Why not use it for a BeagleBone successor that really deserves this name because it is really similar to the original White/Black/Green?
We are having better luck with the Beagley-ai than the others, so it really depends on your use case. Still use the BBB / BBBi that one is the best in its class.
This is no Beaglebone-successor as it has a completely different form factor and no comparable expansion connector. Or in other words: it is as incompatible to BBB/BBG as all the other “successors”.
What you need to consider is the politics and agenda driving the designs… The other issue is price point, beagley-ai and pi 5 both lack emmc. That takes those off the table for some projects due to lack of being able to secure the code on the board. Also, keep in mind it has to be a relatively easy board to work with, I can most certainly understand the need to use microbus on the am62, board. That is a coin toss decision and hope it pans out for them.
My self and others are completely locked out of the profit chain, so why do I want release sophisticated high value code for free and products that can be replicated with an image on a SD card. Others are selling millions of units… they are realizing a profit from inkind contributions of others. My good will and generosity evaporate quickly when I see big tech / small tech companies exploiting the good will of others.
Unless you have $200,000 or so for your own board, all you can do is make the best of what is offered.
It’s being worked on, one problem with an true successor… Compatibility… Think of the AI64, Play, BeagleY-AI, as test designs to see what limitations there are in the AM6x’s IP generation…
Hm, to be honest, I’m not aware of any limitations of the AM62x…what are you referring to exactly?
May be I explain my concerns regarding the successors of the BBB/BBG in a different way: BBB/BBG are an incredible success in industry and automation, toys like the RasPi never came that close in terms of “serious” applications.
Now what the industry REALLY likes, is compatibility. Means prior to adding new features, devices need to stay backwards-compatible. And that’s where I thought the AM62x would be the best choice as it provides all the features of the AM3358 plus faster USB plus faster Ethernet plus more cores plus more computing power. So am I wrong with this assumption about the AM62x?
I expect what @RobertCNelson is referring to is making sure the the pin headers have the exact same functions as the BBB to make sure that existing capes carry on working.
The pinouts of the 2 chips are going to be very different and each pin may have different mux modes to the BBB. There probably isn’t a one to one match to provide the exact same pin functionality.
To achieve that in some cases multiple CPU pads will get mapped to the same pin, in much the same way that the AI64 doubles up on some header pins.
It might not even be possible to achieve pin to pin compatibility, in which case making a physically identical board will lead to people trying to use BBB capes in the new design and then complain when they don’t work.
It takes time to work all that out, especially as the chips get more complex. Plus the hardware design team is pretty small, maybe even only 1 person @jkridner and there have been multiple new boards released. While the new boards might not be what you are looking for, the folks at BeagleBone Org need to cater for a very wide and diverse set of users.
But at least it would appear that there are plans for a BBB successor.
You are correct, its a mess do to the mux, trying to work with that is not easy.
What I am running into is the RPI add-on boards and getting them on the beagley-ai. Working thru 3 HAL’s made it mess that came down to using a vom to identify what goes where. They have wiring pi markings that are not even related to RPI. It was a mess, did get it worked out and those boards are adding value to the bby.
Worst case outliers on the gpio of bby are are about half of the bbb worst case results so the board can most certainly handle more I/O without being choked down. Myself, it seems best to move forward and not worry about past compatibility issues. Just keep it simple like the bbb numbering, P9_10, you know exactly what is going on.
No, the AM62x is one of the closest… But if you look closely, it’s not a 100% pin for pin match… So part of the other boards, was testing some of the IP blocks to see how close they are to am335x…
That’s nothing I would expect. Redesigning boards that attach to the BBx is simple when the signals are there. So a signal-match is more important than a perfect pin-match. In my opinion
As someone who tries to make a living selling capes for the Beaglebone Black and PocketBeagle, not having a viable successor to either is a huge disappointment. Definitely has me starting to push more of my offerings toward the Pi4/5/Zero. I wouldn’t even say it has to be 100% pin compatible. The Pi5 isn’t 100 pin compatible with the Pi4, but it works well for most use cases and libraries and hats and such will slowly adjust over time.
I’ve played a bit briefly with the beagley-ai, but it’s really not a good option for my use case. With only the standard 40pin GPIO header, there aren’t enough GPIO’s for my higher end designs (I’m even running into issues with the Beagle gpio’s) and thus only really usable for the lower end/middle range designs. However, the Pi3B+ and Pi4 work fine for those and are significantly cheaper.
The other issue is that I have thousands of lines of hand tuned assembly for the Beagle PRU’s for handling the output. The R5’s is likely usable for similar things on the beagley-ai, but that would be significant effort to port over. That said, the PRU’s also use the direct r30 pin IO for high performance IO and I’m not sure how well the R5 can handle that. It’s been on my todo to play with, but very low priority since the Pi4 works just as well for that use case, is cheaper, and is already supported. If there was a beagley-ai using the Beaglebone form factor with more IO, then sure, I’d definitely jump it up the priority list.
You should be able to mux outside of the header. BBB and BBy comparision on the gpio using 8 channels has the worst case outliers at about half the time as the BBB. That stuff is at my other office so this is all from memory, seems close. With that said, bby is fast enough to handle gpio load increase. That PRU is something I have not played with. Since you have a single core the multiple core bby you should be able to manage the tasks fairly well and actually end up with a better control. Lot of work…and most certainly using c++ 20. Only issue I am running into at this instance is with the board is getting i2c4 up and the USB does not like the code I am running. Also need to get both of the DSP’s up, really not moving forward with it until I fully understand how to build a device tree for that board. It is heavily threaded and more than likely an issue I am creating, but, I cannot find the problem… For basic stuff, so far it seems okay.
The other issue is EOL, I don’t see any other company using that am67 for a SoM, the am62 is being used by several. So, they have inside information and we don’t, its a guess on my part.
Your lighting work is really amazing. Now that new even faster Pico 2 is out, wonder if that can drive your designs? You’d still need something higher for OS “pico” management (or small RTOS)…
The Beagle V-Fire can only be considered a “failure” if you regard it as a direct replacement of the Black/Green. It is not. It is something new and different in a Beagle form factor. That said, if you are willing to learn how to use the FPGA fabric, I suspect there is nothing the Black/Green can do that the V-Fire cannot do. PWM’s, UARTs, I2C, if they are not already available as hard blocks can be implemented in the fabric.
While a more direct successor to the original Black/Green may be desirable, to call the other members of the Beagle family “failures” is narrow minded.
