rst
Posts: 370
Joined: Sat Apr 20, 2013 6:42 pm
Location: Germany

Re: Circle - C++ bare metal environment (with USB)

Sat Mar 02, 2019 9:38 am

rst wrote:
Fri Mar 01, 2019 7:58 pm
Memotech Bill wrote:
Fri Mar 01, 2019 5:56 pm
With regard to building on Raspian, I did as previously mentioned, compiled the same toolchain as you are using. So the issue now is that I would need to compile a version of libmath.a?
You should be able to use the circle-stdlib project with the --no-cpp configure option. It comes with the implementation of libm.a. I didn't have this in mind. I will try it and give you info.
There is a .zip file with a small patch attached to this article, which should prepare Circle, if you want to build the accelerated graphics samples on Raspbian using the standard compiler. This patch is not required, if building Circle on a PC Linux host with an embedded toolchain, which provides newlib or if building other Circle samples! Please see the README.md file in the archive for instructions!
circle-patch.zip
(1.58 KiB) Downloaded 38 times

rst
Posts: 370
Joined: Sat Apr 20, 2013 6:42 pm
Location: Germany

Re: Circle - C++ bare metal environment (with USB)

Sat Mar 02, 2019 10:08 am

Gavinmc42 wrote:
Sat Mar 02, 2019 7:54 am
But back when I tried to go from C to C++ (DOS C era) they started this thing called Hungarian notation, totally put me off C++.
Of course, you do not need to use this notation, if you use C++. I do it, because I learned it at some stage and I find it useful.
I wonder if Circle could be used with the Arduino IDE?
There was an attempt to realise this. I don't know the current status of this project.
Your Circle stuff needs the same easy usability for me to use it.
The Circle build system is kept simple by intention. But you can use e.g. the Eclipse IDE with it, if you want to.
Yes hard core guys might regard Arduino as toy stuff, I find I can do stuff in it in a few hours or less.
Productivity for one off hacks, prototypes, gadgets, apps, animated bots etc is fast.
For that reason it gets installed on all my PC's and Pi's along with Geany so I don't need to do CLI coding.
I think, the goal is, to provide solutions for making great things. And you can do this definitely with Arduino too. I was using it before I found the RPi. Honestly the RAM was a little small on the Arduino, but I think there are models with more RAM now. BTW. I like using the command line.

User avatar
Gavinmc42
Posts: 3146
Joined: Wed Aug 28, 2013 3:31 am

Re: Circle - C++ bare metal environment (with USB)

Sat Mar 02, 2019 11:24 am

But you can use e.g. the Eclipse IDE with it, if you want to.
That's the exact opposite of a simple IDE, came from that space never want to go back.
Spent a few weeks back in Eclipse hell a few weeks ago for a TI DSP, just a reminder of why I avoid it.

Geany is just a small step up on Command line.
I use Adafruit Feathers but any Atmel SAM cpu is pretty good these days, 32bit Cortex M0's.
Lots of bigger Arm SoC's are starting to get 2D and 3D acceleration, car instrument cluster etc.
I'm not convinced Tizen is the answer for these, just too big.

There is a hole between Linux and microcontrollers that Ultibo, Circle and others can fill.
Sure the Pi's are mostly overkill but they are cheap and reliable.
Just got some PSoC6 eval boards, has an Eclipse tool, yuk back where I started.
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges

rst
Posts: 370
Joined: Sat Apr 20, 2013 6:42 pm
Location: Germany

Re: Circle - C++ bare metal environment (with USB)

Sat Mar 02, 2019 12:15 pm

Gavinmc42 wrote:
Sat Mar 02, 2019 11:24 am
But you can use e.g. the Eclipse IDE with it, if you want to.
That's the exact opposite of a simple IDE, came from that space never want to go back.
Eclipse is a big thing, I know. It was installed in Circle by a Circle user, who also introduced dwelch67's bootloader to speed up development and I accepted both. In fact there is only a doc file, which represents Eclipse in Circle. I'm not an IDE expert, because I do not use one by myself. I'm using an editor with file management and a terminal window with several tabs.

To provide a specific IDE would require much additional effort, I don't want to spent. You should be able to use any IDE with Circle, which is able to call "make". You may have to do some configuration by yourself, but this should not be a major problem. If you focus on one IDE, you will get a problem, if you come to a platform, where it is not available.
I use Adafruit Feathers but any Atmel SAM cpu is pretty good these days, 32bit Cortex M0's.
Lots of bigger Arm SoC's are starting to get 2D and 3D acceleration, car instrument cluster etc.
I'm not convinced Tizen is the answer for these, just too big.

