BeagleV?

I got a mail message from seeed that introduced the BeagleV.

Although I am very hopeful for a complete opensource hardware and software platform, I noticed that the pin-layout and the compatibility of the ARM-Beagleboards has been abandoned.

I also noticed on the specs that the GPIO pins could be used for any kind of communication protocol, be it UART, SPI, SDIO etc.

I am currently using 3 UART ports on a BeagleBone to communicate with some peripherals.

Would that still be possible in the new design?

I also noted the RS485, or Canbus was not described in the IO.

Can anyone involved in the design comment on these observations?
(Why abandon the old pin layout, how to implement three UARTS or 2 I2C’s, and why no CANBus availability)

Kind Regards
Johan Henselmans

https://beaglev.seeed.cc/
seems to say that

All GPIOs can be configured to different functions including but
not limited to SDIO, Audio, SPI, I2C, UART and PWM

so it seems it can handle your application

This looks like another effort to use a RISC-V processor on a board so it will be different than an ARM core.

Jon

Looks like everyone is talking about it even Jason:
https://www.youtube.com/watch?v=9MJl7gCTAcM

https://www.tomshardware.com/news/beaglev-riscv-announced

https://blog.adafruit.com/2021/01/13/the-risc-v-powered-beaglev-board-announced-riscv-beagleboardorg/

https://arstechnica.com/gadgets/2021/01/seeed-and-beagleboard-team-up-to-provide-a-new-risc-v-based-linux-pc/

Jon

Sorry, one more:
https://beagleboard.org/beaglev

Jon

BeagleV is something new in addition to BeagleBoard and BeagleBone offerings from BeagleBoard.org. It is meant to address the needs coming from the RISC-V community for a low-cost development board, ultimately with a path to production. We still have a roadmap for BeagleBone!

So, I’ll share what I should have shared before, but am still ironing out details on schedule as we are executing this…

There’s a minor tweak to BeagleBone AI rev A1a to rev A2, but I’m not sure if it’ll go into full production as we have started a rev B with the TDA4VM device from TI. It jumps to A72s and has better software support for the AI accelerators.

One project I’m most excited about is an update to BeagleBone Blue (rev C, rev B used the smaller SIP but had unrelated issues that never got resolved and therefore never got released). I need some more stuff to be released from TI to share more details there, but the motor drive capability will be boosted to enable direct drive of BLDC quadrotors and 3-phase steppers.

And, I’m very, very excited about BeagleConnect technology being worked on at https://github.com/jadonk/beagleconnect based on TI CC1352. This still has a long way to productize, but it is really interesting tech!

We also have some cool stuff being worked by BeagleBoard Compatible makers in the BeagleBone space. For that matter, SeeedStudio BeagleBone Green Gateway hasn’t been out very long.

Anyway, the short answer is BeagleV an in-addition-to-BeagleBone thing, not moving away from it.

If interested in BeagleV, please register your interest at BeagleV.org. If you already did so with Seeed, no need to replicate.

Hi Jason

The idea on the BBAI is change from am5729 to TDA4VM ?

Best regards

15.4 support that’s huge. Is the TI SUB GHz radio on a cape?
Our neighborhood gas meters were recently updated with a product I worked on that product had an older TI radio and was based on a Renesas controller.
This alternative positions TI to possibly offer a turn key replacement for that product beyond porting the app to Linux.

TI support is way way better than Renesas and that product had reset issues I strongly suspect were the Microcontroller

Hi Jason

The idea on the BBAI is change from am5729 to TDA4VM ?

Yes.

I think the things to figure out are if we can:

  • Increase RAM

  • Add CSI signals/connectors

  • Bring PCIe over Type-C as an alt mode (some devices are just better interfaced over PCIe than USB)

  • Add USB-SS to the Type-A connector

  • Add an alternate power connector (capes and USB shouldn’t be the only way to power, but barrels are too big for this design)

15.4 support that’s huge. Is the TI SUB GHz radio on a cape?
Our neighborhood gas meters were recently updated with a product I worked on that product had an older TI radio and was based on a Renesas controller.
This alternative positions TI to possibly offer a turn key replacement for that product beyond porting the app to Linux.

