Real time charting

[taazz]

there are 2 main methods of data exchange between threads.
1) copy data to an address not accessed by the thread and send address to the main thread.
2) use some sort of synchronization mechanism critical section, multi read single write or some other mechanism.

In your case I would go with 1 ee create an array when it fills create a new array to work with and send the old to the application.

I'll attach an application to demonstrate the 1st technique later today or tomorrow don't know for sure yet.

[CaptBill]

Yes, Doing this job with MCUs is 'ULTRA SIMPLE'. But I come from there to use a 1GHz CPU!!!
Recent years, I made many boards with AVR + WIN PC + Wireless dongle (that i made by NRF24L01+). Everything works OK.
I removed AVR, Wirless Link and  connect all ICs directly to GPIO of  Raspberry Pi. This Reduces the board size and eliminate an expensive Windows PC.
I expect the 1GHz CPU works better than a 20MHz AVR!


Linux has many advantages over Windows but I disappointed, If i can't have a simple interrupt (or fixed time thread)

Ah, see? You defined the problem right there. You are disappointed that the Pi is only a little better at doing real-time. Also you are equating available clock cycles with 'good timing skills'. Even a 20mhz clock that runs on time is better than a clock that can't keep time. Hahaha  4ghz or not. Even ARM Linux has this problem. 'PC OS's' have this serious weakness where the cannot maintain a steady beat. How could they be expected too in a shared multi-tasking environment?

You got the solution too. You need a buffer so you can pile your array data into to be processed and fed out perfectly timed. This is what the AVR is good at. Very good at. It 'single tasks' well. Just program it as your buffer and process the data, within this more suitable real-time platform. Then you only have one last concern: latency. Perhaps you need a speedier AVR to match the latency requirements you have.

"Great man of Tinycore"? Hahaha .Maybe "Tenacious man of Tinycore". Have you attempted an install on the Pi? You know there is a Tinycore ARM port for the Pi, right?

[ahmadian]

there are 2 main methods of data exchange between threads.
1) copy data to an address not accessed by the thread and send address to the main thread.
2) use some sort of synchronization mechanism critical section, multi read single write or some other mechanism.
In your case I would go with 1 ee create an array when it fills create a new array to work with and send the old to the application.
I'll attach an application to demonstrate the 1st technique later today or tomorrow don't know for sure yet.

Thanks a lot taaz.
Your guide works OK. I made a global array and fill it every 1 sec.
I attached result. It work same as buffered Oscilloscope that show thread timing detail.
I will mix this code with SPI reading on Raspberry Pi and replay you soon.

[ahmadian]

Ah, see? You defined the problem right there. You are disappointed that the Pi is only a little better at doing real-time. Also you are equating available clock cycles with 'good timing skills'. Even a 20mhz clock that runs on time is better than a clock that can't keep time. Hahaha  4ghz or not. Even ARM Linux has this problem. 'PC OS's' have this serious weakness where they cannot maintain a steady beat. How could they be expected too in a shared multi-tasking environment?
You got the solution too. You need a buffer so you can pile your array data into to be processed and fed out perfectly timed. This is what the AVR is good at. Very good at. It 'single tasks' well. Just program it as your buffer and process the data, within this more suitable real-time platform. Then you only have one last concern: latency. Perhaps you need a speedier AVR to match the latency requirements you have.

Even a 12MHz AVR is fast enough for my purpose, when using Interrupt of SPI in Slave mode.
But when I send a package for a costumer I want to support one software, not 2s. I can change one software to newer version and email it to the costumer.
Thanks to "taazz" that he solved my problem of threading and i will test it on the Raspberry-Pi.

Have you attempted an install on the Pi? You know there is a Tinycore ARM port for the Pi, right?

yes, but Results was not different from Whezzy. You may see below that "bmarkus" disappointed me in PiCore.
http://forum.tinycorelinux.net/index.php/topic,16727

I have a dream to have real time Linux on Raspberry Pi 

[CaptBill]

