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

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

Wed Apr 10, 2019 3:26 pm

Hi rst! thank you very much for your answer.

patrick_h
Posts: 6
Joined: Mon May 13, 2019 9:35 pm

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

Mon May 13, 2019 10:10 pm

Hey there!

I just succesfully sent the first bytes from a rpi 3b+ Circle program to a windows com port with a bluetooth stack that I have written mostly from scratch. I will, in the upcoming months, make the source code, as well as my mods to Circle, and a number of other interesting additions to Circle, public. In due time.

Right now I just want to take a deep breath. It has been a very hard month of sleepless nights and horrible frustration trying to understand the bluetooth core specs, reverse engineering linux drivers, and generally banging my head against a wall, repeatedly, until finally the wall gave way to my bruised and battered head.

Although I have almost 50 years of programming experience, nothing I have ever done before has been this difficult, and that includes managing teams of 60+ engineers, owning 3+ million lines of source code, or being part of one of the most successful software projects in the history of computing. Nothing has compared to the difficulty of getting things working on these little computers.

I only started with, got my first Arduino, in January of this year. Since then I have been through dozens of mpu's and controllers, and followed a thousand leads, to get to this one point. And I am not done.

I will post more later. But for now, there are two things I would like to do. First I need to thank a few organizations and people, not necessarily in order of importance, but moreso in the order I encountered them on this journey

- the arduino foundation, without which I would have never even become involved

- fellis from circui[email protected] for the HSL which led to a few months of max3421 stuff, and from which I learned the basics.

- Paul Stoffregen who is a force unto himself. The teensy changed my life. I remain amazed at what this man has accomplished.

- dwelch, who laid a nice trail of breadcrumbs for a beginner like me to follow. He didn’t have to, and I thank him for taking the time to lay it out in a series of steps

- Chris Marin, who’s Placid project was an important stepping stone to getting me to Circle, and, of course ...

- rst … what can I say. That you conceived of, and implemented, Circle, is right up there with Paul’s work. Amazing.

You guys are the best, and the brightest, programmers I’ve ever seen.

Not that Circle is without a few warts and bumps. In addition to the (completely reworked) bluetooth stack, I have (completely reworked) created an i2s audio device that has input, as well as output, added a mini-uart serial port, and combined dwelch’s, cmarrin’s, and rst’s bootloaders into one piece of code that also uses fat32 to “flash” the rpi, either from serial, ethernet, tftp, or http. Oh, and I added some simple scripts for building Circle on Windows to make this beautiful codebase more accessible to everybody.

As I said, I will be making the source for all of this public at some point. But after trying to figure out the BT specs, and (re) implementing HCI, L2CAP, SDP, and RFCOMM, and finally getting a few bytes to go from an rPi, over the air to a Windows SPP com port, today, at this moment, all I can say is “yay”.

Yay!

- patrick

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

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

Tue May 14, 2019 11:02 am

Very well done Patrick and thank you!

rst

Nakame
Posts: 16
Joined: Fri Jul 05, 2019 9:24 am

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

Wed Jul 24, 2019 2:17 pm

Hello,

First of all , I've been using circle library for over a week now and it is absolutely fantastic , i am very new to bare metal programming and have been trying to make a real time operating system and that library has been a very good start. However, i do need a little bit of help with the multi-core section of that library.

I have been trying to make a multi-core program using interrupt (more specifically , a CUserTimer that trigger every 125 microseconds) but my previous experience ( as in assisted by an operating system ) did not teach me how to use spinlocks and such.

Could you give me a small explanation ( or a tiny code example) on how to use interrupt in a multi core environment ? i would be very grateful :)

Anyway thanks again for your work, i hope i can produce some useful programs with it that i could share too ^^ have a nice day !

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

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

Wed Jul 24, 2019 7:29 pm

@Nakame

There is not much special in handling interrupts in a Circle multi-core application. What you have to know is, that interrupts (IRQ and FIQ) in Circle are always handled on CPU core 0. The cores 1-3 are dedicated to the specific tasks of the application. For instance in a audio synthesizer application cores 1-3 can be used to calculate the audio samples doing some floating point calculations, while core 0 is handling the external interrupts.

