Delays and thermal management

Discussion and questions about programming with Ultibo.
Gavinmc42
Posts: 1656
Joined: Sun Jun 05, 2016 12:38 pm
Location: Brisbane, Australia

Re: Delays and thermal management

Postby Gavinmc42 » Sat Feb 02, 2019 10:46 am

100uS is a 10KHz interrupt rate :o
That is pretty good for a real time operating system running on it's own core.

For lots of RT systems 100Hz is good enough, drones are at 400Hz, what could 10,000Hz be good for?
How do cores communicate to each other?
Another two cores could run at 100uS?

That's a fixed rate, variable rate on three cores, good enough for circular interpolation on 3 axis CNC machine?
Not a R core ARM so wonder what latency/jitter there is on the A cores?
pik33
Posts: 887
Joined: Fri Sep 30, 2016 6:30 pm
Location: Poland
Contact:

Re: Delays and thermal management

Postby pik33 » Sat Feb 02, 2019 11:58 am

what could 10,000Hz be good for?


Software based pwm :) to control something without switching off the sound
Brutus
Posts: 32
Joined: Sun Jan 20, 2019 1:24 pm

Re: Delays and thermal management

Postby Brutus » Sun Feb 03, 2019 5:59 am

I use this datalogging to monitor my old japanese car.

The injectors opening time for example require that kind of datalogging frequency because they open like 2.1 to 2.3 milliseconds at idle.

The limitation will come from USB writing speed and memory regarding the number of signals I can monitor at the same time, not CPU power.
Ultibo is fantastic!
Gavinmc42
Posts: 1656
Joined: Sun Jun 05, 2016 12:38 pm
Location: Brisbane, Australia

Re: Delays and thermal management

Postby Gavinmc42 » Sun Feb 03, 2019 7:15 am

I use this datalogging to monitor my old japanese car.
Wow, did not think it would be fast enough.

My new Honda has HDMI and USB on the media unit.
Will the USB power the Zero W with BT connection to ODB BT dongle?
Does ODB give enough info to do a 3D ignition MAP?
Hack ECU's with a Pi?

Because Ultibo does not take much ram I usually make a big ram drive and log to that.
Once the sample time is over then I save to flash/uSD or USBstick.
A few years back they made USB dram drives.

Not sure if my only SSD will write faster.
The GPIO does have SMI mode which is basically IDE.
What else is around?
https://www.transcend-info.com/Embedded/Products/No-823
Brutus
Posts: 32
Joined: Sun Jan 20, 2019 1:24 pm

Re: Delays and thermal management

Postby Brutus » Sun Feb 03, 2019 11:16 am

Hi Gavin,

I forgot to answer your other questions BTW:

Gavinmc42 wrote:100uS is a 10KHz interrupt rate :o
That is pretty good for a real time operating system running on it's own core.

For lots of RT systems 100Hz is good enough, drones are at 400Hz, what could 10,000Hz be good for?


I actually did some trials at 100kHz and it worked, but the safety margin was not sufficient for my purpose.
I do a rough compression of the data upon each insertion so it's not like it's only changing a single value, there's a bit of code in there (I optimized this code by checking the amount of assembly code that was generated by each FPC line code).

Gavinmc42 wrote:How do cores communicate to each other?


Cannot be more straightforward: Memory is shared, so you just use global variables and access them like there was no multi-core system.

Gavinmc42 wrote:Another two cores could run at 100uS?


Garry might correct me on this, but from what I saw, only CPU 2 and CPU 3 will be happy to run at 100µs for my application.
CPU 1 deals with the USB and a few other threads and CPU 0 is my workhorse.
But if you migrate threads correctly, having 3 CPUs running at 100µs is perhaps doable.

Gavinmc42 wrote:That's a fixed rate, variable rate on three cores, good enough for circular interpolation on 3 axis CNC machine?
Not a R core ARM so wonder what latency/jitter there is on the A cores?

[/quote]

I would use one cheap Arduino hardware as SPI slaves with Ultibo as a master for this kind of task.
I think it would be much easier, but that's just me! :D

Gavinmc42 wrote:My new Honda has HDMI and USB on the media unit.
Will the USB power the Zero W with BT connection to ODB BT dongle?
Does ODB give enough info to do a 3D ignition MAP?


My car is too old to have OBD :lol:
From my little knowledge about OBD, it should be too slow to collect a 3D ignition map (but I might be wrong).

