NEW RTOS for PIC and AVR- JACOS with features of SALVO

[luben111]

jacos rtos

Hello,

I got that new RTOS for PIC and AVR appeared - JACOS -
https://jacos.narod.ru/
They have almost all services like SA*LVO - delays, timeouts, but without using the complicated system of predefined labels.
For all who is working with RTOS this link will bring new view to the RTOS.

Regards
Luben

 

[mikasi]

salvo avr

It looks realy interesting ...

Everything is in Russian language !!!

That just might be a big problem for me ... :?

 

[Birth_day]

avr rtos russia

Now supports and MSP430 too.

 

[002]

pic rtos c

I work for a long time without OS with the AVRs.
I don't understand to thing they serve.
As it could improve my job.
I get some times of pS and I perform hundreds of simultaneous controls.

 

[trace_ru]

www.pragmatec.net

This so-called "jacOs" is more more nor less but Salvo RTOS produced by Pumpkin Inc.
I am not sure why those guys needed to change some functions' names and to pretend that it's their product.
If you need more info - just check the original WEB site:
w**.pumpkininc.com

By the way: any one out there uses Salvo v3?

trace

 

[Birth_day]

salvo 2.2.0

This so-called "jacOs" is more more nor less but Salvo RTOS produced by Pumpkin Inc.
I am not sure why those guys needed to change some functions' names and to pretend that it's their product.

Wow! Really? Have you any arguments?

 

[trace_ru]

pic rtos

How can I prove it?
I can't. I just looked into the structure of "jacOS" and immediately remembered Salvo. Everything is the same. Functions, parameters, notation etc.etc.etc.
There are some changes, thought. But all of them could be just minor cosmetic changes designed to hide the original product.
The last argument could be the library list for different types of MCUs.
It is identical to the Salvo's!
Can anyone design a RTOS and produce a library with the same file names for about 30 MCUs? I don't think so.
But if (though I doubt it) "jacOS" is a truly original product I apologise profusely for my mistake .
trace

 

[Birth_day]

salvo rtos avr source

>How can I prove it?
It's simply. Disassemble both , and fined same functions.

>I can't. I just looked into the structure of "jacOS" and immediately remembered Salvo. Everything is the
>same. Functions, parameters, notation etc.etc.etc.
And in uC/OS-II the same. It's not an argument.

>There are some changes, thought. But all of them could be just minor cosmetic changes designed to
>hide the original product.
jacOS gives about 40-50% more compact kernel code. Also it works in average 50% faster (sometimes 5-6 times faster).

>The last argument could be the library list for different types of MCUs. It is identical to the Salvo's!
>Can anyone design a RTOS and produce a library with the same file names for about 30 MCUs?
> I don't think so.
It's not an argument too. Compare librarys for PIC16F873:
pic412dc.lib - HT PICC
412dtu.lib - jacOS
sfp412ab.lib - Salvo

>But if (though I doubt it) "jacOS" is a truly original product I apologise profusely for my mistake .

 

[neuralc]

salvo+avr

Birth_day,

You have already worked with it? With PIC?

NeuralC

 

[wzdreamer]

free pic rtos

trace_ru,
maybe jacOS is pirate edition of Salvo? ;PPPppp
who knows?

 

[Birth_day]

the calvin c rtos

NeuralC,

I used both systems for PIC16F73 and PIC18F252. Now only jacOS.

 

[trace_ru]

salvo pro avr

to Birth_day:
Well, although initially I did not want to (or should I say di not want to loose a day of work), I had a proper look at jacOs.
It is a pirated Salvo based on rev 2.1. No doubt about it.
The guys (whoever they are) simply re-compile the source files after some "original" changes. But this is not surprising. What is surprising is your claim that "jacOS" is 5-6 times (!) faster than Salvo. I found this difficult to beleive since the code of the latest "jacOS" is the same is the code of Salvo.
One more thing: I have worked with uC/OS-II as well. It's simulare to Salvo as much as a road accident is simular to a sexy scene from your favourite movie. Any RTOS in general has roughly the same structure. The difference is in the implementation. In the case of "jacOS" there's no difference.
I am going to make a little experement and to compile a test project using Salvo and jacOS, in order to check the performance. I'll keep you posted.
trace

 

[Birth_day]

jacos+avr

I have prepared one test, where Salvo works almost 10 times slower than jacOS. It is the simple test for 16 tasks. The most of them simply increase the counter.

The sizes of the programs for PIC18F252 :
Salvo - 5094 bytes
JacOS - 2558 bytes

The counter after approximately one million cycles (4MHz) :
Salvo - 2180
JacOS - 21300

 