Have you attempted an install on the Pi? You know there is a Tinycore ARM port for the Pi, right?
yes, but Results was not different from Whezzy. You may see below that "bmarkus" disappointed me in PiCore.
http://forum.tinycorelinux.net/index.php/topic,16727

I have a deam to have real time Linux on Raspberry Pi 

Hey, I missed your post. Very interesting. BMarkus is correct. Just because it's small doesn't mean it's real-time. As a matter of fact, there is no 'ARM Rt-kernel build' at all, that I am aware of yet. 

The real problem you have deployment wise is that you must have complete control of the complete system, if you are attempting real-time. So to prevent a deployment nightmare, you have to provide a custom OS pre-configured for RT. You can't just write an app that is 'Rt-ready', unfortunately. You can't even allow your customer to install any more apps, hahaha. You have to configure the kernel itself to do bona-fide Rt. That's the sad reality.

The good news is there seems to be a very nice, elegant solution with the AVR route. Seen it with my own eyes. Total game changer for CNC, which is heavily reliant on Rt. With AVR controlling the actual pulsing previously done with a Linux RT-kernel, Linux is free to just be a front end while the AVR is running circles around the Rt-kernel's performance. Even running 5 axis simultaneously. No need for Rt-kernels anymore. Whoo hoo.

[ahmadian]

Hi taazz
You are great. It works like a  Jet on Raspberry Pi. 
I'm writing this post on Raspberry Pi too. I attached source but you must have Rpi and my hardware for testing.
The code have a data logger thread that reads a Loadcell and ShaftEncoder every 10ms from SPI port and copy it to an array[0..99]. When the array was full, It copied to another array and this new array is plotted on the chart. Simultaneous plotting of TAchart component is very fast and 1sec time is so enough for 100 points. The data logger thread works in background even when plotting is done.
I use Szollosi's Pigpio code from http://wiki.lazarus.freepascal.org/Lazarus_on_Raspberry_Pi#5._PiGpio_Low-level_native_pascal_unit_.28GPIO_control_instead_of_wiringPi_c_library.29
But I added low level SPI driver to it. This driver works directly with CPU registers (faster than any other driver of linux).
I can't  donate Lazarus/FreePascal developers (here is IRAN and no VISA card is found  ) but I can share all of my practical codes on this forum (or wiki).
Lazarus/FreePascal is the only RAD available for Raspberry Pi and same boards. It has many potential for consumer/industrial electronics. But without a systematic donate, it propagates slow.

[taazz]

I'm glad you made it work. Let me pock a small hole in your code not big enough to make any difference I guess but it is important for me. you say

When the array was full, It copied to another array and this new array is plotted on the chart.

So let me get this straight for a second, in pseudo code you have something along the lines of

Code: [Select]

    getmemory(MyVar, 100*4{bytes});
    While Not terminated do begin
      FillMem(MyVar,0);//init;
      Cnt := 0; //init
      repeat
        MyVar[Cnt] := readValue;
        Inc(Cnt)
      until Cnt >= 100;
      GetMemory(MyOtherVar,100*4);
      copy(MyVar, MyOtherVar, 100*4);
      SendToChart(MyOtherVar);
    end;
Given the fact that this runs once a second and it only copy 100 values I don't think this would be of any measurable help but it would be faster if you avoided the copy altogether. eg

Code: [Select]

    getmemory(MyVar, 100*4{bytes});
    While Not terminated do begin
      FillMem(MyVar,0);//init;
      Cnt := 0; //init
      repeat
        MyVar[Cnt] := readValue;
        Inc(Cnt)
      until Cnt >= 100;
      SendToChart(MyVar);
      getmemory(MyVar, 100*4);
    end;

Just in case you missed it, no I haven't looked at your code yet, so fill free to ignore me.

[ahmadian]

You are ashamed me taazz 
I can search Google for small problems and refer to you for large problems.
Before using your suggestions (or other improvements), Now I am trying to write a high precision timer to measure small improvements of speed.
I am googling to find equivalent to QueryPerformanceCounter for Linux ARM. This will have me an insight to small speedup of code.