Gavinmc42 wrote:Hack ECU's with a Pi?


I just datalog the data from the ECU.
I will again use an ATMega328P to hack the signals in the ECU, especially since my ECU deals with 5V TTL signals.
Ultibo will send presets to the ATMega.

Gavinmc42 wrote:Because Ultibo does not take much ram I usually make a big ram drive and log to that.
Once the sample time is over then I save to flash/uSD or USBstick.
A few years back they made USB dram drives.


When it comes to logging, it's all about balancing the load between the data insertion routine (running every X µs) and the file write routine (running every X seconds).

If your data insertion routine does too many things, you obviously cannot log data at a quick rate.
If your file write routine (data formatting and USB drive write) isn't fast enough, you will run out of RAM between file writes.

Gavinmc42 wrote:Not sure if my only SSD will write faster.
The GPIO does have SMI mode which is basically IDE.
What else is around?
https://www.transcend-info.com/Embedded/Products/No-823


I use a cheap chinese USB2.0 stick and it works. :)

Regards,
Henri
Gavinmc42
Posts: 1656
Joined: Sun Jun 05, 2016 12:38 pm
Location: Brisbane, Australia

Re: Delays and thermal management

Postby Gavinmc42 » Sat Feb 09, 2019 7:47 am

My new Honda has HDMI and USB on the media unit.
Will the USB power the Zero W with BT connection to ODB BT dongle?


Yes, my car console's USB port will power a normal Zero running my LCARS OpenVG demo.
What can I use a Zero in the car for? The console already plays music and videos when stationary.
Get a GPS module and roll my own nav system?
Attachments
car_lcars.jpg
car_lcars.jpg (339.01 KiB) Viewed 664 times
Brutus
Posts: 32
Joined: Sun Jan 20, 2019 1:24 pm

Re: Delays and thermal management

Postby Brutus » Sat Feb 09, 2019 8:29 am

Gavinmc42 wrote:What can I use a Zero in the car for?


Usually, you do not want to modify the wiring loom of a new car you paid big money for, so you will not do much.

On a cheap older car, you can play a lot:
-Auto wakeup engine start in the winter.
-Remote control engine start.
-Fuel consumption datalogging (with flowmeter on injection).
-Overtemp/oil pressure warning.
-Bumper radars display.
-Full speedometer update to TFT (below for my Lexus LS400).
Image
-Automatic Go Pro switching in case of spirited driving (using accelerometer).
-OpenCV cops detection. ;)

And if you start using arduino slaves, the possibilities are virtually endless...
Brutus
Posts: 32
Joined: Sun Jan 20, 2019 1:24 pm

Re: Delays and thermal management

Postby Brutus » Sun May 05, 2019 4:23 am

Hi, I finally found time to give a go to the timers on other cores than core 0, but I couldn't go far because I got a link error (see end of this post).

For ease, I post here Garry's suggestion I followed:
Ultibo wrote:Here's some simple modifications to the DedicatedCPU example to setup a generic timer interrupt on CPU3.

This is based on the example as published which is done for a Pi2 (works also on Pi3 etc) but you can easily modify it to be Pi3 specific by changing BCM2836 to BCM2837 and ARMv7 to ARMv8.

The following changes are applied to the ThreadUnit

Add the PlatformARMv7 unit to the uses clause

Code: Select all

uses
 ...
 PlatformARMv7;


Add a variable to count the number of times the interrupt is triggered (so we can check if it is working).

Code: Select all

var
 Interrupts:LongWord;


Add an interrupt handler for the generic timer interrupt, this sets up the next timer interrupt and then simply increments a counter to prove it is working. You can add whatever extra work you need to the interrupt handler.

Code: Select all

procedure GenericTimerInterrupt(Parameter:Pointer);
var
 Next:LongWord;
 Current:LongInt;
begin
 //Get Timer Value
 Current:=ARMv7GetTimerValue(ARMV7_CP15_C14_CNTV);
 
 //Setup Next
 if Current < 0 then
  begin
   Next:=Current + 1000;
   if LongInt(Next) < 0 then Next:=1000;
  end
 else
  begin
   Next:=1000;
  end; 
 
 //Set Timer Value
 ARMv7SetTimerValue(ARMV7_CP15_C14_CNTV,Next);
 
 //Update Counter
 Inc(Interrupts);
end;