Are you talking about BeagleConnect Freedom? I am working on a cape that would include the CC1352 as well, but, for now, you’d connect the BeagleConnect Freedom to any Linux board over USB and run the wpanusb driver (still needs to be mainlined). So, the BeagleConnect Freedom can act as either a device or a gateway. Right now, they are 2 different firmware loads.

The TDA4VM doesn’t have PRU’s. Does that mean use of PRU’s is now “deprecated” and discouraged?

Dan

I have the same question as you Daniel,
the PRU in my opinion is one of the most killer feature of beaglebone and I’m already using BBAI Pru and the 4 PRU’s on AI is extremely welcome.
Jason, any chance to have PRU with this revision 2 BBAI board?

I was looking the TD4VM and there is 2 prus :slight_smile:

Yes, what Vinicius said:

From TD4VM doc at: https://www.ti.com/product/TDA4VM

7.11.5.24 PRU_ICSSG
The device has integrated two identical PRU_ICSSG subsystems (PRU_ICSSG0 and PRU_ICSSG1). The programmable nature of the PRU cores, along with their access to pins, events and all device resources, provides flexibility in implementing fast real-time responses, specialized data handling operations, custom peripheral interfaces, and in offloading tasks from the other processor cores in the device.

That TD4VM is a real beast. I really look forward to being able to use the 64-bit ARM cores as the 32-bit Linux world seems to be fading a bit. I also use the PRUs for low-level I/O, need that hard real-time access.

I would really like to see a bunch more I/Os available. The Beaglebone format is nice size-wise but really seems to constrict access to more of the IO goodness.

Maybe a carrier-board format similar to Pi Compute or Jetson?

Interesting…. It’s not in the functional diagram. Awesome that they are there.

Dan

Yeah, the PRUs are there, but hidden I guess for “support” reasons. I think TI isn’t offering the firmware loads to support industrial protocols on this chip to the public. TI already makes a carrier board SOM. I want to make sure those people who have invested in the BeagleBone form-factor get pay-off with upgraded processing. I’m sure there is lots more that could be done with the TDA4VM. I’m going to try to see if I can at least get a fairly high-speed ribbon cable brought off, but things like PCIe will need to be muxed across type-C in this form-factor as best I can tell.

I totally get it on the Beaglebone form-factor and continuing support for it. I have Beaglebone AI format-type solutions I have to support on the software side and the Mech. and Elec. engineers in my group would probably devise some kind of torture system and install it in my cubicle if I pushed a radically different form factor “just because”. I was really only parroting what I’ve observed with the other groups like RPi and the Jetson stuff - they seem to be partly going for an industrial direction in a “mass quantities” kind of way, doesn’t mean that’s what the Beagleboard group should do at all.

The possibility of expanded I/O would be great to see and PCIe would be fantastic even over a “non-standard” connection. I’d also add a vote for a populated JTAG connection, or at least one that one that isn’t too involved to install.

I totally get it on the Beaglebone form-factor and continuing support for it. I have Beaglebone AI format-type solutions I have to support on the software side and the Mech. and Elec. engineers in my group would probably devise some kind of torture system and install it in my cubicle if I pushed a radically different form factor “just because”. I was really only parroting what I’ve observed with the other groups like RPi and the Jetson stuff - they seem to be partly going for an industrial direction in a “mass quantities” kind of way, doesn’t mean that’s what the Beagleboard group should do at all.

The possibility of expanded I/O would be great to see and PCIe would be fantastic even over a “non-standard” connection.

Really pushing Type-C for that, though it isn’t daughterboard friendly.

I’d also add a vote for a populated JTAG connection, or at least one that one that isn’t too involved to install.

Choosing TagConnect for future boards. A bit more expensive to add an adapter, but at least no soldering.

BeagleV 's pin layout is very similar to Rasaberry Pi

在2021年1月13日星期三 UTC+8 下午9:39:34johan.he...@gmail.com 写道:

yes, you are right. this is the first thing that i pointed out.