[neuralc]

pic con picos18

Hi,

Some one have documentation in English?

ThX

NeuralC

 

[trace_ru]

top ten rtos for pic

to birth_day:
Well, I'd say it's a classical mistake.
Your problem is simple: you are trying to re-compile the Salvo project using the source code and the "jacOs" project by including the object library.
Salvo (and "jacOS" for that matter) is highly configurable RTOS and includes lots and lots of functions, calls and services. By using the source code you are able to re-configure (and possible change) internul services. bit the payment for this is size.
The compiler simply includes ALL routines found in the source code regardless if they are used or not. The object library option gives you much tighter code since the linker only extracts the routines called from the main code.
I have re-compiled your code with Salvo's object libraries and the final code size was 2512 byte. The result is roughly the same code as in the case of "jacOS". Furthermore, you can increase the speed and reduce the stack call depth by configuring Salvo's OS_Timer() and OSSched() routine as inline (don't forget to change you salvocfg.h if you are to try this).
All of this you can find in the Salvo's User's Manual. Happy reading.

http://www.pumpkininc.com/content/doc/manual/SalvoUserManual.pdf

 

[neuralc]

salvocfg.h

I'm using Salvo 2.2.0, and I'm unable to compile it using HTC_PICC 8.01

In the manual of jacOS, I saw HTC_PIC 8.01

I'm trying to use 8.01 with jacOS and I get the following error on the OS_Delay line:
Error[000] swimctl.c 261 : undefined identifier: os_timer_delay

What append?

ThX

NeuralC

 

[hwswboy]

picos18 for pic24

Problem with S*lv* 2.2.0 and PI*c 8.x :symbol FOSC0:

code:
--------------------------------------------------------------------------------

Compiling main.c:
Command line: "C:\HT-PIC\BIN\PICC.EXE -FAKELOCAL -G -O -Zg9 -DMAKE_WITH_FREE_LIB -E -16F877 -C -I\SALVO\DEMO\D4\SYSH -I\salvo\inc -DSYSH \salvo\demo\d4\main.c"
Error[000] C:\WINDOWS\TEMP\_3VVIED7.AAA 63 : undefined symbol FOSC0
Enter PICC -HELP for help

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

This is because v8.00 and later use a different argument scheme for the __CONFIG() macro than did v7.87PL2 and earlier. The solution is to either comment out the __CONFIG() line(s) in the project's header file for now, e.g.:


code:
--------------------------------------------------------------------------------

#elif defined(SYSH)
#include <pic.h>
/* __CONFIG(FOSC0 | UNPROTECT); temporary fix for PICC v8.00 */
#define LED_PORT PORTC
#define LED_TRIS TRISC
#define ADGO_BIT ADGO
#define ADREG ADRESH
#define ADCON0_INIT 0b01000101
#define ADCON1_INIT 0b00001110
#define PORTBIT(adr, bit) ((unsigned)(&adr)*8+(bit)) static bit keySW @ PORTBIT(PORTB, 0);
#endif

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

(and set the configuration options manually in MPLAB), or to change the __CONFIG() arguments to the appropriate ones for v8.00.

 

[neuralc]

salvo pic

No,

I have the problem to, with the __config macro, but resolved with: __CONFIG(UNPROTECT|HS|WDTDIS|PWRTEN|BOREN|LVPDIS|DEBUGDIS|WRTDIS);

Problem is use the libraries, allways give link errors...


NeuralC

 

[Birth_day]

undefined identifier adgo

trace,

>: you are trying to re-compile the Salvo project using the source code
>and the " jacOs" project by including the object library.

Is it my mistake? My Salvo 2.2.1 has no library that works with timeouts. Maybe you have linked the test with less complex library, and your Salvo test is not correct. Or... Have you made your own library? Then, please, describe the makefile for that library. I'll make and test it.

>Furthermore, you can increase the speed and reduce the stack call depth
>by configuring Salvo's OS_Timer() and OSSched() routine as inline
>(don't forget to change you salvocfg.h if you are to try this).

Hmm... OSSched() as inline saves only 6-10 cycles (from 400-600 in the Salvo test) per context switch , and it is not possible with libraries. OS_Timer() has no influence at all. You have told about inline like it can radically change the situation - it cann't.

NeuralC ,

I have prepared jacOS test for 16F873. Size - 1447w. Speed - 19200 contexts switches for 1 mill. cycles.

 

[Birth_day]

avr salvo rtos

NeuralC,

I apologize, has made a mistake in prim_tmr.c. I have set tick time equal 1ms, but it must be 4ms. Then jacOS test for PIC16F873 gives 21800 context switches.

The corrected version.