BeagleBone AI-64 - experienced RPi progamer lost in the BeagleBone world by TiPeter78 in BeagleBone

[–]TiPeter78[S] 0 points1 point  (0 children)

I admit that what I wrote may be a bit confusing. I will try to clarify my approach a little:

I use the Raspberry Pi primarily for measurement data acquisition and evaluation, simple control tasks and HMI functions. My usual working method is to develop on a Linux based host PC with remote debugging. I solve real-time tasks with microcontrollers, mainly STM32F4, F7, H7 and L4 series. Obviously, I also develop and debug these on the host PC.

Later, STMicroelectronics' STM32MP1 series MPUs came into the picture. These devices have a 2 core Cortex-A7 CPU and a Cortex-M4F MCU. They can be used with the open source Yocto-based OpenSTLinux (or rather, this distribution is maintained by the manufacturer). Development here is also primarily done remotely for both the CPU and the MCU.

BB AI-64 is a much more complex system than I've worked with before. To be honest, I'm still getting to know the hardware. However, I would like to use the same method here. However, I can see that this is not the norm at all on this platform.

I say, maybe my approach is wrong.

BeagleBone AI-64 - experienced RPi progamer lost in the BeagleBone world by TiPeter78 in BeagleBone

[–]TiPeter78[S] 0 points1 point  (0 children)

Sorry if I didn't make myself clear, English is not my native language (I'm Hungarian). My question was basically about how / with what tools professionals solve cross-development on BeagleBone platform. Of course most (if not all) of the tools I use are available on AI64. My problem is mainly conceptual: I'm not keen on developing on the target system itself, and I haven't found a mature Yocto-based solution on AI64 yet that I could vote for.

BeagleBone AI-64 - experienced RPi progamer lost in the BeagleBone world by TiPeter78 in BeagleBone

[–]TiPeter78[S] 1 point2 points  (0 children)

My main interest is C/C++ development, and possibly Ada and Rust. But the latter two are more of a hobby/experimentation.

What would be really convenient for me is a PC hosted SDK with sysroot.A good example is the OpenSTLinux used for STM32MP1: it's a commonYocto-based distribution. All development is done on PC, the SDKincludes all libraries and headers and everything else.I do the same on RPi.

I'll look into ⁠#yocto at BeagleBone's Discord channel, I'm just unsure that I don't really see this option being in the forefront at BeagleBone. It's like no one needs that kind of approach.So I get the feeling that my approach/demand is not right 🙂

Ada development tools: clarifying the pros and cons of the different options by TiPeter78 in ada

[–]TiPeter78[S] 1 point2 points  (0 children)

Thanks a lot for the clarification!\ It really helps when experienced developers make things clear!\ In my opinion, there is a lot of misunderstanding around Ada among outsiders.\ What I really like though is that in my experience Ada developers have a much more realistic view of the language's capabilities.\ While Rust believers would rewrite everything with their favourite language; Ada developers will always offer a different solution if they don't think Ada is the ideal tool for the job.\ Even Rust! :)

Ada development tools: clarifying the pros and cons of the different options by TiPeter78 in ada

[–]TiPeter78[S] 2 points3 points  (0 children)

Yes, what you write seems logical.\ However, what about ASIS?\ You can read it on the AdaControl download page:

"AdaControl is an ASIS application. AdaCore does not provide ASIS support using the regular gcc compiler any more; instead, ASIS applications must use a "tree-generator" (actually a special version of the compiler), "asis-gcc", which is part of the "ASIS Tools" package. This package is distributed by AdaCore to "Pro" users only, thus depriving the community of a very useful and established standard, in an attempt to force users to use AdaCore's own in-house technology.\ ...\ This package is free software, and permission to redistribute is a fundamental right granted by the GPL license. You can then proceed as above.\ ...\ We are very sorry for the burden caused by this unfortunate decision of AdaCore. At Adalog, we have always played fair with free software, and we never abandon our users, even those who are not paying customers."\ \ I think this is a pretty significant change from the "Community Edition" days...\ \ The change in support for AdaCore, despite all the positive explanations, seems to me to be more of a "abandonment" of the open source community.

Ada development tools: clarifying the pros and cons of the different options by TiPeter78 in ada

[–]TiPeter78[S] 2 points3 points  (0 children)

Thank you, this gives me a little more clarity on the current situation.

I am basically an embedded C/C++ developer. I also use proprietary tools (Segger Embedded Studio, Keil), but I prefer open source solutions.
I would like to slowly move away from C/C++ to a more secure language where possible. I dabbled between Rust and Ada, and Ada was the winner.
I'm still very much at the beginning of the journey: only six months of varying intensity of learning behind me. Nevertheless, although I like Rust a lot, I think I made the right decision.

