Arduino for baremetal. Boot, load with no avrdude.

Hello,

I am currently digging the possibility to use my arduino nano as a very bare environment.

My goal:
#1) Upload to the card, in the simplest way possible, my machine code (yes, binary already)
#2) Executing it without the usual ABI, elf header; which translates to the fact that I have my own binary compiler, custom language, and "OS", ready to accept challenges.
#3) Get away from gcc/clang, avrdude and any 3rd party libraries.

Don't get me wrong the OS I created for arduino is dead simple and only has the logic needed to do what I want (USB, mem management, threading and IO frameworks). So it fits.

What are my options to fulfill the #3 requirement ? bluetooth upload? flashing the rom with my bootloader (I guess) and taking control of the address of execution?

Right now, it will seem too complicated and many will advise to stay with the libraries. But I don't want. I want max control and speed (given the quality of the binary of course, but that is another question).

Thanks

you have described my most common toolset. avrasm instead of gcc and custom flash program instead of avrdude. about 4x more productive/faster than the arduino ide for most projects.

however there is the rare situation where its better to go slumming. for example c for really complex programs or a new device. sometimes better to use existing arduino libraries and not reinvent the wheel. aka skip the 5yr journey and "go where some man has gone before".

I’ve done assembler for AVR, but not any more. I’m using 3 different architectures for uC: 8-bit AVR, 32-bit ESP8266 (Tensilica) and 32-bit STM32F1xx.

To play with all the new toys, assembler is not productive, IMO.

C is a good choice for dedicated projects where speed and efficiency are critical. C++ (IMO) is actually more productive for cross-plstform development if your uC has a good set of low-level API’s. I do not consider the Arduino-cores all that efficient, but they do make cross-architecture development easier if one just keeps track of wordsize and other little architecture-centric things.

There is hardly a project I do that I do not hack those 3rd party libs. Just include the resources into the IDE tabs and the lib is “encapsulated” to that project. Only the most basic of libraries are kept in /library. This approach also makes it easy to Zip up the project fir backup or to upload to a blog, like mine.

But, if you are not into writing, instruction, or participating in the Arduino movement then by all means use assembler and write your own tools.

Ray

#3) Get away from gcc/clang, avrdude and any 3rd party libraries.

What are my options to fulfill the #3 requirement ? bluetooth upload? flashing the rom with my bootloader (I guess) and taking control of the address of execution?

AVRDude is simply the host side application that talks to a device programmer (or a bootloader, most of which mimic a device programmer.) You can find simpler programs, but you’ll always need something that is appoximately equivalent.
(AVRDude is complex because it’s incredibly general, talking to MANY different device programmers. The easiest way of simplifying it is to find a program that only deals with the specific bootloader or device programmer that you happen to have.)

The bootloader is probably a no-no for your “application”; it CAN be used to upload non-arduino sketches, and simplifies things, but to do true “bare metal development” you should get a real device programmer and/or debugger, like an “Atmel ICE” or a USBASP.

JoeLinda,
my observation is that if you really have the skills necessary as indicated by:

the fact that I have my own binary compiler, custom language, and "OS"

and created an "OS" that:

has the logic needed to do what I want (USB, mem management, threading and IO frameworks

That you should have the skills necessary to be able to answer your #3 question on your own.

Having been doing embedded development for more than 30 years, I can say that there are very few situations where hand coded assembler are actually needed.
In many cases writing the code in C will yield equal or better performance since it makes it much easier to focus on overall architecture issues and focusing on performance of the system as a whole vs dropping down in the dirt and optimizing individual components.
i.e. a better way of doing things from a system perspective can often outperform highly optimized individual components.

In other words, often performance issues are not related to code speed but rather what the code is doing or the way it is doing things.

That said, what can really help in some cases is spending some some time looking at the compiler output to get a feel for how the C compiler generates code for the target processor as often a few small tweaks the way the C code is written can create code that can be better optimized by the compiler to create smaller or faster code.

As an example of using C vs assembler, have a look at the optiboot bootloader code some time.
That is a case were code size and timing are critical, and yet the code is not written entirely in assembler.

--- bill