There is one exception from this rule: You may interrupt a CPU core on behave of another core by sending an inter-processor-interrupt (IPI). A core has to call CMultiCoreSupport::SendIPI() to do this and the target core will call CMultiCoreSupport::IPIHandler() then to handle this IPI.

You may need some synchronization between the different cores, if you access and modify data, while is shared between the cores. You have to prevent data from being modified from two cores at the same time or while it is read from another core. This can be done by using the class CSpinLock. Using it is relatively simple:

Code: Select all

m_SpinLock.Acquire ();

// access or modify the shared data

m_SpinLock.Release ();
This template has to be used in any case, where shared data is used. Acquiring the spin lock does only succeed, if there is no other core, which has already acquired the same spin lock. Otherwise the execution waits inside the Acquire() method, until the other core calls the Release() method.

Hope it helps.

Nakame
Posts: 16
Joined: Fri Jul 05, 2019 9:24 am

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

Thu Jul 25, 2019 8:07 am

Hey

Thanks for your fast response, i'm feeling a bit stupid but yea , the interupt did work perfectly on core 0 as you said ( i could have found that out but i guess i lost patience too fast on this one)

As for the spinlock , i did not think it was that simple, but it works to just like you said. I'm sorry to have wasted your time with those questions that were, as it turn out, way more simple than i thought. I am still struggling a bit to warp my head around how multicore is really working under the hood but nothing i can't find out via trial and error :)

Thank you again for the beautiful library and the help provided ^^

fanoush
Posts: 484
Joined: Mon Feb 27, 2012 2:37 pm

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

Thu Jul 25, 2019 8:15 am

patrick_h wrote:
Mon May 13, 2019 10:10 pm
bluetooth stack that I have written mostly from scratch. I will, in the upcoming months, make the source code, as well as my mods to Circle, and a number of other interesting additions to Circle, public. In due time.
Amazing, thanks, looking forward to your contributions. As for bluetooth stack - this is classic bluetooth or BLE or both? Did you check or based your work on other existing open source bluetooths stacks?

As for BLE I am aware of NimBLE as part of apache mynewt and the BLE stack in ZephyrOS. Now when checking it, there is also lwBT mentioned in https://en.wikipedia.org/wiki/Bluetooth ... mentations

The ZephyrOS stack is even bluetooth certified https://launchstudio.bluetooth.com/ListingDetails/70189

Do you have any plan for certification of your stack? Or is it not needed as the module is certified including its firmware?

EDIT: checked more about certification and there are more of them - one for the wireless hardware itself (which raspberry pi module already must have) then there is bluetooth host(?) certification which is the software implementing bluetooth profiles - which is in case of raspberry pi maybe in the firmware of wireless chip(? or maybe partly also in the bluez stack?) and in case of the BLE stacks I mentioned it in their source and needs to be certified again with each release e.g for NimBLE used in apache NEWT the certification is mentioned in each release notes e.g. here.

However I am still confused if software like bluez (or your stack) needs certification/qualification and how it works in practice when e.g the BlueZ packages in linux are often updated, they list some qualifications here http://www.bluez.org/qualification/ but these are in general pretty old.

Anyway, just trying to figuring out how it works.
Last edited by fanoush on Fri Jul 26, 2019 2:55 pm, edited 1 time in total.

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

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

Thu Jul 25, 2019 10:20 am

Nakame wrote:
Thu Jul 25, 2019 8:07 am
Thanks for your fast response, i'm feeling a bit stupid but yea , the interupt did work perfectly on core 0 as you said ( i could have found that out but i guess i lost patience too fast on this one)
You are welcome. I do not think, your questions were simple and it's OK to ask them. The answer may be simple, but a question is not.
I am still struggling a bit to warp my head around how multicore is really working under the hood but nothing i can't find out via trial and error :)
Starting a secondary CPU core is also not that difficult. There are three mailbox registers, one for each secondary core, where you have to write the start address of your code to. Then you have to execute a "sev" instruction and the respective core will jump to this address. In Circle this is implemented in lib/multicore.cpp. This is valid for AArch32, in AArch64 there are three memory locations used instead of the registers.