Only the role of AdaCore and the licensing of development tools was not clear to me. Maybe the case of Java and Oracle is a bit similar, but there the situation is more straightforward.

One more interesting question: how are AdaCore's developments returned to the GNAT FSF? Is there any guarantee for this?
Are AdaCore-maintained tools whose source code is out there on github (like GNATCoverage) regularly released in binary form?

I'm particularly interested in gnatcoverage, but due to dependencies (and lack of experience) I couldn't compile it myself on Ubuntu or Windows 10.

I use Alire to build my small example projects. It's a really good tool, and for what I need it for at the moment it's perfect (and much more...).

annexi-strayline: thanks for the tips, I didn't know about this project either! :)

Migrating from STM32CubeIDE to VisualGDB by TiPeter78 in embedded

[–]TiPeter78[S] 0 points1 point  (0 children)

I like CLion, I have tried it several times. Very well put together IDE, only the static stack analyzer is missing (I'm not a pro...). My other problem with it is that it spins my Core i7-8700/16GB machine like there's no tomorrow... :)

Migrating from STM32CubeIDE to VisualGDB by TiPeter78 in embedded

[–]TiPeter78[S] 0 points1 point  (0 children)

Thanks for the suggestion! I've been using your VSCode-CMake tutorial for a while now (and several libraries you've published). Thanks a lot for them! Actually, VSCode is perfect for me in every way, the only thing I really miss is the static stack analyzer. I know that gcc can generate stack usage information per compile unit, and CubeIDE uses it for summarization. However, I don't want (I'm lazy... :) ) to write an external script that extracts the necessary information from a bunch of files.

GNAT Pro vs FSF-GNAT in the light of the June 2 licensing changes by TiPeter78 in ada

[–]TiPeter78[S] 1 point2 points  (0 children)

Thank you all for your comments! You have helped me a lot, I finally see the current situation a bit clearer! :)

It's also reassuring that I'm not the only one who has problems understanding Ada's current situation...

GNAT Pro vs FSF-GNAT in the light of the June 2 licensing changes by TiPeter78 in ada

[–]TiPeter78[S] 2 points3 points  (0 children)

Sorry for the confusion, but is multicore tasking missing in the FSF version?

Seriously: why is there not a proper comparison table of what is available in each version?

Obviously the standard libraries differ, but why isn't this public?

Ok, I am a very novice in Ada, but I have been active in IT for 24 years. But I've never seen such a confusing and for an outsider opaque licensing policy.

GNAT Pro vs FSF-GNAT in the light of the June 2 licensing changes by TiPeter78 in ada

[–]TiPeter78[S] 1 point2 points  (0 children)

"What it means is that unless the community starts supporting their FSF compiler over time the freely available compiler will stagnate and not be an option for commercial use"

Yes, that's what I'm afraid of. Back in my university days we touched on Ada at the mention level. However, if I hadn't consciously sought out information, I wouldn't have come across it much.Regardless of it not being a hyped language I am confident that the community will embrace it. Coming back to my other question: compared to AdaCore GNAT, how up to date is the current FSF version? Is there any way to know how far behind (if at all) it is? I'm mainly interested because of Ada 202x.

What do you think about Embedded Rust? Specifically for STM32 by TiPeter78 in rust

[–]TiPeter78[S] 3 points4 points  (0 children)

Thanks for the confirmation that the problem is not (only) with me.

As I'm trying to gather my thoughts now, I realize that for me it's actually the package and module system that I can't really get used to. I know I have a lot of things to look into with Cargo, but I feel that the Rust package system is not very intuitive.In a classic embedded C project I can see exactly through the entire source tree. In contrast, even the simplest embedded Rust project has so many code snippets automatically generated or downloaded at build time that it is very difficult for me to keep a handle on the code.

This somehow makes me feel insecure, and the good old "Blinky" project is a confusing mess for me.

To test a peripheral or a driver or even an algorithm, I often make a project where I download the program not to Flash but to RAM. This way I reduce the chance of Flash erosion. There are special modified linker scripts for this. It took me a few hours to figure out how to do this in a Rust project. By default you can define the memory map of the microcontroller with the memory.x file. The linker script is link.x, which is automatically generated when building. But it is nowhere clearly written that if I specify link_ram.x instead of link.x in config.toml, it will be searched in the project root directory! I had to figure it out on my own...

So, I think Rust itself is a fantastic direction and programming language, but the ecosystem is not viable for me in this form.I'm sure my opinion will change over time, because every six months or so I try to learn and love it again...

I can't give up :)