[taazz]

there is a control called epictimer that if I understand correctly it has good precision on both windows and linux. I have never used it although it is in my list to check. Try googling it.

[ahmadian]

Thanks taazz
I used rtl function of Linux and It was precise.
Istalling Lazarus components on Rraspberry is not simple.
But I successfully installed LazReport.
Every thing is OK. But I can't decide on selecting a database that  is suitable for saving Series and link to LazReport.
In Delphi, I used ClientDataset in nested mode.
I don't need query or other advanced options. Only save a LineSerie and its metadata on file. But want to load multiple Series and report those.
Lazarus offer many database that I can't select one for my program.
Regards.

[taazz]

personally I would go with a type file in your case everything is small and self contained as far as I can see, a database no matter how small will add overhead for features that you do not use and all solutions on lazarus I have seen so far are not cached. They load all from file in to memory, nice easy small solutions that do not lend them selfs to big datasets, reporting or anything else of that group of processes. In the case that you do not really care for memory consumption for what ever reason, then I would go with TDBF or TBufDataset as local databases.

[avra]

ahmadian,

you should know that with linux approach you have an error in your tension break force calculation, so you should check if such error is acceptable (different force will be calculated if wire break is caught after dt+9ms then after dt+12ms). When you read a measurement over SPI, you can turn on and off a single GPIO pin, and then monitor timings on oscilloscope. If error is acceptable you are done. If not you examine if you can improve it (like doing nothing except filling an array for a few seconds and update screen after measurement is done, or drawing directly on canvas, or...). If nothing helps, then you are left with two options: to program RPi without any OS and use ARM interrupts directly (this is really not for a newbie, both for bare bones ARM hw access and for visualization part), or to keep AVR and use it's interrupt for precise 10ms measurements which you can send to RPi even via simple serial (even speeds like 115200, 57600 or 38400 bps will be enough since you have 8 bytes * 100 times / per second which is just 800 bytes).

[ahmadian]

Thanks avra
I read many posts from you about RPI (thanks)
I used AD7190 from Analog Device for reading LoadCell. This IC convert voltage to data at a programmable update rate. In my app 100 sample per second. When a data is ready the REY pin goes Low and we have 10ms time to read data. In my tests on RPI, this 10ms is enough. I think refresh time of scheduler of Raspbian is less than 10ms.
Next, in charting of data on Tensile test, we can modify chart ofter break. Tensile testers is used for many materials and 10ms is enough for more of them. I have a Repaint_Chart procedure on my software that filter and modify raw data of initial chart.
I workd many years on bare-metal programming with 8051, AVR and ARM. But Now I want to use OS for faster development and many other benefits. I'm not student. I must make machines for living. But here is Iran and team working is very rare. I must work alone: basic design an ordered machine, draw CAD detail of every parts, send to CNC worker, assemble parts, draw schematic, draw PCB, soldering parts, initial test of circuit, initial test of machine, write software, write helps, send to costumer ...
You can see bare-metal programming is not suitable for me. I attached my code in last post. It works very well by offering AsynCall from taazz (You may use or offer to others my SPI lib that directly command to BCM2835).
I converted my Delphi program of Tensile Testers to Lazarus and it works cool on RPI( overclocked to turbo mode).
My new problem is selecting a method for data storing and manipulation: Database or Record.
Taazz say, Record is faster than Database for small softwares and my test approve it. Now I'm working on LazReport to complete my program and release version 1 to costumer ( get some money to be alive for writing version 2) 
Regards

[Paul Breneman]

This is a very interesting thread!   

I know a fellow who tried very hard to get the Raspberry Pi working with linux-cnc (which is sort of real time) but he couldn't.  Mainly because the 3D graphics part of the CPU came up in control (I don't remember the specifics).  He switched to the Beaglebone Black and that does work.  So if you are interested in real time Linux you might check this blog out more:
http://blog.machinekit.io/

There are similar links on this page: http://www.turbocontrol.com/monitor.htm

[ahmadian]

Thanks Paul
It is very useful Link.