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

[rst]

@cmarrin Thanks! I have to use the GPL, because I'm using source code from 3rd parties in Circle, which is licensed using the GPL by itself. So a license switch is not possible.

[cmarrin]

Ah, right. GPL is infectious - one of its many maddening qualities. Oh, well, still a great piece of work though. Thanks for the response. Have any components been split off anywhere? It would be great if I could find a complete set of startup and interrupt logic to work with. I'll keep looking.

[LdB]

Your current interrupt handler has a bug it doesn't 8 byte align the stack when calling out to a C function

handleIRQ is a C function in RPiInterruptManager.cpp

This is not enough

Code: Select all

irqStub:
    sub    lr, lr, #4
    stmfd sp!, {r0-r12, lr}
    bl handleIRQ
ldmfd sp!, {r0-r12, pc}^

Try

Code: Select all

irqStub:
    sub    lr, lr, #4
    stmfd sp!, {r0-r12, lr}
    
    /* 8 byte align stack for external call hold pad value in R4 */
   and r4, sp, #0x7
   sub sp, sp, r4
    
    bl handleIRQ
    
    /* Restore the original stack alignment  */
   add sp, sp, r4

 ldmfd sp!, {r0-r12, pc}^

[rst]

@cmarrin Don't understand me wrong, personally I do not have a problem with the GPL. I like the open source idea.

[cmarrin]

Hey! Who do you think you are? I was just about to debug that



Thanks so much for looking at my code! And thanks for the solution. Your experience at this level of the code is really valuable. I hope I can get there someday!

Your current interrupt handler has a bug it doesn't 8 byte align the stack when calling out to a C function

handleIRQ is a C function in RPiInterruptManager.cpp

This is not enough

Code: Select all

irqStub:
    sub    lr, lr, #4
    stmfd sp!, {r0-r12, lr}
    bl handleIRQ
ldmfd sp!, {r0-r12, pc}^

Try

Code: Select all

irqStub:
    sub    lr, lr, #4
    stmfd sp!, {r0-r12, lr}
    
    /* 8 byte align stack for external call hold pad value in R4 */
   and r4, sp, #0x7
   sub sp, sp, r4
    
    bl handleIRQ
    
    /* Restore the original stack alignment  */
   add sp, sp, r4

 ldmfd sp!, {r0-r12, pc}^

[cmarrin]

@cmarrin Don't understand me wrong, personally I do not have a problem with the GPL. I like the open source idea.

I don't fault your choice of languages. My suggestion to move away from GPL was a purely selfish one. My hardline stance against using encumbered licenses is a philosophical one. But I understand developers like you who want to use other good work out there and are fine using the GPL in order to be able to do it.

[LdB]

Thanks so much for looking at my code! And thanks for the solution. Your experience at this level of the code is really valuable. I hope I can get there someday!

Haha no worries your fiq has the same problem btw but I assume you realize that.

[Memotech Bill]

I thought it worth recording my experience attempting to build Circle on an RPi. I am using an RPi v2 with no overclocking, and a clean install of 2018-11-13-raspbian-stretch-lite.img.

The rasbian repositories do include an arm-none-eabi toolchain, which can be installed with "sudo apt-get install gcc-arm-none-eabi". However, attempting to compile Circle with that results in the following error:

Code: Select all

httpclient.cpp: In member function 'THTTPStatus CHTTPClient::Request(THTTPRequestMethod, const char*, u8*, unsigned int*, const char*)':
httpclient.cpp:326:1: error: insn does not satisfy its constraints:
 }
 ^
(insn 1452 2259 1453 153 (parallel [
            (set (reg/v:SI 3 r3 [orig:141 nState ] [141])
                (and:SI (leu:SI (reg/v:SI 3 r3 [orig:141 nState ] [141])
                        (const_int 4 [0x4]))
                    (ne:SI (reg/v:SI 3 r3 [orig:141 nState ] [141])
                        (const_int 1 [0x1]))))
            (clobber (reg:CC 100 cc))
        ]) httpclient.cpp:309 256 {*and_scc_scc_nodom}
     (nil))
httpclient.cpp:326:1: internal compiler error: in extract_constrain_insn, at recog.c:2246
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
../../Rules.mk:109: recipe for target 'httpclient.o' failed
make: *** [httpclient.o] Error 1

It might just be the one source file that fails, but I was not sure whether there may be other subtle unreported errors.

So head over to the recommended https://developer.arm.com/open-source/g ... /downloads. Except that all the pre-compiled toolchains are for x86 processors. So download the "Source Invariant" version. Copy onto the RPi and untar.

