In case you are curious, the GPU is PowerVR "Rogue" AXE-1-16M. Despite PowerVR generally having been a pain in the ass in the past, they apparently have had a change of heart finally and are trying to push drivers to mainline which is nice. Although it must be also said that afaik the drivers have not been merged yet, so ymmv with these devices
The possibility of them using a PowerVR GPU was the first "fly in the ointment" that occurred to me upon reading this. I have the OG Beaglebone and the closed source GPU driver was a real pain to deal with in terms of updating the kernel and the like. Do you have further details on how far along their open source effort is and how serious they are about it? The last reference I found in a quick search goes back to Aug 2022.
Screw PowerVR. I'll never forgive them for the way their crap drivers locked down chips strangled the netbooks and some of the UMPCs. To this day I still look up the SONY Vaio P and drool only to wake up again when I realize the hardware will never perform right in Linux because of the poison pill that is PowerVR. I also blame Intel but it was PowerVR's chips.
If they want to play at having a change of heart, let them release what it would take to make the Sony Vaio P series and other netbooks with those video chips viable again.
Beagleboard is the pioneer in SBC trend, it predates RPi, arguably RPi took the ideas from OLPC(one laptop per child) and Beagleboard and made what it is today. Even today, Beaglebone is quite popular for real products.
The kit looks cool to me, as a beagleboard and beaglebone user, I wonder when TI will embrace 'standard' wireless spec(e.g. LORA, 802.11AH etc) instead of keeping using its own sub 1Ghz proprietary wireless solution?
Beagleboard also has its Jetson like AI board, https://beagleboard.org/ai-64, but Jetson just dominated that market.
> Beagleboard also has its Jetson like AI board, https://beagleboard.org/ai-64, but Jetson just dominated that market.
There is definitely a community effect everybody in the pytorch world assumes you can run cuda, a target that can only go with openCL will immediately limit how much you can leverage everything that is already out there from previous research.
It would be great to convince everyone to move away from proprietary stuff but that is not gonna happen quickly if at all.
This looked pretty cool until I found a price: ~$100.
Lots of cool features, and it's a beagleboard, so there will be actual support/documentation/source. But I'm not sure $100 is "affordable" for the SoC you get and the small 2GB of RAM.
> The price is exactly where it belongs without Broadcom subsidizing things so they can be given away.
A bazillion mobile phones with similar cpus, ram, AND screen, cameras and other sensors, battery, bla bla bla aren't being subsidized. Lots of them are at similar price levels.
As I mentioned in another comment, 2GB is the maximum memory size that all of the processors within the SOC can access, so it's a perfectly reasonable amount of RAM to spec for this SOC.
The Cortex-A CPUs can access more than 2GB but because that memory requires more than 32 bit addressing, the other processors cannot easily access it.
This is a common theme in similar TI SOCs. For example, the AM57xx SOC which are used on the Beagle-X15 and Beagle-AI can have more memory available to the Cortex-A15 than can be possibly made available to the DSP and Cortex-M4 processors. The Cortex-A15 has a special interface to the memory controller which enables extended address use beyond 32 bits where-as the other processors and subsystems within the SOC are all attached to a bus where 32 bit addresses are the maximum.
> The Cortex-A CPUs can access more than 2GB but because that memory requires more than 32 bit addressing, the other processors cannot easily access it.
What's preventing the 32-bit CPUs from accessing the full 4 GB of a 32-bit address space?
The main memory map places the DDR memory starting at 0x8000_0000 up to 0xffff_ffff in both AM62x and AM57xx. Below 0x8000_0000 are a bunch of other memory mapped devices and interfaces.
Additional memory beyond 2GB are all located above 0x1_0000_0000 address.
Before I tell you kids to get off my lawn, there was a time when development kits were thousands of dollars, and only if you had a good business relationship with a chipmaker.
TI actually had BeagleBoard (not BeagleBone) and PandaBoard for OMAP long before RPI came along. Those were nice, but still were close to $200. Probably $300 in today's dollars.
Yeah for a while before RPi and Arduino embedded/DSP dev hardware was pricey. I still remember when I worked for ADI that their “EZ-Kit” SHARC and Blackfin development boards were insanely expensive, >$500 each or so. The real kicker was that the JTAG emulator you programmed it with with cost thousands of dollars. Never made sense to me, I always figured if people were putting in orders worth millions, why not just offer dev kits and software for some nominal fee.
Someone later produced a cheaper Blackfin dev board called the “STAMP” and sold it for ~$100ish and worked to support uCLinux and a GCC backend. Picked one of those up and did a bunch of hacking in my own time, really fun stuff.
And before JTAG you had in-circuit emulators which could cost tens of thousands of dollars. And even today we're spoiled by Seeger JLink. The Lauterbach tools used to be the only game in town for ARM besides ARM's own stuff and it was all crazy expensive. But it was pretty powerful too.
And back in those days if you were a high volume customer you got all the development tools for nothing. But that didn't help startups and tinkerers at all. Hacking hardware in the early days was not easy.
No, this is what parts cost, don't let Broadcom fool you with the RPi SoC.
This TI AM625 is around $18 in high quantity. When you add in all the connectors and DRAM and the PCB/assembly it sure looks like a $100 retail cost is almost selling it for no profit.
Hmm, this is 802.3cg which is 10Mbps single-pair, which doesn't seem to be compatible with the 802.3da multidrop iot stuff, and definitely not the 802.3bw 100Mbps single-pair being used in automotive.
Whyyyyyyyyy, IEEE, do we have so many single-pair singletons floating around out there, none of which work with each other?
> Hmm, this is 802.3cg which is 10Mbps single-pair, which doesn't seem to be compatible with the 802.3da multidrop iot stuff
802.3cg supports multidrop as part of 10Base-T1S.
802.3da is a draft intended to enhance these capabilities with longer segments, support for more devices in a segment, and support for powered multidrop segments. It's far from final at this point so I wouldn't expect hardware to support .3da any time soon.
That said one of the main objectives of the .3da group is to be backwards compatible with .3cg multidrop networks. Obviously the enhanced features are not guaranteed to work with older devices, but .3da devices should always be able to connect to a .3cg multidrop network.
> Whyyyyyyyyy, IEEE, do we have so many single-pair singletons floating around out there, none of which work with each other?
They all have different use cases that rarely need to interact.
The 10 megabit varieties are primarily focused on being able to operate on existing wiring that was not intended for Ethernet use. They're intended to bring Ethernet in to environments where CAN, Modbus, PROFIBUS, etc. have long dominated with as little external impact as possible.
The faster varieties are mostly for adding high-speed ethernet to wiring harnesses in environments where using one pair over four pairs is advantageous, usually where weight matters like automotive and aerospace applications.
Either way, users are not expected to be mixing and matching single-pair ethernet devices in the same way as you would for "normal" ethernet. They're all still ethernet on top of the physical layer and can be bridged/switched to other varieties in the same way as any other varieties have been for years if someone wants to build a device with both kinds of ports. You just can't physically plug them in to the same cables.
> Either way, users are not expected to be mixing and matching single-pair ethernet devices
Which is precisely what made other Ethernet so powerful and rapidly dominant. I'm not disagreeing with you, just saying it's a shame.
Say I want to make an Ethernet-speaking sensor of some sort, the sort of thing that might be on CAN today. I now have to make multiple versions of it if I want to sell into all those markets, which I'm not likely to do in practice. Which means there will be fewer Ethernet options on the shelf in some of those markets, which means they'll remain CAN for longer. Which ultimately means Ethernet doesn't become as pervasive as it could if all those things worked together.
> Say I want to make an Ethernet-speaking sensor of some sort, the sort of thing that might be on CAN today. I now have to make multiple versions of it if I want to sell into all those markets, which I'm not likely to do in practice.
If it's the sort of thing that might be on CAN today, you'd put it on 10Base-T1S and call it a day
The higher speed varieties aren't even going to be used in the sorts of situations where you'd normally be plugging in random additional hardware. It's a point to point link within a specialized wiring harness, whatever is going on each end is generally going to be specific to that environment.
It's moderately annoying from a tinkerer standpoint to have to use adapters, but I'm really having a hard time coming up with real world scenarios outside of development/testing where it'd be useful to be able to plug a 10Base-T1L device directly in to a 1000Base-T1 link for example, or vice versa.
I guess I could see some utility in a dual mode device for the two 10mbit varieties that could either be on a shorter multidrop network or a long run point to point, but even there I feel like a lot of those use cases would be in building automation type infrastructure where at the end of most of those longer T1L runs you'd have a few devices and a bridge to T1S multidrop would make sense anyways.
802.3cg seems to specify 10BASE-T1S and -T1L. T1S is short range and multidrop. T1L is longer range but point-to-point. 802.3bw is 100BASE-T1 and is (I think) point-to-point. 802.3da seems to be working on enhancements to the cg spec.
It seems reasonable to me to have three standards here. They support rather different use cases. Also, 100BASE-T1 seems to be getting a bit less traction — for automotive and industrial uses, 10Mbps seems like more than enough, and improved reliability on less fancy cable seems like a win.
The BeaglePlay is 10BASE-T1L, which seems like a fine choice to me. -T1S is a bit short range to use for a house-wide network depending on the size of a house and how straight the wires are. Of course, for -T1L to be of much use, we need cheap switches, preferably powered with PoDL.
edit: a better end game would be for all the gadgets to have internal switches and at least two ports.
The BeagleConnect seems lost in the announcement but interesting in its own right. It looks to me like a well packaged Arm M4 with wireless, reminiscent of the M5Stack modules using ESP32. The twist is that BeagleConnect uses Linux kernel drivers instead of the ubiquitous Arduino library contributed code, if I am interpreting this correctly?
BeagleConnect™ uses the collaboratively developed Linux kernel to contain the intelligence required to speak to these devices (sensors, actuators, and indicators), rather than relying on writing code on a microcontroller specific to these devices.
Great to see SPE (ethernet) here, this is going to be an important IoT/industrial standard IMHO, and I'm not aware of any other hobbyist options. And also it seems they haven't chosen one of the seemingly proprietary/industrial/expensive connectors, which is great too.
And it has PoDL (PoE equivalent) too! Though at 5V/250mA, I think this is for the board to power sensors, not the board to receive power itself.
> And it has PoDL (PoE equivalent) too! Though at 5V/250mA, I think this is for the board to power sensors, not the board to receive power itself.
I dug through some documentation, and yes, it's PoDL source only.
I'm still holding out for someone to make a pair of devices: A is ethernet + spe + PoDL source, B is ethernet + spe + PoDL powered. Hopefully for not a lot of money.
It's hard to buy the first one when this board is only a little more expensive and comes with everything else (even if I don't need the everything else).
If I had circuit design skills and patience, I'd try to whip something up using the 'back to back' PHY mode, in theory, you connect a 10base-T1L PHY up to a 10base-T PHY, setup the proper 'straps', put in the right passive components, supply power, and that's it; no microcontroller required.
Kinda weird that I don't see any exposed gpio pins on the board? The SoC has "up to 170" gpio pins, and especially it has those fancy PRUSSes in there, so feels like huge missed opportunity to not expose any of that?
There is the mikrobus, grove, and qwiic connectors, all of which will be GPIO, I2C and likely (for Mikrobus) SPI as well.
The reason the SoC says "up to 170" as they are multiplexed with the ethernet, display and camera interfaces, so since this board has all 3 there are likely not many GPIO actually left to pin out
Yeah that's weird to me too; the Beaglebone's claim to fame has been acres of GPIOs with powerful PRUs behind 'em. Even if it needs some fine-pitch Samtec daughterboard to break 'em out, just putting some of those GPIOs on a connector _somewhere_ would be nice.
Nobody's gonna drive a CNC machine with this, that's for sure.
SODIMMs use a 64 bit wide memory bus. The TI AM62x SOCs only have a 16 bit wide memory bus. There exist modular memory which can work with narrow buses like this but it's not common or inexpensive. Most embedded SOC are meant to be used with a "memory down" configuration where the memory is soldered to the same PCB as the SOC.
Additionally, there's only 2GB of the DDR which is accessible to all of the processors within the SOC. The Cortex-A processors can use the addresses beyond 32 bits but because only 2GB of the DDR is within the first 32 bits worth of memory mapping, the other processors cannot easily access memory beyond 2GB.
$100 is an amazing deal when considering this as a development board or reference design to build a real product from. $100 is not that great a deal if you want a Raspberry Pi replacement. Different markets and different use-cases.
I do thoroughly enjoy my RPis, but even though we’re supposedly heading towards the shortage ending in late 2023, availability of the normal boards feels as it continues to dwindle further.
The A53 is about 1/2 - 2/3rds of the performance of the A72 *(depending on the task), so it’s no slouch.
At $100 it’s certainly not cheap, but the feature set of the board is packed. Moreover, you can buy one in a straightforward manner.
I didn't know about the beagle, but have been wanting to get a Rpi. What exactly does it failed to live up to? Is the beagle better in general or just for specific use cases?
It's interesting that TI has dumped the PRUSS from this part of the Sitara family and gone with a Cortex-M4 as the coprocessor instead. It's certainly a more comfortable development environment.
I also like the single-wire ethernet interface. That's going to be really useful looking forward.
It depends on what you want to do in terms of which type of coprocessor is more useful. The PRUs are quite amazing in what they can do, but the development environment is let's say less than ideal. The AM6xx series SOCs do have the PRU subsystem in them along with the Cortex-M4.
> but the development environment is let's say less than ideal.
I agree - lots of wasted potential there. I wish they had implemented an Arduino plugin for the PRUs, as well as a library for both the PRU side and the Linux side for using shared memory with common patterns (FIFOs, etc.).
Something newbie-friendly like that would've made the Beaglebones way more popular, IMO.
> the development environment is let's say less than ideal.
Developing C on Linux is less than ideal?
I suspect you are making the wrong comparison. Using a PRU generally lets me skip an FPGA. That's huge. Now, my firmware team can do development in C on a Linux machine rather than Verilog/VHDL in some horrible vendor (Xilinx/Altera) toolset.
If you're programming a PRU, you need to know WHY you're programming a PRU. Otherwise, why wouldn't you just use the main processor?
Although there is a C compiler for the PRU, the last time I checked it produced quite less than optimal performance compared to hand assembly. The instruction set is pretty simple so it’s not horrible to write by hand. Maybe they’ve made big strides in the C compiler capabilities recently?
Not only is the instruction set simple, but the clock-per-instruction cost is deterministic, so assembly code is ideal for real-time I/O. Just like GP, we found that we could often use a PRU in place of an FPGA and dramatically cut development cost (this was for very small production series).
One use case for C is communication with the CPU (remoteproc stuff). We commonly had one PRU handle CPU communication with trivial C code while another PRU on the same PRU subsystem was coded with assembly to handle real-time I/O.
Looks like an interesting open source SBC, with a wide variety of connectors for sensors and other devices/connectivity. At $99 it’s definitely not competing based on cpu/memory.
It’s in stock at all 3 distributors they link from the product site.
This is the least expensive device I've seen with single pair ethernet (specifically 10Base-T1L), so that's pretty neat. And it's a source for power over the single pair too, which is neat. I have yet to see a PoDL powered device though.
If I can finagle some power at the remote end, two of these could get me 10M ethernet to my gate controller where I don't have quite enough pairs to do what I want.
It's more than that: This whole device with 802.3cg and PoDL as a side-feature, but oh by the way it has a whole CPU and radios and eMMC and stuff, is cheaper than most 802.3cg dev boards that're just the MAC/PHY and you still need to glue 'em to a computer of some sort.
That alone justifies it for a lot of applications, and I expect a PoDL injector to emerge from the DIY scene in a matter of days.
I've been thinking of picking one of these up to make a small hand held device for emails, maybe video calling. Does anyone have experience doing these sorts of projects with the beagle?
