Lutetium-
All About Beagle Board HackChat Transcript Pt.2
10/13/2017 at 20:54 • 0 comments@AdityaPrakash23 I can clearly say yes because you say "very basic". The big question is how basic is basic. A BeagleBone can do face recognition using the OpenCV demo code (unoptimized) at about 5-10 frames per second. Lots of room to optimize, but that is probably a reasonable proxy for the type of ML algorithms that you'd run. Running a neural net algorithm doesn't have to be crazy CPU intensive, but you have to look at how many nodes you need. Cloud training is clearly making things much easier.
I see labor as a major, small-time effort in the expensive range. I have tried backing US mfg. but prices have soared. I can tell, esp. in my state. Louisiana has been an oil field marketplace. I am sure you have oil field related markets for embedded systems.
From Jacob : "The barrier of entry for PRU development seems pretty steep, any recommendations on getting started with PRU development?"
@Seth lots of factors to roll in this discussion. I think the fact that we can make PocketBeagle in the US cost-effectively such that everyone in the chain gets a bit of profit and not selling as a loss-leader is a pretty big statement.
yep!
@Jason Kridner So a basic neural net might work?
yeah. As far as starting with PRU... My blinky LED example is at https://gist.github.com/jadonk/2ecf864e1b3f250bad82c0eae12b7b64 it uses the remote-proc stuff rather than UIO. I think it is pretty easy, but I know it really needs to be even easier.
I get so "up and at 'em" with USA mfg. These days, it is sort of a touchy subject. So, back to the bone!
@Chris Gammell did you catch that? :-D anyway, botspeak is a beginning-user's assembly language.
From @Sai Yamanoor : "Is it possible to program the PRU on the Beagle in an Arduino like environment? I learned about PRUduino. WOuld I be able to use third party libraries as-is or do I have to port them to use it?"
"Getting to PRU"
I tried to gather some starting stuff at bbb.io/pru, but it is still a bit heavy.
@Seth I read you on that. Schiit Audio pulled it off but it really depends on the product. As you said back to it.
Yep.
my next plan is to create a botspeak interpreter as a kernel service, unlike the python attempt done by previous GSoC student. then, you can simply "cat" high-level assembly into a socket to get code for the PRU. nd then I'll create a little Firmata daemon for it. What's important to me is to make something that is easy to get started, but then is really practical for making a real product.
zakqwy "Don't be a PRUde -- BBB programming with Chris" sorry I'll stop
Something I think I kinda missed the mark a bit still on BoneScript.
So Jason, I have been on the google groups and on the #beagle on IRC. I have been overwhelmed by the support of the products produced by the beagleBoard.org people.
And you start the processing with a marble rolling down a ramp turning on a fan that blows a USB drive into a port
Oh yea...are you still going to produce BoneScript more?
@Seth in a good way?
Yea.
@Seth yes, I'll still do BoneScript updates....
In a good way...I have had all sorts of assistance, even when I did not deserve it.
though I've floated the idea in small circles to make the RPC-server an installable rather than pre-installed component.I think JavaScript is a great development language (/me ducks), but most Beagle users never really go down that path. I need to do things the Beagle community loves.
I'm not against Javascript. I even use it for ESP8266 stuff
For @Sai Yamanoor , I think that Firmata covers a lot of Arduino use cases.... I'd love to have a full Arduino-style library for the PRUs and the StarterWare stuff provides a good starting point....
@zakqwy it's PRU-dent to have more Bone-s for your audience. They made Beagle-lible though.
Just a few more Q's before open discussion ('til @Jason Kridner 's gotta hop on a plane) Another from @Sai Yamanoor : "When can I expect to be able to use the bonescript's GPIO capabilities on the Pocket Beagle?"
I think Python is better for hardware control, e.g. ask our MicroPython expert @Radomir Dopieralski
I will try but I am very inexperienced for now.
*sigh* Getting BoneScript working cleanly on PocketBeagle always feels a week away for me. Bug me a couple more times and I'll just do it to stop you from bugging me. :-)
@Soul_Est there's that sharp pain in my head again
Python is good. I enjoy typing software in python. Yea boy! Bug him! We need it.
It really isn't much, just that there's a bunch of other documentation to create too.
From @Soul_Est : "To follow-up on Avner's question, will standard BeagleBones and PocketBeagle see a more energy efficient ARMv7 or ARMv8 CPU coupled with an equally efficient SGX GPU sometime in the future?"
I'm very interested in ways we can take what we have on BeagleBoard-X15 and put it into a BeagleBone-like product. Contributions welcome. Some progress is made, but I've probably already said too much.
I got one last question for this group. Does anyone use the Motor Bridge Cape for the BBB? Sorry. I like motors and electromechanical mowers.
@Seth GHI and Embest are both working on revitalizing the Cape offerings, including motor drivers. Tindie also brought back the Beagle store.
Cool. I will look into those Capes when they come out.
Last but not least from @Feed N Tweet : "If I wanted to drop Linux, what SDK do you recommend to program the ARM AM3358 natively?" StarterWare is the most logical place to grab a bare-metal programming library. Also, there's a ton of peripheral support in u-boot and they actually have some framework for adding programs that use that infrastructure. StarterWare is a TI software library and u-boot is an open source bootloader. both are technically open source. there are a lot of great RTOSes out there, proprietary and not. QNX, etc. here's also other great operating systems, like FreeBSD/OpenBSD. I just like the collaborative nature of Linux. pretty amazing all the code that gets managed in there. I mean, why use stuff like MRAA when most sensors already have Linux drivers?!?
Gentoo?
Jason Kridner Gentoo is typically on Linux, though it'll run on others.... not really bare-metal. it is more about managing userspace.
Yeah i've had surprising good luck with devicetree stuff lately. Lot of people working on the same problem. The 1% who need bare metal performance are also probably capable of doing the necessary work
Thanks so much for joining us and being generous with your time @Jason Kridner ( & beagleboard.org friends )
k, I better run. hope this was useful. hope I don't see my words twisted too much later. ;-D
Happy to see everyone's excitement! You can find more BeagleBone projects to follow on Hackaday.io https://hackaday.io/list/3562-beaglebone-projects
-
All About BeagleBoard HackChat Transcript
10/13/2017 at 19:42 • 0 commentsJason Kridner Gerald Coley and I started up BeagleBoard.org as a lunch conversation in 2007. Both of us were TI employees at the time (I still am), but we wanted to make OMAPs (mobile phone chips) more accessible and I suggested making something that helped the Linux community was the way to go about that. I started programming when I was 8 when my mom got a TRS-80 to run her home business. I then spent every dollar I could get at Radio Shack building "Electronics Mini-notebook" projects. This little BeagleBoard.org skunkworks project seemed like a great chance for me to help make sure other people had that kind of experience.
Thank you for joining us @Jason Kridner !
Love it when general lunchtime convos turn into products!! good job sticking with it!!
Just a reminder to all that we're prioritizing the questions on the sheet -- off-topic discussion can start once those are through, time permitting :)
@Jason Kridner Does TI provide any help or resources for you, or did you do this the two of you on your own?
Ready to get started, @Jason Kridner ?
@Shayna sure.
ason are you me?
Those mini-notebooks were GREAT!
Hehe
First one's from @Daren Schwenke "Why oh why are not more people using the beaglebone?"
@Norse I got my boss to put up $25k for the first board layout and prototypes.
Gerald and I had a theme in the early days....
it was "keep TI out of TI's way"
so, we always tried to keep it independent.
Starting funding came when Digi-Key placed a purchase order for the first 10k boards, and the TI reputation obviously helped with that a lot.
Over time, we launched the non-profit BeagleBoard.org Foundation....
Reminder that additional questions should go on the sheet or saved for open discussion. Don't forget your project ideas! https://docs.google.com/spreadsheets/d/17HGpRljQE87t50rX47U-BkkFI61FZJWCDueec7KckKQ/edit#gid=0
then, we eventually altered the leadership and now I'm the only TI employee on the board.
we have a 5 member board (all volunteers) and a paid executive director.
Good way to prevent tunnel vision
pretty much everything else is either paid for by TI contributions to the community, manufacturer contributions to projects or Foundation sponsored contracts.
My role is as the community manager, website hack and general product definition.
Ultimately, the less of me the better and I really do try to make this a community project.
Any thoughts on @Daren Schwenke 's Q?
Activities like the Google Summer of Code and contributions from community members like @Kumar, Abhishek and @Michael Welling really keep things going.
Anything else I should say about me before going into questions?
Yes, favorite color?
You could layout the virtues of the platform, such as PRU's and such.
Guess I could say I'm a 25 year veteran of TI and have done everything from ASIC design, product engineering, audio/video codec software, board design and I dunno.
@Daren Schwenke k, I can try to give an intro to what makes BeagleBoard.org "products" interesting.
We started with mobile phone chips, but moved to more industrial chips over time.
The most popular board is BeagleBone Black that features an AM3358. That's an industrial focused ARM processor with a good mix of peripherals that makes it nice for building electronics prototypes and products. the PRUs are the generally killer feature that keeps it really relevant today, even after it has been out since 2013. they are 2 200-MHz RISC microcontrollers with a subsystem optimized for creating software-based peripherals. that means I can interface up to the types of things I'd connect other microcontrollers to, but they are faster than most and provide direct access to shared memory with the ARM processor. things like @Kumar, Abhishek 's BeagleLogic logic analyzer done in software show off a bit of what is possible. people make products enabled by the PRUs to do things like machine control (3d printers, CNCs, etc.), LED control (see LEDscape) and many others. having everything in one chip lets you do things you can't do in an R-Pi + Arduino configuration.
Springboarding of Daren's question/observation, does that mean the BBB is really popular from Jason's perspective (industrial apps) but doesn't get as much exposure in hobby circles?
@Jason Kridner so I could do a lot of PWM with them, for instance?
@Garrett Mace that was going to be part of my answer to one of the first questions.
Hey Jason, I'm new to the beagleboard group. Could you tell us what's up next for beagleboard? I have been on an esp kick lately, any multi core units coming out?
basically every pin could be PWM at crazy speeds. Yes.
GET IN LINE BUDDY https://docs.google.com/spreadsheets/d/17HGpRljQE87t50rX47U-BkkFI61FZJWCDueec7KckKQ/edit#gid=0 :-)
Hi @specialed08, please put it on the question sheet https://docs.google.com/spreadsheets/d/17HGpRljQE87t50rX47U-BkkFI61FZJWCDueec7KckKQ/edit#gid=0 Hah, what @zakqwy said
@Radomir Dopieralski in addition to having 8 pure-hardware PWMs exposed on BeagleBone Black, people have added another 25 done on the PRUs to give you 32 PWM outputs on just that board.
/me thinks he got the math wrong above.
k, I'll start with the Qs.
Yes, I hate to cut off good discussion but let's stick to the sheet for guidance for now.
So, "Why oh why are not more people using the beaglebone?"
I think we lost a bit of mindshare with Pi marketing, but a lot more people use them than is commonly known.
The manufacturing licensees of BeagleBone Black (we license the brand, but the design is open hardware) make more now than ever. The monthly production figures float between 12k and 20k units. over 1 million BeagleBone Blacks have been sold.
zakqwy !! that is an amazing achievement!
Jason Kridner By estimates, about half of those are going into small volume industrial automation activities. Larger volume stuff would just end up respinning the board.
wow, that is really amazing
For some reason, people like to talk about using Pi, but use Beagles to get things done quietly.
That is a huge win
I noticed the latest Dremel laser cutter embeds a SeeedStudio BeagleBone Green. Several 3D printer companies embed BeagleBones.
Right
(apparently there is a big one in China... don't even know who) We get put into things like the JPL prototype Mars rover that they drove under the polar ice cap.
Perhaps it's because (besides the pocketBeagle) the price vs Pi just seemed that much higher?
very cool. mind if we move on to the next?
I would hesitate to embed a Pi due to availability, and tenuous nature of depending on a heavily subsidized product. Good reason to use Beaglebone
I think the price perception matters, but I think more importantly we are perceived as a more serious tool.
From @Blecky : "Where do you see the future of end user SBCs going? Would you consider putting an FPGA on board like the Technologic Systems boards?"
Mars rover means that you have radiation hardened versions?
Thanks @Shayna
That and feature set and computational power. The BeagleBones will always have better I/O and control.
From the PocketBeagle, you can see that I think a big part of the future of SBCs is making them as easy to use as microcontrollers.....
The BBB's on-board storage of the OS pulled me over from RPs.
Jason Kridner part of that is in the packaging.... working with high-speed DDR, etc. is a PITA. I think we are going to see better software for people on top of Linux that makes Linux less visible, but also more people starting to do things in Linux rather than hacking around with userspace oddities. So, ease of use improvements, but also more creative integration to look more like "something".
what I don't like about Linux is that it is not hard realtime, or does RTLinux run on it?
General purpose SBCs are great, but integration takes work. I think it is a nice feature of all the BeagleBone "clones" that you can have a common software base, but also a greater level of integration into some kind of activity. (referencing mostly Blue)
@Frank Buss yes, we run RT Linux as an option.
nice
anyway, FPGAs...I have a love/hate relationship with FPGAs. There is a project @Michael Welling did called "BeagleWire".... and that is one of at least a dozen efforts to tie an FPGA to a BeagleBone. There's an SDR focused one (Kiwi) and others.... names coming slow to my head. I'd be open to the idea of doing more, but I think we have to figure out the "why" that includes as much community as possible. As of now, the cape add-on boards make a nice approach. @Shayna next Q?
Next up from Marc : "Any chance the octavo chip is going to be cheaper than say a regular beaglebone green? Because for a commercial product it currently does not really make sense to me to use the octavo solution."
put a nice big FPGA in the micocontroller, like the Zynq 7000
The Octavo Systems guys have their own pricing strategy.... as of now, they publish pricing on the OSD3358-SM used on PocketBeagle as $26.5 in 1000 unit quantity. I've heard Greg over there say that they will be "competitive with discrete pricing"... so I'd take that as a positive of making the price more accessible.
yeah, I'd noticed that weird pricing.
From @Bharbour : "Is the I/O management / Cape Manager scheme stabilizing? I designed and built several capes, but after 3 major revisions in a couple of years, I walked away rather then spend all my time tracking the I/O definitions."
Is the Octavo stuff connected with TI or is it a separate company?
My strategy for BeagleBoard is to try to get really competitive prices on components (yes, it helps to work for TI, but I try to help other community projects too), but I never want to source anything for BeagleBoard.org that the community can't get on their own in some rational way.
Octavo Systems is a start-up from ex-TIers that I know and admire.
It looks like a hard product to set up. I'd bet the price comes down as setup costs are paid off and yield rates improve
@Garrett Mace sounds like a good appraisal.
I think the real possibility there is to actually make something much cheaper, since you are only packaging once instead of 4 times.
Did I answer the Octavo Systems pricing question well enough? I mean, it is approachable, but start with a PocketBeagle and see what you can do with that first. At least for me, I think we've put something compelling together. Anyway, SeeedStudio BeagleBone Green is around $39 and BeagleBoard.org PocketBeagle is around $25, so you can get started pretty cheap.
Next up was @Bharbour And that is: "Is the I/O management / Cape Manager scheme stabilizing? I designed and built several capes, but after 3 major revisions in a couple of years, I walked away rather then spend all my time tracking the I/O definitions."
@Bharbour the stabilizing approach is to utilize device tree overlays in the u-boot bootloader. for folks that don't know.... device tree is a way to describe to Linux your system. Linux for ARM systems used to be dominated by these C files that had to be rewritten for every chip and every board. and they had to figure out how to work together without breaking. Device tree was a mechanism already in use by PowerPC systems and Linus Torvalds said he was done bringing in all these crazy C files for all these ARM boards. BeagleBoard was already there before device tree, but we've always tried to be good mainline citizens. And when cape add-on boards needed to change the configuration based on having different hardware....
creating your own device tree and configuring and compiling a custom kernel version, is not easy
well, we decided that overlays that modified the live-running device tree was a good way to go. @Frank Buss exactly. For those not too familiar with the kernel, it was both a confusing syntax as well as they didn't know what they should be configuring (because they couldn't read the kernel source well).
From @hansober : "Any plans for moving the standard BB boards to a faster CPU? Any chances of a Beaglebone 'breakout board' that breaks out ALL of the pins of the Octavo SIP? Any boards in the pipeline with an FPGA or auxillary MCU for more PRU-like realtime control?"
So, Charles Steinkuhler, who did a lot of the LinuxCNC/Machinekit development, started to use a tool that Pantellis Antoniou had developed called "Pinmux helpers" to give control back to userspace and not require device tree overlays for something simple like enabling a peripheral that could be enabled by default and then setting the pinmux. guess I should wrap device tree up and say, yes, it is stabilizing. use pinmux helpers and do the overlays in the bootloader if you need them, rather than with CapeMgr. @hansober: we already have BeagleBoard-X15 (https://beagleboard.org/x15) which is a much faster processor with some pretty amazing specs on I/O.
But there seems to be a lack of readable examples for how to use the device trees. Obscure syntax needs some explanations and 'how to use' examples.
The price point puts it at more "serious" developers and I don't think it is much of a secret that we'd like to do some things to make it more accessible. howdy @MarkAYoder ! BTW, @MarkAYoder is one of our board members. :-)
@gh78731 let't talk more device tree later.
four PRUs! wow!
Something like an explanation of what is going on and what the options are to fill in fields for the device tree would be a big help too.
Hi @MarkAYoder
I'd like to try to start being more open with our development process and our community. We already get a good amount of development on both software and hardware coming from the community... and it helps to be open hardware for that.
How can one get involved? I find the mailing list to be cumbersome?
@Sai Yamanoor the github repos are another interface point that can be more directed. @Sai Yamanoor there's also the IRC.
@Bharbour there's a folder called dt-bindings in the Linux kernel that contains useful information about the device tree.
For those really serious and clearly not needing hand-holding, there's also some more private developer lists. Only serious users need apply.
Ready for next did you have more to add for @hans-ober ?
is the BeagleBone all open, so every register etc. is documented? Raspberry Pi had a bad history for this, only recently opened their GPU registers for hobbyists
ie., I don't want to answer "how do I create a device tree overlay" on our developer list.
@Shayna ready.
agreed
From @Soul_Est : "How was the decision made to include the
All BeagleBoards/BeagleBones are 100% open hardware with full non-NDA technical reference manuals on the processors used.
cool
Hi Jason! sorry I am just lurking while at work, but I'm pretty excited about the tiny Octavo ... really hope to roll my own Beagle at some point :D
@Soul_Est the process I went through on the PocketBeagle was mostly to leave the LCD lines used for bootmode selection and the Ethernet MII pins alone and then grab as many spare PRU pins as available. The folks at GHI also encouraged me to provide mikroBUS Click compatibility, so we support 2 of those modules on PocketBeagle. Robert and I now have stacks of mikroBUS Click boards we are going through the process of testing. https://github.com/beagleboard/pocketbeagle/wiki/mikroBus%E2%84%A2-Click-Boards Oh, I also left the eMMC pins untouched.
Is the Pocket Beagle similar to the CHIP Microcontroller?
@Soul_Est my goal was to try to expose the pins that someone would have likely chosen to use on a BeagleBone Black cape.
Just a reminder that discussion questions can be found on this sheet. There are quite a few, so we'll have to keep things moving :) https://docs.google.com/spreadsheets/d/17HGpRljQE87t50rX47U-BkkFI61FZJWCDueec7KckKQ/edit?usp=sharing
@Soul_Est did a quick check with the Bela.io cape and we should be able to support it with a single-line software change on PocketBeagle!
@Cornix Shelford see @Shayna 's comment, because I want to answer.
Next up from @zakqwy : 'I grabbed a couple of the 256-ball Octavo SiPs with my last Digi-Key order. Assuming I get all the bits wired up correctly (that is a big 'if') is getting the thing working really as simple as explained at https://beagleboard.org/getting-started ?'
oh, wow, the question list grew quickly at the end...
Ah understood. Thank you for answering that for me.
(he's going to dead bug it too)
I was pacing myself on the 6 or so questions that were there this morning.
Yes, folks are rightfully very excited. So forgive me for being pushy ;)
@Jason Kridner you can come back for part 2 and @Kumar, Abhishek is also going to host a chat pretty soon :)
@zakqwy the on-chip EEPROM is a thing to remember....
Yeah, that would be super
u-boot looks for the EEPROM to specify which device tree to load at boot. You need to write to it before you can just grab-and-run a latest-images release. n PocketBeagle, we tied a GPIO to the EEPROM write-protect line. I've got a hacked version of u-boot that defaults to PocketBeagle, ignoring the EEPROM.
I've got the same for BeagleLogic standalone as well
Hmm.. but I assume writing the EEPROM is fairly straightforward if you have its pins broken out?
we then program the board ID and serial number over USB. https://gist.github.com/jadonk/809337ed8435cdc25f99887746550ed2
@zakqwy I just write it using the processor and the hacked u-boot.
next Q.
Ah, I see. Thanks !!
From @Norse : "What modes can the SPI busses communicate with? (Raspberry Pi has two SPI, but only SPI0 can communicate over all four modes)"
@Norse pretty sure it all modes. ve seen a quirk with SPI0 that some devices kinda look like SPI flash devices.... and because the SPI flash boot mode is enabled, you can hang the board on boot if it looks like flash, but doesn't have a good boot image. I'd have to look up the different modes, but it is a very flexible SPI module.
on a Parallella board I just memory mapped an IO area in a custom driver to access my FPGA functions from user space, no need to do complicated device trees etc., but of course, that's not the Linux way of doing things :-)
From @DrivenMadz : "Would a beagleboard work for a mobile kismet/gps/debug logger?"
Thanks! WIth open docs this seems easy.
I've been hacking a fair bit with SPI TFT displays and the FLIR Lepton 3.
uh, thats what I'm doing =)
cool :)
@DrivenMadz yes. I mean, you'd need to be more specific, but connecting to a GPS and then connecting to a cellular modem are, from my perspective, fairly simple tasks. ...and that would be for any of the boards for that matter, even PocketBeagle. tried first with the Hologram.io Nova without problems. https://gist.github.com/jadonk/db300dadabe0b75dc62e39041dd66da4 <-- Nova
Perfect, i was shooting for super mobile :)
Next up is from @Hulkco, though you may have touched on this with the first question : "Do you have any plans to make the Beagleboard as well known and used as the Raspberry Pi?"
Perfect link , Thank You !
I guess would need some marketing joke to make it more known, like the unobtainable Pi Zero
@Gustavo Reynaga I think it is important for the community to have a big stage, so, to some extent, yes. Certainly at least bigger. I think we have to look at where we bring real solutions to real problems. I think robotics is one of those areas where very many people can get engaged and we provide a superior solution.
Pi Null
:-D I love what R-Pi has done for our community, but it has made some false promises or expectations. My personal plan is to outlive the hype. nd do have fun doing it.
Okay, @Christopher G. Stanton wants to know why you prefer IRC over other chat mediums, but I think that might be a better one for later ;)
From @mumi : "What's your favorite way to build embedded linux for the Beaglebone? Buildroot? Yocto? Other?"
There is something real there and I'd like BeagleBoard.org to be part of the real solution to making embedded systems accessible and make programming/electronics part of everyday literacy. @mumi my favorite build system for Linux is Gentoo. but, for Beagle, easy answer is Debian. and the Free Electons guys are pretty much genius caliber folks, so I won't argue with them. :-)
I think massive, concentrated focus on the PRU is the best way to outshine the Pi. BeagleBone really is better for hardware projects
^
The Ubuntu how-tos pretty much work on Debian and it has a great community.
@Garrett Mace , @Benchoff +1 :-D
Yes. I +1 on the PRUs
the LD Graphy project shows a good use of BBB PRU where a lot of other projects would use SBC + Micro
Yocto is great for pro projects where reproducibility and license management are paramount. I personally plan to do much more with Buildroot for ram-based, 100% volatile systems. but, for the every-person, Debian is an easy answer.
From @Robert Marosi : "Can the UART/encoder/servo/DC motor/etc. pins of the BBBlue be repurposed as GPIOs?"
@Robert Marosi yes. I'm not sure if we've put the config-pin/cape-universal/pinmux-helper hooks in for all of them to be done trivially, but, if you need help enabling any of them as GPIO, we can help you do that. except for DC motor... those aren't processor pins, they go through motor drivers. the others, yes. next Q?
I'm losing my place in the spreadsheet.
From @ottoragam : "I've been using beaglebones to make custom CNC machine controllers with machinekit. Now I want to develop my own motherboard with integrated servo drives using the Octavo Systems thingie. Some general advice? Would it be better to use one of the prebuilt BBs (due to pricing, board assembly cost at the low 100s of units, etc)?"
Low 100s is kinda borderline. The PocketBeagle is a bit of an attempt to span the gap. but, if you make enough, you do get a lot more flexibility with the SIP... and a bit more control. but, if you buy PocketBeagle, the BeagleBoard.org Foundation gets a small royalty. ;-) I'd say get some basic schematic done and share with the community if it won't hurt you. You can get a fair amount of help if you are willing to share. Or not. :-D
From @Jacob Creedon "Besides a battery, what is the best way to prevent eMMC corruption from unexpected pwoeroff? Read only root file system?"
excellent, thanks for the advice, Jason!
maybe a docker image would be useful
@Jacob Creedon ext4 is fairly robust. Doing some kind of union file system would be ideal, but is difficult to configure. It really depends on how sensitive your project is. I pull power randomly on BeagleBone Black and BeagleBone Blues many times a day and never see issues outside of occasionally longer-than-usual fsck's.
BeagleBone!
@Jason Kridner there are about 6 questions left. Are you still okay on time?
yup, still an hour or so before I need to leave to catch a plane home.
From @Todd : "PocketBeagle: I noticed there's a SGX530 3D graphics chip.... but there's no video out, so how is it used?"
@Todd you can use SPI TFT displays and still accelerate with the SGX... at least that is my architecture argument... yet to be played out with software integration. the SGX530 does a memory-to-memory render and isn't tied to the LCDC in specific.
This is in I believe some contrast to some SoCs, TI and other, that do more integration with richer on-screen-display subsystems. I think OMAP falls into that camp. Anyway, from a hardware perspective, it just renders to RAM, so we should be able to still use it.
Also from @Todd : "PocketBeagle: what's the difference between the Cortex 64KB RAM and the DD3? I suppose the on-chip is faster?"
Apparently the gpu has OpenCL capability but I don't know if it's usable
@Garrett Mace I wasn't aware. pointers?!?! @Garrett Mace not sure if that is only for newer generation GPUs or not. I don't have an inside contact at Imagination. :-(
I'd love it to be true.
http://cdn2.imgtec.com/documentation/PowerVR_SGX_Series5XT_IP_Core_Family_%5B3.3%5D.pdf
Jason Kridner Anyway, we are working on the X, Wayland and framebuffer rendering. @Garrett Mace does that not imply only for SGX545?
Not sure :)
From @Tux Lab : "Are BBB still being made domestically or in other free countries? and where to buy them? thanks."
I want it so bad!! ;-)
Clay Montgomery says TI didn't license the OpenCL drivers for the SGX530 Sorry, back to questions :)
@Tux Lab we have 3 current "BeagleBoard.org logo" licensed manufacturers (and several other "BeagleBoard Compatible". Direct logo: PTI in Texas (xM and X15), GHI in Michigan (Black, Black Wireless, PocketBeagle) and Element14/Embest in China (Black, Blue) Some of those listed above are planning to also make other board moving forward.... like Embest will eventually make PocketBeagle as well as GHI. I like having both US domestic as well as China manufacturing. The cost of production really isn't that different as machines to most of the work. However, having good contacts for sourcing in China is critical for embedded electronics at scale these days.
(even if you assemble in the US) we try to make sure our BOMs support US sourcing, but we don't always have our manufacturers do so. it is best effort, but we will spend resources to prototype and verify local component suppliers.
It is hard to find good prices for mfg. in the US.
From @AdityaPrakash23 : "I'm presently working on my final year project for undergrad. I'm designing a structure surveillance robot in Gazebo SIM. I intend to use my BBB rev c for controlling the robot in the simulator using ROS. Also I am supposed to run a Machine Learning program on the Beaglebone for image classification (images taken in the simulation). So my question is, is it possible to run ROS with a very basic ML program at the same time?"
thanks for giving us a choice on the country of origin :)
@Seth in my perspective, it is mostly about prevailing market forces and not labor costs.
Oh.
yup, China is push for automation faster than we are.
All About BeagleBoard
We'll be talking about BeagleBoard projects, communities, and hacks!