There is a hole between Linux and microcontrollers that Ultibo, Circle and others can fill.
I think, we are trying to do so. But of course it's a question of the available time and knowledge, what one can do. You can learn something, but it takes time too. This is one reason, why Circle is working with RPi's only. Focus is essential.

Memotech Bill
Posts: 22
Joined: Sun Nov 18, 2018 9:23 am

Re: Circle - C++ bare metal environment (with USB)

Sat Mar 02, 2019 1:38 pm

rst wrote:There is a .zip file with a small patch attached to this article, which should prepare Circle, if you want to build the accelerated graphics samples on Raspbian using the standard compiler.
Thanks, I will try this out and report back on how I get on.

stefanovic
Posts: 2
Joined: Wed Mar 07, 2018 12:22 pm

Re: Circle - C++ bare metal environment (with USB)

Sat Mar 02, 2019 9:12 pm

Hi,

I was trying to compile the vc4 example on my mac using 'brew cask instal gcc-arm-embedded'.
I had to use add this to the compile command:
-I /usr/local/Caskroom/gcc-arm-embedded/7-2018-q2-update/gcc-arm-none-eabi-7-2018-q2-update/lib/gcc/arm-none-eabi/7.3.1/include
-I /usr/local/Caskroom/gcc-arm-embedded/7-2018-q2-update/gcc-arm-none-eabi-7-2018-q2-update/arm-none-eabi/include/

and replace calls to 'make' with 'gmake'

This compiles fine, but the openvg tiger sample fails to link with "undefined reference to `__errno'" from:
../../../../../addon/vc4/interface/vcos/libvcos.a(vcos_pthreads.o): In function `vcos_pthreads_map_errno':
and
/usr/local/Caskroom/gcc-arm-embedded/7-2018-q2-update/gcc-arm-none-eabi-7-2018-q2-update/bin/../lib/gcc/arm-none-eabi/7.3.1/../../../../arm-none-eabi/lib/thumb/v7-ar/fpv3/hard/libm.a(lib_a-wf_sqrt.o): In function `sqrtf':
wf_sqrt.c:(.text.sqrtf+0x78):

with STDLIB_SUPPORT = 1

any tips?

And congratulations for Circle, I follow the project from time to time, it's very interesting.

User avatar
Gavinmc42
Posts: 3146
Joined: Wed Aug 28, 2013 3:31 am

Re: Circle - C++ bare metal environment (with USB)

Sun Mar 03, 2019 12:09 am