There are instructions for building the toolchain in file "How-to-build-toolchain.pdf". These are for building on Ubuntu, but it was not too difficult to interpret for RPi.

WARNING: These steps require a lot of space (16GB SD card was not big enough, I used a 64GB for second attempt) and a lot of time (more than 36 hours).

Code: Select all

sudo apt-get install \
build-essential \
autoconf \
autogen \
bison \
dejagnu \
flex \
flip \
gawk \
git \
gperf \
gzip \
nsis \
openssh-client \
p7zip-full \
perl \
python-dev \
libisl-dev \
scons \
tcl \
texinfo \
tofrodos \
wget \
zip \
texlive \
texlive-extra-utils \
libncurses5-dev

./install-sources.sh --skip_steps=mingw32
./build-prerequisites.sh --skip_steps=mingw32
./build-toolchain.sh --skip_steps=mingw32

It is the last of these steps which is the very time-consuming one, and it may look as though it is repeating itself as the code is built for all the different processor versions.

Having built the toolchain, copy Circle onto the RPi and unzip. Edit the "Rules.mk" file and change the PREFIX line to:

Code: Select all

PREFIX   ?= /home/pi/gcc-arm-none-eabi-8-2018-q4-major/install-native/bin/arm-none-eabi-

Then run "./makeall" to obtain a clean build of Circle.

Now all I have to do is work out how to use it.

[rst]

I thought it worth recording my experience attempting to build Circle on an RPi. I am using an RPi v2 with no overclocking, and a clean install of 2018-11-13-raspbian-stretch-lite.img.

Thanks for your report. I think, your problem with building Circle was caused by a compiler bug, which has already been reported here for an earlier compiler version on a different platform.

Normally Circle can be build (for AArch32) on Raspbian using the standard compiler (GNU C 6.3.0 at the moment). You have to set an empty toolchain prefix in Rules.mk (or Config.mk) to do this, like that:

Code: Select all

PREFIX =

I tested it with an older Raspbian installation, which has been upgraded to the current state. Circle 38 builds successfully and the resulting kernel7.img runs without problems on a RPi 3B (tested with sample/21-webserver).

[Memotech Bill]

Normally Circle can be build (for AArch32) on Raspbian using the standard compiler (GNU C 6.3.0 at the moment). You have to set an empty toolchain prefix in Rules.mk (or Config.mk) to do this

@rst, thank you. Simple when you know how, but I am a complete novice at bare metal on ARM and using high level languages.

[rst]

Normally Circle can be build (for AArch32) on Raspbian using the standard compiler (GNU C 6.3.0 at the moment). You have to set an empty toolchain prefix in Rules.mk (or Config.mk) to do this

@rst, thank you. Simple when you know how, but I am a complete novice at bare metal on ARM and using high level languages.

I built my first bare metal toolchain from source too. I wouldn't do this today any more. It's a learning process. The only thing is, you have to try to go further. This is what you did. So no problem. Good luck!

[Memotech Bill]

Mt adventures with Circle and bare metal continue. This code:

Code: Select all

const char * MakeString (const char *fmt, va_list va)
    {
    static CString sText;
    sText.FormatV (fmt, va);
    return (const char *) sText;
    }

gave me these link errors:

Code: Select all