Initialize the generic timer and register the interrupt, this is done at the start of the DedicatedThreadExecute function but it must happen AFTER the thread has migrated to CPU3. Generic timers are only accessible from a thread running directly on the CPU, so a thread on CPU0 cannot configure a generic timer on CPU3.

The generic timers run at 1MHz on the Pi (based on the local peripherals clock) so if we set an interval of 1000 that will be a 1ms interrupt, I also tried an interval of 100 (a 100us interrupt) and that worked as well.

Code: Select all

function DedicatedThreadExecute(Parameter:Pointer):PtrInt;
var
 State:LongWord;
 ...
begin
 Result:=0;
 
 {Do a loop while we are not on our dedicated CPU}
 ...

 //Create a Generic Timer Interrupt, this must be AFTER switching to CPU3
 //Request the Timer IRQ
 RequestIRQ(CPUGetcurrent,BCM2836_IRQ_LOCAL_ARM_CNTVIRQ,@GenericTimerInterrupt,nil);
 
 //Setup the Generic Timer
 State:=ARMv7GetTimerState(ARMV7_CP15_C14_CNTV);
 State:=State and not(ARMV7_CP15_C14_CNT_CTL_IMASK); {Clear the mask bit}
 State:=State or ARMV7_CP15_C14_CNT_CTL_ENABLE;      {Set the enable bit}
 ARMv7SetTimerState(ARMV7_CP15_C14_CNTV,State);

 //Set Timer Value
 ARMv7SetTimerValue(ARMV7_CP15_C14_CNTV,1000);
 
 ...
 {Continue with the rest of the example}
 

That should provide a useful starting point for experimentation, let us know how you go.


Below is a capture of the error:

Code: Select all

C:\Ultibo\Core\fpc\3.1.1\units\armv7-ultibo\rtl\platformarmv7.o: In function `_haltproc':
platformarmv7.pas:(.text.n_platformarmv7_$$_armv7halt+0x0): [b]multiple definition of `_haltproc[/b]'
C:\Ultibo\Core\fpc\3.1.1\units\armv7-ultibo\rtl\platformarmv8.o:platformarmv8.pas:(.text.n_platformarmv8_$$_armv8halt+0x0): [b]first defined here[/b]
EGTWBO2BoostController.lpr(372,0) Error: Error while linking


I don't use the PlatformARMv7 anywhere else, and PlatformARMv8 neither.

My uses in this module:

Code: Select all

uses
  Dbg,
  Platform,
  SysUtils,
  GlobalTypes,
  PlatformARMv7,
  BCM2837,
  threads;


My ultibo RTL version is 2.0.569
I tried to update to the newest RTL, but I'm having trouble downloading it (I'm in China at the moment and the internet is a bit dodgy)
User avatar
Ultibo
Site Admin
Posts: 2280
Joined: Sat Dec 19, 2015 3:49 am
Location: Australia

Re: Delays and thermal management

Postby Ultibo » Sun May 05, 2019 10:16 am

Brutus wrote:I don't use the PlatformARMv7 anywhere else, and PlatformARMv8 neither.

My uses in this module:

Code: Select all

uses
  Dbg,
  Platform,
  SysUtils,
  GlobalTypes,
  PlatformARMv7,
  BCM2837,
  threads;

As per our earlier post:

Utibo wrote:This is based on the example as published which is done for a Pi2 (works also on Pi3 etc) but you can easily modify it to be Pi3 specific by changing BCM2836 to BCM2837 and ARMv7 to ARMv8.

which essentially means that you cannot have both PlatformARMv7 and PlatformARMv8 anywhere in the same project.

The BCM2709 unit includes PlatformARMv7 , the BCM2710 unit includes PlatformARMv8 and the RaspberryPi2 and RaspberryPi3 units include BCM2709 and BCM2710 respectively.

So if the rest of your project is specific for Pi3 then make sure the new additions don't include BCM2836, BCM2709, PlatformRPi2 or PlatformARMv7 or anything that includes any of those.

Hope that makes sense.
Ultibo.org | Make something amazing
https://ultibo.org
Brutus
Posts: 32
Joined: Sun Jan 20, 2019 1:24 pm

Re: Delays and thermal management

Postby Brutus » Sun May 05, 2019 11:57 am

Ultibo wrote:which essentially means that you cannot have both PlatformARMv7 and PlatformARMv8 anywhere in the same project.


That was the issue, another housekeeping session was required...

Thanks for putting me on the right track! :)

Return to “General”

Who is online

Users browsing this forum: No registered users and 55 guests