[This is one reason, why Circle is working with RPi's only. Focus is essential./quote]
Yep knowing capability limitations is important, Ultibo is Pi only apart from QEMU.
I only use Pi's and don't have any other SBCs, at my current rate of learning I will probably never master the Pi and all it's capabilities.

Most of my PiCore Linux Pi's are networked and Midnight Commander is my editor and file manager for those Pi's.
These were mostly scripted apps not compiled, got as high as 2% cpu usage on Pi B+'s. :lol:

Not sure how long it would take to be an Eclipse IDE expert, 2, 3 lifetimes?
IDEs should help and not get in the way, if I spend more time fighting the IDE than debugging I get annoyed.
I like Geany because it is available on most OS's and it has just enough easy to use IDE compile/build/make and can colour syntax edit most known languages.
But of course it's a question of the available time and knowledge, what one can do.
Yep, what I can do with Pi's is mostly stuff I have never done before but always wanted to.
Somethings I know can be done but it takes years to get around to doing it.
Lack of time and/or knowledge or these days leaking memory, all contribute to slow progress.
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges

rst
Posts: 370
Joined: Sat Apr 20, 2013 6:42 pm
Location: Germany

Re: Circle - C++ bare metal environment (with USB)

Sun Mar 03, 2019 7:24 am

stefanovic wrote:
Sat Mar 02, 2019 9:12 pm
This compiles fine, but the openvg tiger sample fails to link with "undefined reference to `__errno'" from:
../../../../../addon/vc4/interface/vcos/libvcos.a(vcos_pthreads.o): In function `vcos_pthreads_map_errno':
and
/usr/local/Caskroom/gcc-arm-embedded/7-2018-q2-update/gcc-arm-none-eabi-7-2018-q2-update/bin/../lib/gcc/arm-none-eabi/7.3.1/../../../../arm-none-eabi/lib/thumb/v7-ar/fpv3/hard/libm.a(lib_a-wf_sqrt.o): In function `sqrtf':
wf_sqrt.c:(.text.sqrtf+0x78):
The __errno symbol should normally be present. It is provided by libcircle.a itself with "STDLIB_SUPPORT = 1" here and libcircle.a is the last library in the hello_tiger Makefile.

You can try to add the following line as the last line in this Makefile for a test:

Code: Select all

EXTRALIBS += $(CIRCLEHOME)/lib/libcircle.a
This will provide libcircle.a as very last library, even after libm.a. Perhaps this resolves the external. The library order is sometimes critical.
And congratulations for Circle, I follow the project from time to time, it's very interesting.
Thanks!

rst
Posts: 370
Joined: Sat Apr 20, 2013 6:42 pm
Location: Germany

Re: Circle - C++ bare metal environment (with USB)

Sun Mar 03, 2019 7:32 am

Gavinmc42 wrote:
Sun Mar 03, 2019 12:09 am
I like Geany because it is available on most OS's and it has just enough easy to use IDE compile/build/make and can colour syntax edit most known languages.
Perhaps I should have a look at Geany. It's also available on Raspbian and on the Linux distribution, I am using.

stefanovic
Posts: 2
Joined: Wed Mar 07, 2018 12:22 pm

Re: Circle - C++ bare metal environment (with USB)

Sun Mar 03, 2019 9:13 am

rst wrote:
Sun Mar 03, 2019 7:24 am
The __errno symbol should normally be present. It is provided by libcircle.a itself with "STDLIB_SUPPORT = 1" here and libcircle.a is the last library in the hello_tiger Makefile.

You can try to add the following line as the last line in this Makefile for a test:

Code: Select all

EXTRALIBS += $(CIRCLEHOME)/lib/libcircle.a
This will provide libcircle.a as very last library, even after libm.a. Perhaps this resolves the external. The library order is sometimes critical.
my bad, I forgot to recompile everything once I changed STDLIB_SUPPORT from 0 to 1. Thanks!

msx80
Posts: 17
Joined: Sun Feb 11, 2018 4:36 am

Re: Circle - C++ bare metal environment (with USB)

Wed Mar 20, 2019 1:04 pm

I have some questions about usb keyboard callbacks (the Raw one in particular). When, during the execution of the program, is the callback called? Can it interrupt the flow of the program in any arbitrary point?
And is the callback completed somehow in parallel with the normal program, or does it stop it?
I would like to have some control over it to avoid updating some "live" data.

rst
Posts: 370
Joined: Sat Apr 20, 2013 6:42 pm
Location: Germany

Re: Circle - C++ bare metal environment (with USB)

Wed Mar 20, 2019 4:38 pm

msx80 wrote:
Wed Mar 20, 2019 1:04 pm
I have some questions about usb keyboard callbacks (the Raw one in particular). When, during the execution of the program, is the callback called? Can it interrupt the flow of the program in any arbitrary point?
And is the callback completed somehow in parallel with the normal program, or does it stop it?
I would like to have some control over it to avoid updating some "live" data.
In a single-core application the keyboard callback interrupts the main program. It is called from the USB interrupt handler and runs in IRQ context. The main program is continued, when the keyboard callback completes. In a multi-core application the callback may run parallel on core 0 with the functions, which are running on core 1, 2 and 3.

You may have to do some queuing of the keyboard data in the callback and read the queue from the main program. The queue has to be protected using a spin lock, like that:

Code: Select all

#include <circle/spinlock.h>

class CSomething
{
private:
    CSpinLock m_SpinLock;
};

CSomething::callback()
{
    m_SpinLock.Acquire ();

    // write to the queue

    m_SpinLock.Release ();
}

CSomething::main_program()
{
    m_SpinLock.Acquire ();

    // read from the queue

    m_SpinLock.Release ();
}
While the spin lock is hold, the code in the callback or main program can be sure, that no one else does access the queue.

msx80
Posts: 17
Joined: Sun Feb 11, 2018 4:36 am

Re: Circle - C++ bare metal environment (with USB)

Wed Mar 20, 2019 7:57 pm

Awesome, that's what i needed. Just to understand, does the spinlock work in single core too? Does the IRQ kinda stops and the main flow resume until it frees the spinlock?
Btw how do one set the build as single or multicore? does it need a rebuild of circle?

Thanks a lot!

rst
Posts: 370
Joined: Sat Apr 20, 2013 6:42 pm
Location: Germany

Re: Circle - C++ bare metal environment (with USB)

Wed Mar 20, 2019 10:54 pm

msx80 wrote:
Wed Mar 20, 2019 7:57 pm
Awesome, that's what i needed. Just to understand, does the spinlock work in single core too? Does the IRQ kinda stops and the main flow resume until it frees the spinlock?
Btw how do one set the build as single or multicore? does it need a rebuild of circle?

Thanks a lot!
Yes, you can use the spin lock in the same manner for both single- or multi-core operation. The difference is handled automatically by Circle. In a single-core environment the class CSpinLock does not implement a real spin lock. It simply disables the IRQ on Acquire() and enables it on Release(). This has the same effect, that code, which holds the "spin lock" cannot be interrupted and the data, which is protected by the spin lock cannot be modified by a different instance.

Multi-core operation will be enabled by activating the #define ARM_ALLOW_MULTI_CORE in the header file include/circle/sysconfig.h. It is commented out by default. Of course this only works on RPi 2 and 3, because RPi 1 and Zero are single-core by hardware. You have to rebuild Circle, when you changed this. To really use multiple cores with Circle, you have to use the class CMultiCoreSupport in your application. Please have a look at sample/17-fractal to get info, how it is used.

msx80
Posts: 17
Joined: Sun Feb 11, 2018 4:36 am

Re: Circle - C++ bare metal environment (with USB)

Thu Mar 21, 2019 9:17 am

Thank for your quick replies rst! I think i solved with the spinlock. This project really is a huge achievement.

rst
Posts: 370
Joined: Sat Apr 20, 2013 6:42 pm
Location: Germany

Re: Circle - C++ bare metal environment (with USB)

Thu Mar 21, 2019 2:14 pm

@msx80 Thanks!

msx80
Posts: 17
Joined: Sun Feb 11, 2018 4:36 am

Re: Circle - C++ bare metal environment (with USB)

Sun Mar 24, 2019 4:52 pm

Here i am with another question (i hope i'm not abusing your patience).
I'm adding gamepad support to my project (the tic80 port to circle). I find that the gamepad callback get called way too often, like continuously, to the point that the entire system slow to a crawl. I've searched the code but there doesn't seem to be a way to configure it to receive less messages. Do you think it could depend on the specific joystick?

I'm planning to move to multicore to get a bit more performances in any case (between audio and the input callbacks there start to be quite some stuff to parallelize). About audio, does it still uses che Scheduler object even in multicore? Do i still have to call Yield() somewhere?

Thanks again!

rst
Posts: 370
Joined: Sat Apr 20, 2013 6:42 pm
Location: Germany

Re: Circle - C++ bare metal environment (with USB)

Sun Mar 24, 2019 6:22 pm

msx80 wrote:
Sun Mar 24, 2019 4:52 pm
Here i am with another question (i hope i'm not abusing your patience).
I'm adding gamepad support to my project (the tic80 port to circle). I find that the gamepad callback get called way too often, like continuously, to the point that the entire system slow to a crawl. I've searched the code but there doesn't seem to be a way to configure it to receive less messages. Do you think it could depend on the specific joystick?
No problem. I already had a look at your interesting project. Your gamepad callback should do only those things, which are absolutely required to enable gamepad support in your application. Just copy the data and return. Do not make outputs to the screen there. There are some gamepads, which do send a report very often. This can be triggered by the gyroscope sensor for instance and cannot be suppressed. My experience is, that even with this, there should not be a performance problem, as long the gamepad callback is not doing to much.
I'm planning to move to multicore to get a bit more performances in any case (between audio and the input callbacks there start to be quite some stuff to parallelize). About audio, does it still uses che Scheduler object even in multicore? Do i still have to call Yield() somewhere?
Yes, the scheduler is still running on core 0 and you have to call Yield() on core 0 from time to time. The cores 1-3 do not use the scheduler. You can do on them, whatever you want.

msx80
Posts: 17
Joined: Sun Feb 11, 2018 4:36 am

Re: Circle - C++ bare metal environment (with USB)

Tue Apr 02, 2019 8:30 pm

Actually about the joystick, i experience a slowdown even just connecting it, without even any code to attach callbacks etc. :shock: I don't know, maybe the system is already almost saturated and that's enougth to tip it over?

Anyway, i give a serious try with multicore, to distribute the load to different cores, but i don't seem to be able to make it run.

What i see is that the program runs and only code with core = 0 on my CMultiCoreSupport class gets run.

My steps were: I recompiled circle with ARM_ALLOW_MULTI_CORE (which is confirmed becouse the class CMultiCoreSupport is there). I made a subclass of it with some minimal stuff just to see it working (like logging nCore or drawing to screen), i initialized it after all other initializations on core 0.
Then on main kernel.cpp Run method i called myclass.Run(0) (as on sample 17). I'm not sure why this is correct, wouldn't it just run the class with parameter nCore set to 0? Perhaps core 0 is run this way and 1, 2, 3 starts by themselves somehow?

I fumbled about on multicore.cpp, noticed the "main_secondary" which sounds like an entry point for secondary cores. Not sure who calls it?

Anyway, am i missing something? Looks like there's something to trigger execution of other cores but the more i look at example 17 the more it seems i'm doing exacly the same stuff.

PS i'm running inside circle-stdlib if that can help. And no joystick attached.

Thanks again :)

rst
Posts: 370
Joined: Sat Apr 20, 2013 6:42 pm
Location: Germany

Re: Circle - C++ bare metal environment (with USB)

Wed Apr 03, 2019 8:56 am

msx80 wrote:
Tue Apr 02, 2019 8:30 pm
Actually about the joystick, i experience a slowdown even just connecting it, without even any code to attach callbacks etc. :shock: I don't know, maybe the system is already almost saturated and that's enougth to tip it over?
Please try it with the system option USE_USB_SOF_INTR enabled. Circle implements two different USB frame scheduling methods. This one is probably the better one for using gamepads.
Anyway, i give a serious try with multi-core, to distribute the load to different cores, but i don't seem to be able to make it run.
There is a working multi-core sample attached to this message, which has to be build using circle-stdlib. Place it in the circle-stdlib/samples directory. ARM_ALLOW_MULTI_CORE still must be enabled with it.
Then on main kernel.cpp Run method i called myclass.Run(0) (as on sample 17). I'm not sure why this is correct, wouldn't it just run the class with parameter nCore set to 0? Perhaps core 0 is run this way and 1, 2, 3 starts by themselves somehow?
This something.Run (0) call is only required in this sample/17-fractal, because core 0 is doing the same task like core 1, 2 and 3 (calculating pixels for the fractal image). In other applications, where core 0 is doing different things, this call is not needed.
I fumbled about on multicore.cpp, noticed the "main_secondary" which sounds like an entry point for secondary cores. Not sure who calls it?
Yes, this is the entry point for the cores 1, 2 and 3 and it is used internally in the class CMultiCoreSupport. You do not need to touch it on your own.
17-fractal.zip
(5.5 KiB) Downloaded 31 times

msx80
Posts: 17
Joined: Sun Feb 11, 2018 4:36 am

Re: Circle - C++ bare metal environment (with USB)

Thu Apr 04, 2019 7:43 am

Ok tried your program and it works. Now i really don't know what i can be doing wrong. I guess i'll start from your example and move my code in it until it's all there :P

On the USB side, that flag helped! now it handles the gamepad with no slowdowns.

Well thanks again for your essential support!

bzt
Posts: 373
Joined: Sat Oct 14, 2017 9:57 pm

Re: Circle - C++ bare metal environment (with USB)

Thu Apr 04, 2019 12:08 pm

Hi

First, Circle is getting better and better, well done! I've linked it from my tutorials just in case someone's looking for a bare metal C++ library. :-)
rst wrote:
Sat Mar 02, 2019 10:08 am
Gavinmc42 wrote:
Sat Mar 02, 2019 7:54 am
But back when I tried to go from C to C++ (DOS C era) they started this thing called Hungarian notation, totally put me off C++.
Of course, you do not need to use this notation, if you use C++. I do it, because I learned it at some stage and I find it useful.
I've found that the biggest problem with Hungarian notation is that people don't understand how to use it. There are many bad examples on the net which creates confusion. I've seen many bad code where they were using prefixes like "dword", "dw" or "u32". This is an abuse of the HN from people who don't get it (also called Systems HN btw).

As Simonyi put it, the point is:
Simonyi wrote:we would look at one name and I would tell you exactly a lot about that
Without getting too deep in the details, I'd like to point out HN is all about abstract types, and not C/C++ types or machine represetation types. That's the most common misconception. For example "int" is a C/C++ type, whereas "counter" is an abstract type (which implies numerical machine representation and also that the value cannot change arbitrairly but increased/decreased monothonically). Therefore "intTicks" or "intRetry" are bad notations, and "cntTicks" or "cntRetry" are good ones. From the original paper, "d" should represent distance. It's clear that distance is stored in some sort of numerical representation, but "d" does not mean integer nor double because HN is not about machine represenation. It's clearly an abstract type which tells "relative difference" rather than an "absolute value" stored in that variable.

The wikipedia page tries to explain this by referring to HN as the "intention or kind of the variable" in contrast to "type". Unfortunately there are many bad examples on the wikipedia page too. Using "b" for boolean is just bad. For example in a class which stores more elements you shouldn't have an "bEmpty()" function, you should have "isEmpty()"; where "is" tells the reader that this is a run-time check (being a verb) which clearly returns a boolean as a result (because the only possible answers to that are yes or no).

In Circle for example I saw "nEntry" which implies "number of Entry". This helps understanding of the code, therefore it's a good HN. I've also seen "nResult" which is not for "number of Results" therefore it's not the luckiest HN. But "n" suggests that result is a number, so it's not bad at all, as it contributes to code readability after all.

Cheers,
bzt

rst
Posts: 370
Joined: Sat Apr 20, 2013 6:42 pm
Location: Germany

Re: Circle - C++ bare metal environment (with USB)

Thu Apr 04, 2019 4:08 pm

Thanks bzt, for linking Circle in your tutorials! Regarding Hungarian Notation I have to say, it's probably not the whole notation by Simonyi, which I am applying, more a modified one. For example I'm using the prefix "n" for any integer or unsigned typed variable. It's just "a number". About twenty years ago I wrote some MFC applications and at this time I started with this notation. I guess, in the field, where Circle lives, it's more uncommon to use HN, but I didn't thought much about this, when I started. It was intended to help myself in writing source code and it did. ;)

juga64
Posts: 3
Joined: Tue Apr 09, 2019 3:11 am

Re: Circle - C++ bare metal environment (with USB)

Tue Apr 09, 2019 3:23 am

Hi! Actually I am testing in the RPi the bare metal Commodore 64 Emulator BMC64 that it is based in VICE emulator and Circle:

https://github.com/randyrossi/bmc64
https://accentual.com/bmc64/

It works really well! I recommend it to anyone that it is interested in C64 emulation on the Raspberry Pi.

All the files (Circle, VICE and C64 disk, tape, etc. image files) must be included in the micro SD card.

I would like to put my C64 files (games, etc.) in an external USB flash drive and leave the micro SD only for BMC64 files.

Is there any way to mount an usb flash drive and read it from the emulator?

The developer recommended us this, I tested it but it doesn't work:

You _should_ be able to add disk_volume=USB to cmdline.txt and that should switch loading emulator stuff from a USB stick. Set disk_partition=0 for auto or the specific partition #. However, when I tried it, it didn't appear to work for me but I never investigated why. If you try it and you just get a blank screen, try disk_volume=USB2 or USB3 as well.

I will appreciate any comment you could provide. Thanks and best regards!

Juan

rst
Posts: 370
Joined: Sat Apr 20, 2013 6:42 pm
Location: Germany

Re: Circle - C++ bare metal environment (with USB)

Wed Apr 10, 2019 9:23 am

juga64 wrote:
Tue Apr 09, 2019 3:23 am
Is there any way to mount an usb flash drive and read it from the emulator?

The developer recommended us this, I tested it but it doesn't work:

You _should_ be able to add disk_volume=USB to cmdline.txt and that should switch loading emulator stuff from a USB stick. Set disk_partition=0 for auto or the specific partition #. However, when I tried it, it didn't appear to work for me but I never investigated why. If you try it and you just get a blank screen, try disk_volume=USB2 or USB3 as well.
Unfortunately it is not possible to say, why this is not working, here. Circle supports USB flash drives, but the application must support this too. These "disk_volume" and "disk_partition" settings are added by the emulator. They are not a Circle standard. Perhaps you should add an issue to the emulator project on GitHub.

Return to “Bare metal, Assembly language”