Nakame
Posts: 16
Joined: Fri Jul 05, 2019 9:24 am

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

Tue Jul 30, 2019 7:28 am

Hello !

On this beautiful day i come here to , once again, seek your invaluable help in this multicore matter that i still have (to my great shame). however i feel resolving this very simple problem (simple for you of course since i personally have no clew XD ) SHOULD make that concept finally enter my very thick skull.

So here is my code :

Code: Select all

void    TMulticore::Run(unsigned nCore)
{
    while (1)
    {
        if (nCore == 0 && !m_isactive[0])
        {
            m_isactive[0] = TRUE;
            m_kernel->Write("Sending function to core\n"); // <==== Works fine when alone.
            functionCore0(m_datacore[0]);
        }
        if (nCore == 1 && !m_isactive[1])
        {
            m_isactive[1] = TRUE;
           // m_kernel->Write("Sending function to core\n");  <===== If uncommented , crash.
            functionCore1(m_datacore[1]);
        }
        if (nCore == 2 && !m_isactive[2])
        {
          //  m_kernel->Write("Sending function to core 2\n"); <===== If uncommented , crash.
            m_isactive[2] = TRUE;
            functionCore2(m_datacore[2]);
        }
        if (nCore == 3 && !m_isactive[3])
        {
           // m_kernel->Write("Sending function to core 3\n"); <===== If uncommented , crash.
            m_isactive[3] = TRUE;
            functionCore3(m_datacore[3]);
        }
    }
}
So i am sure you already realized the problem here. m_kernel is basically a pointer pointing to my CKernel object. I feel like this is exactly a situation where i should use spinlocks . I tried simply putting a m_spinlock.Aquire() and m_spinlock.Release() around the m_kernel->Write call , but nothing changed. I have 4 error on the screen :

- assertion failed : nTargetLevel == IRQ_LEVEL || nTargetLevel == FIQ_LEVEL (one line of that error)
-assertion failed : !(nLocalPending & ~(1 << 1 | 1 << 8) (3 lines of that error)

I can deduce the meaning of the first one , but dont understand at all the meaning of the second one.

Here are the 4 different functions intended for each of the core. Just basic while loop for now :

Code: Select all

void    TMulticore::functionCore0(void *data)
{
    CGPIOPin    testpin(13, GPIOModeOutput);

    while (1)
    {
       // m_spinlock->Acquire();
       // m_kernel->Write("Sending function to core 0\n");  <=== If uncommented , crash.
       // m_spinlock->Release();
        testpin.Invert();
    }
    m_isactive[0] = FALSE;
}

void    TMulticore::functionCore1(void *data)
{
    while (1)
    {
    }
    m_isactive[1] = FALSE;
}

void    TMulticore::functionCore2(void *data)
{    
    while (1)
    {
    }
    m_isactive[2] = FALSE;
}

void    TMulticore::functionCore3(void *data)
{
    while (1)
    {
    }
    m_isactive[3] = FALSE;
}


so here it is. I am sure it is very basic but i would like to know how to correctly take a pointer to my CKnernel object and print something on screen which each core, possibly using spinlocks ( and learning how to use those in the process) so i can finally make some progress on multi core.

as always , thank you very much for the time you spend on my problem, i hope someday i'll be able to repay you :)

Have a beautiful (but not too hot, hopefully) day.

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

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

Tue Jul 30, 2019 10:17 am

@Nakame

Can you please put the whole source code of your test program somewhere on the Internet, so that I can test it? Unfortunately I cannot find the problem from the parts of the code, which you have posted. Which RPi model do you use?

If you call m_Screen.Write() in CKernel::Write() to display the string, you do not need a spin lock, because the class CScreenDevice is multi-core safe internally.

Nakame
Posts: 16
Joined: Fri Jul 05, 2019 9:24 am

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

Tue Jul 30, 2019 1:29 pm

sure, made a git real quick for you.

here you go : https://github.com/talemari/SerlemOS

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

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

Tue Jul 30, 2019 2:38 pm

Nakame wrote:
Tue Jul 30, 2019 1:29 pm
sure, made a git real quick for you.

here you go : https://github.com/talemari/SerlemOS
Thanks. I think, I have found the problem. m_multicore.addKernel() has to be called before m_multicore.Initialize() and not later in CKernel::Run(), because the secondary cores 1-3 will be already started inside m_multicore.Initialize(). So when they call m_kernel->Write() in TMulticore::Run() m_kernel is not initialized yet and an invalid pointer is used, which leads to an exception. Just change the file srcs/kernel.cpp this way:

Code: Select all

diff --git a/srcs/kernel.cpp b/srcs/kernel.cpp
index 306eeee..47384b9 100644
--- a/srcs/kernel.cpp
+++ b/srcs/kernel.cpp
@@ -66,6 +66,7 @@ boolean CKernel::Initialize (void)
                m_usertimer.Initialize();
        }
 
