BeaglePlay from BeagleBoard brings fun to building with computers
beagleboard.org
beagleboard.org
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.
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.
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.
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.
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.
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 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.
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.
The price is exactly where it belongs without Broadcom subsidizing things so they can be given away.
Of course, since Broadcom is no longer subsidizing things, mere mortals can't get an RPi anymore.
But, don't worry, Broadcom is happy to give them to companies like T-Mobile now that all the suckers^W users created an ecosystem for them.
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.
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.
What's preventing the 32-bit CPUs from accessing the full 4 GB of a 32-bit address space?
Additional memory beyond 2GB are all located above 0x1_0000_0000 address.
I can fit a home server with some to spare to 512MB.
Whyyyyyyyyy, IEEE, do we have so many single-pair singletons floating around out there, none of which work with each other?
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.
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.
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.
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.
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.
https://docs.beagleboard.org/latest/boards/beagleconnect/fre...
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.
https://www.methodedatamate.com/10base-t-to-10base-t1l-media...
But it doesn't look like 'commodity' cheap - it's probably several times the price of the beagle...
https://www.arrow.com/en/products/10base-t1l-mc/einfochips-l... at $85.75
https://botblox.myshopify.com/products/speblox-long at $175
https://www.ti.com/tool/DP83TD510E-EVM listed as $150, but $200 from Mouser
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.
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
In the block diagram I don't see any of those exposing GPIO.
Nobody's gonna drive a CNC machine with this, that's for sure.
2GB is very limiting for an otherwise flexible platform. It will take some dedication of resources to get the quoted GPU modes, for one.
The utility increase per memory unit compared to the cost increase, with a base price of $100, really makes me scratch my head here.
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.
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.
Unlike RPi: https://github.com/raspberrypi/documentation/issues/2233
"The Raspberry Pi is not open source. However, reduced schematics are made available on a best efforts basis."
I also like the single-wire ethernet interface. That's going to be really useful looking forward.
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.
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?
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.
It’s in stock at all 3 distributors they link from the product site.
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.
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.
1 core 1Ghz and half a GB of RAM is starting to show its age real fast.