main.o: In function `MakeString(char const*, std::__va_list)':                                                  
/home/pi/circle/app/memu/main.cpp:98: undefined reference to `__cxa_guard_acquire'
/home/pi/circle/app/memu/main.cpp:98: undefined reference to `__cxa_guard_release'

I am building on RPi with STDLIB_SUPPORT ?= 1.

It was this article which gave me the solution, rewrite the code as:

Code: Select all

static CString sText;
const char * MakeString (const char *fmt, va_list va)
    {
    sText.FormatV (fmt, va);
    return (const char *) sText;
    }

It appears that the compiler itself is generating calls to functions which are not in libgcc.

[rst]

Mt adventures with Circle and bare metal continue. This code:

Code: Select all

const char * MakeString (const char *fmt, va_list va)
    {
    static CString sText;
    sText.FormatV (fmt, va);
    return (const char *) sText;
    }

Such construct can only be used with C++ standard library support, which is provided using the circle-stdlib project with a suitable toolchain on PC Linux hosts. Unfortunately it is not supported if building Circle on Raspbian itself.

[Memotech Bill]

Such construct can only be used with C++ standard library support

I'm not complaining. It is just that it takes a fairly deep understanding of compiler internals (such as the article I referenced) to understand why my first version fails to link, while my second version does not. In terms of functionality of the routines I don't think that there is any difference.

Perhaps I should start a separate thread "Learnings of a Circle Newbie".

Anyway I now have a successfully linked kernel, so the real fun starts.

[rst]

Circle 39 has been released today with support for the following accelerated graphics APIs:

• OpenGL ES 1.1 and 2.0
• OpenVG 1.1
• EGL 1.4
• Dispmanx

I have partially ported the userland code to realise this.

[Ultibo]

Circle 39 has been released today with support for the following accelerated graphics APIs:

• OpenGL ES 1.1 and 2.0
• OpenVG 1.1
• EGL 1.4
• Dispmanx

I have partially ported the userland code to realise this.

Congratulations Rene, We know how much work is required to produce a complete implementation of the VCHIQ protocol and Userland libraries so your effort should be applauded not only by those using the Circle project but by anyone interested in serious bare metal development.

Having two publicly available bare metal implementations of standards based graphics APIs opens many possibilities for creating sophisticated embedded projects and puts the Raspberry Pi a long way ahead of its competitors.

Best wishes,
Garry.

[Gavinmc42]

It's strange but some people like C++
Well done, I was wondering who was going to be next to do VC4 baremetal.
.
Any and every baremetal progress is good for the industry.
Not everyone wants or needs to use Linux.

Wonder if that uGUI can be ported to Ultibo?
I don't read C++, is that pixel or gpu based?
Hmm, button states etc, might have to pinch that idea
Ok, I can read a little bit of C++

[rst]

Congratulations Rene, We know how much work is required to produce a complete implementation of the VCHIQ protocol and Userland libraries so your effort should be applauded not only by those using the Circle project but by anyone interested in serious bare metal development.

Having two publicly available bare metal implementations of standards based graphics APIs opens many possibilities for creating sophisticated embedded projects and puts the Raspberry Pi a long way ahead of its competitors.

Best wishes,
Garry.

Thank you very much, Garry! I think, it was a great achievement, when you have ported the entire VCHIQ driver and Userland libraries already some time ago. I had it easier, because I did read about your work and for example it is already a big help, if you know what is important, to get it running, and what can be left out (e.g. the shared memory and the file service driver).

What I really like on this small (but great) machine is, beside it is able to do such things like accelerated OpenGL ES and OpenVG graphics for 35$ (or less), that it has a community, which is able to appreciate the work of others. Let's continue trying to provide great bare metal applications or platforms for it, be it based on Ultibo, Circle or on other platforms.

Best regards,

Rene

[rst]

It's strange but some people like C++
Well done, I was wondering who was going to be next to do VC4 baremetal.
.
Any and every baremetal progress is good for the industry.
Not everyone wants or needs to use Linux.

Wonder if that uGUI can be ported to Ultibo?
I don't read C++, is that pixel or gpu based?
Hmm, button states etc, might have to pinch that idea
Ok, I can read a little bit of C++

https://dictionary.cambridge.org/dictio ... ish/thanks
http://embeddedlightning.com/ugui/
https://www.tiobe.com/tiobe-index/

[Memotech Bill]

If I may make an observation on USB timing, for those RPi models without a built-in hub, the 20ms timeout waiting for the connection of the root device (Routine CDWHCIDevice::EnableRootPort (void) in file "dwhcidevice.cpp") can be a bit short. It was causing me to fail to recognise a keyboard plugged into a model A.

Since the routine WaitForBit (..., 20); polls the connection bit every 1ms, and returns as soon as the bit is set, there is no great penalty in increasing the timeout, as for those models which do have a built-in hub will connect and return quickly anyway.

Circle supports the following accelerated graphics APIs now:

OpenGL ES 1.1 and 2.0
OpenVG 1.1
EGL 1.4
Dispmanx

Great, Dispmanx is just what I need for up-scaling the display.

This support ... cannot be built on Raspbian.

I wonder why not? Something I will probably look into.

If I may be permitted a quick plug for Andy Key's Memotech emulator, which I am porting to Circle, http://primrosebank.net/computers/rpi/p ... memupi.htm

[rst]

/Joke mode off/

@Gavinmc42

uGUI is not accelerated in Circle. It was an early attempt to provide a GUI in Circle, but works well. It's an interesting question, how an accelerated GUI can be provided e.g. using OpenVG. The API calls are relatively time expensive, so they should be reduced. OpenVG allows to create a long "path", which can be drawn with one API call. This can be repeated many times. BTW The accelerated graphics code is in circle/addon/vc4/interface. The provided samples come from the Userland code and are nearly unchanged.

I think, C and C++ are still the programming languages, which are most often used for such applications, we talk about here. But Ultibo, which uses Pascal has a lot supporters, probably much more than Circle. So the language is not the only point and maybe not the most important one.

I thought about, for which reasons people do bare metal programming and there are some of it. You are not restricted, if you want to access to hardware, it should be more easy to understand, because there are not that much different software layers. That's good for learning. And normally the interrupt latency is much smaller, which allows applications, which are not possible with Linux. Also you can switch off the device without destroying data. Recently I read, that a big company are still providing "bare machine" solutions for their hardware. There is a "market" and we can make it together.

So thanks for recognizing Circle, even if you like Pascal more than C++.

[rst]

If I may make an observation on USB timing, for those RPi models without a built-in hub, the 20ms timeout waiting for the connection of the root device (Routine CDWHCIDevice::EnableRootPort (void) in file "dwhcidevice.cpp") can be a bit short. It was causing me to fail to recognise a keyboard plugged into a model A.

Since the routine WaitForBit (..., 20); polls the connection bit every 1ms, and returns as soon as the bit is set, there is no great penalty in increasing the timeout, as for those models which do have a built-in hub will connect and return quickly anyway.

Yes, but you get a penalty, if no USB device is attached. But I can increase this value a little bit. Which value did you chose, to get the keyboard running?

This support ... cannot be built on Raspbian.

I wonder why not? Something I will probably look into.

I tried to get it built on Raspbian with the standard compiler and libraries. At first there were some #ifdef __unix__ in the Userland code, which I did not remove so far. __unix__ is defined on Raspbian, but not by the embedded toolchains I'm normally using. But the more serious problem is the library. To be able to build the Userland code, now I link Circle with libm.a provided and this one is not compatible with Circle. I got many unresolved externals. Circle is prepared for newlib compatible libraries. I don't know, if this can be sorted out that quick.

If I may be permitted a quick plug for Andy Key's Memotech emulator, which I am porting to Circle, http://primrosebank.net/computers/rpi/p ... memupi.htm

That's an interesting project. I had a quick look on it.

[Memotech Bill]

Yes, but you get a penalty, if no USB device is attached. But I can increase this value a little bit. Which value did you chose, to get the keyboard running?

I followed the example in CUSBStandardHub::EnumeratePorts and picked up a value from pOptions->GetUSBPowerDelay (). For the cheap keyboard I was using, I needed to set the delay to 1000ms.

If you were building an application which did not need any USB device attached, would you even link the USB library? And this is for models which do not have ethernet.

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?

[rst]

I followed the example in CUSBStandardHub::EnumeratePorts and picked up a value from pOptions->GetUSBPowerDelay (). For the cheap keyboard I was using, I needed to set the delay to 1000ms.

You are right. That's a real issue. The time between powering on the port and deciding, if there is a device attached, is much too short. I will set it to the "usbpowerdelay" value as suggested. Thanks for reporting this.

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.

[Gavinmc42]

uGUI is not accelerated in Circle

But it could be
Turns out the accelerated graphics is the easy bit, apart from screen width and height not a single pixel was hurt.
https://ultibo.org/forum/viewtopic.php?f=9&t=1269
Much more to come this weekend

Free Pascal, specifically Ultibo was the first tool I found that had a familiar IDE type tool set, like all the microcontroller IDE's I had used for decades.
It also had great libraries written by better coders than me, meaning I really only needed to code the application and not the low level stuff.
Still need to learn lots of Free Pascal , so much stuff can be ported.
Your Circle stuff is getting there now, it has a bunch of needed libs to make interfacing to hardware much less painful.

I don't really care about languages as long as they do what I want to do.
Since Pi's came out I had to learn a dozen or so, even Awk and Sed got used
After a while they mostly start looking the same, I use what works the best and quickest
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++.

I do use C++ now but don't tell anyone, it is buried in the Arduino stuff
I wonder if Circle could be used with the Arduino IDE?
Apart from hardcore coders most hobbyist/Arduino users don't care about the language debate.
They just want to make stuff that works quickly and is easy to do.

Ultibo makes use of Lazarus and Free Pascal, lots of code that is well tested with usable IDE.
Your Circle stuff needs the same easy usability for me to use it.
I would love to see baremetal Pi's make it onto the Arduino platform, choices are always good.
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.

There is a very good reason companies like Adafruit, Sparkfun , Pimoroni etc are thriving.
Electronics is fun and much easier to do than the old days, even a bit of coding with the right tools is much less painful and quicker to learn.

And many thanks for the embedded lighting link, PSoCs are my main micros these days, did not even think about using them for LCD.