+       m_multicore.addKernel(this, nullptr);
        if (bOK)
        {
                m_multicore.Initialize();
@@ -88,7 +89,6 @@ TShutdownMode CKernel::Run (void)
 
        m_Logger.Write (FromKernel, LogNotice, "Compile time: " __DATE__ " " __TIME__);
        m_multicore.setDataCore(1, &m_sv);
-       m_multicore.addKernel(this, nullptr);
 //     this->Write(str);
        m_multicore.Run(0);
 /*     while (1)

Nakame
Posts: 16
Joined: Fri Jul 05, 2019 9:24 am

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

Wed Jul 31, 2019 8:01 am

hey;

It work just as you said , i did not realize the cores were starting at the initialize function ( i should have known :/ )

thank you very much !

xlar54
Posts: 50
Joined: Tue Aug 20, 2013 5:08 am

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

Wed Jul 31, 2019 10:42 am

Patrick - you should know that in the retro community, Circle has had a MASSIVE impact. The Pi1541 project allows us to emulate 1541 and 1581 disk drives using bare metal / Circle as the core. Most people who use Pi1541 will not understand the effort you did in bringing it to life, but I do (as does Stephen). You're the unsung hero of us Commodore enthusiasts and we thank you.

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

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

Wed Jul 31, 2019 1:34 pm

Thank you very much, xlar54. My name is not Patrick, but because I do not know another bare metal environment for the Raspberry Pi with the name Circle, I guess you are talking about my project. I did read about several retro computer projects (including Pi1541) using Circle and I'm glad that Circle can help to do such awesome things, like you do.

Rene

Nakame
Posts: 16
Joined: Fri Jul 05, 2019 9:24 am

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

Thu Aug 01, 2019 12:10 pm

Hello again :)

now that the multicore is working as expected ( thanks again about that by the way, now that i know that i need to send pointers BEFORE initialization, so many things start to make sens). However now i'm trying to figure out how to use the file manager. My objective it to create, read and right a file on the sd card in order to make a configuration file. I tried to take exemple on sample 07 and 15 but none of them can find the USB key i plugged in.

So what is the procedure to write and read from a file ? it seem like i need to find the partition i want to write in , but how can i find the name of that partition ?

LdB
Posts: 1280
Joined: Wed Dec 07, 2016 2:29 pm

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

Thu Aug 01, 2019 4:18 pm

You need a FAT32 reader. That converts the raw sectors into index tree structure which tells you what sectors your file is on. A sector of the SD card is 512bytes so basically you read sector 0 which will be a Bios parameter block or a master boot record and off you go from there.

You can tell if sector 0 is a BPB (https://en.wikipedia.org/wiki/BIOS_parameter_block) because the first 3 bytes will be eb xx 90, or e9 xx xx, if they aren't that it's a master boot record.

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

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

Thu Aug 01, 2019 4:38 pm

Nakame wrote:
Thu Aug 01, 2019 12:10 pm
However now i'm trying to figure out how to use the file manager. My objective it to create, read and right a file on the sd card in order to make a configuration file. I tried to take exemple on sample 07 and 15 but none of them can find the USB key i plugged in.

So what is the procedure to write and read from a file ? it seem like i need to find the partition i want to write in , but how can i find the name of that partition ?
sample/15-files should be able out-of-the-box to read and write a file on the first FAT16 or FAT32 partition of an attached USB flash drive. If this doesn't work, there is something going wrong. Do you get any messages?

If you want to read/write a configuration file, have a look to addon/Properties/sample. It reads and writes a configuration file in .ini format ("key=value" pairs) from/to the SD card.

The first FAT partition is found automatically. Its name is "emmc1-1" (SD card) or "umsd1-1" (USB flash drive).

Nakame
Posts: 16
Joined: Fri Jul 05, 2019 9:24 am

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

Fri Aug 02, 2019 2:36 pm

hey !

Did not have the time to try it out but this sample addon seem to be exatly what i am looking to do so thats perfect. Your reply gave me a little doubt about the filesystem on my usb key so that's another thing i will have to check ( but i am fairly sure it was on fat32).

Ill keep you posted when i manage to make it work , thanks a lot !

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

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

Sun Sep 01, 2019 1:23 pm

rst wrote:
Wed Mar 20, 2019 10:54 pm
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.
Hi there, i'm back on this project :) I'm having some issue with handling input. I've activated USE_USB_SOF_INTR (as per your suggestion to correctly handle the gamepad). But now it's giving me problems with the keyboard. It looks like it's randomly losing keystrokes (both up and down) now and then.

The setup (in single core mode) is as follow: i have a spinlock that's acquired and released in the raw keyboard handler. Inside, keystrokes are detected and added to a queue. In the mainloop, the queue is read from and processed (again under spinlock).

What happend when a key is pressed but the main loop hold the spinlock? does the IRQ get lost or is it "queued" somehow? It seems to me that it kind of get lost. If i remove some code under spinlock in the main loop (not strictly necessary for input handling), the issue seems to get better.

I made the code on both section as small as possible and now i have a reasonably working system, but if it's as i think, it can still happen, just much more rarely.

Do you have any hint?

Many thanks

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

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

Sun Sep 01, 2019 5:26 pm

@msx80 Good to see you back on this project. I can only suggest to release the spin lock as quick as possible, so that your main loop is only reading the keyboard buffer with spin lock held and does the processing outside of the spin lock protected region. Even if it is theoretically not impossible to lose keystrokes, it should be very unlikely then.

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

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

Wed Sep 04, 2019 9:07 am

Circle 40 with Raspberry Pi 4 support is available:

https://github.com/rsta2/circle
https://github.com/smuehlst/circle-stdlib

Please note that there is a recent change in the Raspberry Pi firmware, which modifies the handling of 64-bit kernels. With the firmware from today on you need the following config.txt file on your SD card to enable AArch64 mode:

Code: Select all

#
# Enable 64-bit mode (AArch64)
#
# This file must be copied along with the generated kernel8[-rpi4].img
# onto a SDHC card with FAT file system, if 64-bit mode is used.
#

arm_64bit=1

[pi2]
kernel=kernel8.img

[pi3]
kernel=kernel8.img

[pi3+]
kernel=kernel8.img

[pi4]
kernel=kernel8-rpi4.img
In AArch32 mode there is still no config.txt file needed.

patrick_h
Posts: 6
Joined: Mon May 13, 2019 9:35 pm

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

Thu Sep 05, 2019 4:52 pm

Congratulations!

Good work! I was wondering if you were going to continue and implement rPi4 specifics.

I have re-forked and more selectively applied my changes at https://github.com/phorton1/circle and separated out my additions into a separate repository at https://github.com/phorton1/circle-prh, which includes:

- my port of the Teensy Audio Library
- support for ili9486/xpt2046 touch screens
- limited support for generic touch screens (LCDWIKI library port)
- my bluetooth stack (finally posted, without regards!)
- a wxWidgets like windowing/event system (wsWindows)

... and various other stuff. I am/was in the middle of writing the wsWindows system when I re-merged with your new source. I had not noticed the littlevgl addon ... my wsWindows was based off of ugui. Now that I have built littlevgl and seen it, I have to go back and re-think my decision to implement, or at least how I implement, a general windowing system on Circle. It certainly looks nice and is worth the effort.

As an aside, I have been experimenting with run-time linking/loading. It's brain-dead simple and goes like this.

It turns out that you can link against an elf file. So, I build the kernel, like you normally would, and it runs on the rPi. Then you write a program that makes calls to things in the kernel, but which is linked into a seperate image. In the same way the kernel is always loaded at 0x80000 (or whatever), I picked an arbitrary location for the executable of 0xc0000 (about halfway up in the "kernel memory"). The program img file is only a few bytes (1500 bytes), yet it can call anything in the kernel ... including object constuctors. So my example, at https://github.com/phorton1/circle-prh/ ... inkerTest2, which uses my fledgling windowing system, creates a window with a button in it, and allows the button to be pressed. The "shell" program can switch between two different executable programs.

I didn't mean to start talking about this ... I have some other stuff I want to talk to you about ...

but to finish this sub-sub-sub topic a little, I know it's not perfect. It's not real "run-time" linking. The "program" is statically linked against a fixed kernel and must be (currently) loaded at a fixed location. But to support "real" shared libraries and run-time linking, the files end up growing because of the symbolic information in them ... and really part of what I am trying to do is compartmentalize and streamline my development process, so, for example, I don't have to rebuild and upload the kernel for every change I make. Even this crude approach *should* allow me to, once I have arrived at a fairly stable kernel, develop applications completely separately from kernel development.

:-)

It's almost like an actual nascent operating system ... I guess I saw a movie about Bill Gates or something and was thinking about the basics ... "what was MSDOS" ... or "what is a disk based operating system" ... or "what the heck is an operating system, anyways?", but I have an inkling to make Circle a "resident operating system" with general abilities, like a persistent shell, maybe with a windowing system ... think mini-ubuntu ... more on this later, I suppose.

Related to that are the (many) notion(s) about things like run-time configurable device drivers, display devices, etc. For example here, I am thinking about making the audio library DETECT the codec that is connected and switch to the proper i2S device. Most of the rest of the audio system can be instantiated at run-time, even flexibly, in my vision, through a UI.

Anyways, thanks again, and always, for your hard work. In re-forking I have attempted to minimize the changes I needed to make to Circle to be compatible with my code ... you remember ... and that should also allow me to re-merge your upstream changes more easily in the future.

It's about some of those changes, and merging them upstream, that I want to talk to you separately about ...

- Patrick

patrick_h
Posts: 6
Joined: Mon May 13, 2019 9:35 pm

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

Thu Sep 05, 2019 5:19 pm

@rsta,

STATIC POINTERS TO SINGLETON OBJECTS

I wish you wouldn't. Don't! Think about it.

You have these objects upon which other objects must register a callback. So objectA is already keeping a pointer to the static method on objectB. You then typically have objectB create a static singleton pointer to itself which is used in the static callback method to get to the object.

THIS LIMITS YOU TO ONE POSSIBLE INSTANCE OF objectB !!!

By simply adding a second "void *" parameter to objectA (the instance of objectB to call), and passing THAT to the static method on objectB, you can now (more correctley, in my opinion) have multiple instances of objectB. ***

It is not a question of memory usage ... both schemes use two void * pointers. But is a fairly huge change to the possible usage models.

An example case is that I might want to have TWO different polymorphic instances of the same user interface code .. one running for example, on the rPI HDMI screen and another running on a separate 3.5" touch screen.

Your current implementations of UGUI and LittleVGL, and in general this usage model of static pointers to singleton object, assume that there will be one, and only one instance of the UI. There is no reason to introduce this artificial limitation.


BASE CLASSES FOR COMMON OBJECTS

Likewise in my implementation I have added base classes for "Screen Devices with a PutPixel method" and "Touch Devices" under your existing classes, and implemented the ili9486/mpt2046 rPi touchscreen in terms of those base classes, so that I can, sheesh, polymorphically pass them to a UI constructor.

Please try to remember that there is more than one way to skin a cat! Consider that there is a bewildering plethora of different screen and touch devices, for a moment, and reflect on the fact that there is hardwired use of CScreen in virtually every program you have written for Circle and that whenever you use CTouchScreen or CMouse you are assuming there is only one cat, and exactly one knife!

--------------------

I am not saying that my code is perfect, by any stretch ...

But I urge you to consider pulling my base classes for CScreen and CTouchDevice, and to also consider the way that I have modified various objects (CTouchDevice, CMouse, and CMouseBehavior) to also accept an instance pointer in their registration methods.

I'd like to hear your reply, if any, before I make a pull request ....

I've never made a pull request from anyone before, so I'm not sure how they work. If it will help you to understand this post for me to make a pull request, please let me know!

Otherwise, thanks for taking the time to read this, and please know that I am still 24/7 on Circle ... https://hackaday.io/project/165696-rpi- ... guitar-rig ... well, except for all of last month cuz I got a 3D printer LOL ... https://hackaday.io/project/166825-prus ... experiance

And as always, thanks for your hard work, and thanks for reading this!

- Patrick

*** reminder ... I told you the story of how I made a static pointer to a global object early in a major project development, when there were only four programmers, and that 10 years later it took 15 people 6 months to rectify the situation. Heed 40 years of experience! I urge you to review your entire use of static pointers to objects, now, relatively early in the lifecycle, with the thought that Circle will exist for 50 years into the future and have millions of applications ...

patrick_h
Posts: 6
Joined: Mon May 13, 2019 9:35 pm

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

Thu Sep 05, 2019 5:49 pm

@fanoush ...

I just saw post #462 from @famoush on Thu Jul 25, 2019 8:15 am

I'm not sure how to reply to a particular post, so here goes .my best effort ....
Amazing, thanks, looking forward to your contributions. As for bluetooth stack - this is classic bluetooth or BLE or both? Did you check or based your work on other existing open source bluetooths stacks?

As for BLE I am aware of NimBLE as part of apache mynewt and the BLE stack in ZephyrOS. Now when checking it, there is also lwBT mentioned in https://en.wikipedia.org/wiki/Bluetooth ... mentations

The ZephyrOS stack is even bluetooth certified https://launchstudio.bluetooth.com/ListingDetails/70189

Do you have any plan for certification of your stack? Or is it not needed as the module is certified including its firmware?
Uhm ... nope. No plans for certification. I'm just a guy, and there's a lot of other code to write. I looked at virtually every existing implementation, hint, or partial implementation of a BT stack that I could find on the internet. Almost uniformly they are either (a) very expensive with licensing requirements, or (b) would be hugely complicated to port to Circle.

As far as (b) goes, if anyone else manages to get a BT stack working on Circle, I'd sure like to know about it.

Yestereday, I (finally) posted the BT code within https://github.com/phorton1/circle-prh ... I compiled and quickly made sure the 09-testBT program came up, enumerated devices, and did a simple SDP request to my laptop.

Bluetooth is hugely complicated. So much so that I'm not even sure I'm gonna try to use it in my project https://hackaday.io/project/165696-rpi- ... guitar-rig ... I got as far as being able to make COM port connections to my windows laptop and an Android, but it is not perfect, nor is it particularly fast.

I may re-visit it at some point, but no guarantees. What you see is what you get. It remains, as far as I know, the only example of actually using the radio on the rPi from Circle. I'd also like to know if anyone has anything else that can make the rPi BT or WiFi work with Circle. I'm not talking about separate radios, BT05's, esp8266's, etc ... I'm talking about the radio on the BCM283x chip ....

It seems (remains, has always been) silly (stupid) that broadcom does not release the videocore details. I understand now why rsta did not want to go further with BT, and why NO-ONE has implemented Wifi in bare metal ... not even Ultibo. I have to check into rsta's reference to somebody implementing SSH (crypto), as I believe that's another reason that WiFi is so difficult.

So, if anyone can use my code, or learn from it, great!

If ANYONE HAS WORKING BT OR WIFI CODE for Circle that uses the RPI RADIO directly, I'd sure like to know :-)

- Patrick

Return to “Bare metal, Assembly language”