Monday 8 October 2018

QNX /WinCE Porting Journey

Its been 4 years ... It started with a simple question.



 First target was Raspberry . Initial 3 things are necessary  for porting to any OS , 1- Timer 2-UART(just to see whats happening inside the board ) , 3- Interrupt ,normally, the trouble comes with interrupt, load address has to be mapped with boot address properly. I ran into multiple problems in the process.So with no choices left out, ordered Beaglebone(4000Rs) , which is very well supported by QNX.


BBB QNX bsp had no HDMI graphics support .. It can be wiredup with 24X parallel LCD , that  requires additional module & LCD.. I didn't like to spend another 4000Rs on that ... Initially graphics driver was very challenging, later figured out the way to do it. 


Then I came back to raspberry to fix the graphics, In this process ,I found that Photon ,’ the famous QNX UI’ is not supported on ARM version. really I did not expected this .. Instead they were promoting QT. dont know the logic behind this decision .. Technically if photon can run on x86 , it should be possible to make it run on ARM .  Ideally what I wanted was, to move X86 Application code to ARM , which would save probably 400$ to 600$  hardware cost. porting an app from Photon to QT , is something a hell of job .. instead you could rewrite it from scratch ... yes ..First door closed..  I lost my interest on continuing further on this direction..   If Photon was open source, It could have been easily ported to ARM.( QNX guys still keep the ARM version of Photon library , but it crashes immediately )

 Second Raspberry’s Network chip on USB, is something ,as a person from hardware & software background  , I couldn’t digest it .  One could make an Ethernet IP core out of 20K LUT  which probably cost them additional 20cents… Seriously I cant still believe that how they carried away with their decision. Linux driver development is different, you have an army of developers who are ready to spend their day & night for a little pride. That’s not the case for other OS. 

I still have a mouse/keypad/Ethernet baremetal code (well someone did a nice job), which is in C++ .  most divers don’t support C++ .. Someone has to spend another 15 days to make it pure C code . which is another hell of work.. again the success rate is 50 :50 .. No time/ patience to do that. 

QNX graphics is consuming a huge CPU cycle.  Well I wanted to add GPU support , even spent some time on “Lima”  library .. I even  thought of tweaking it .. well ,mali GPU is a closed source library  ,’ Lima ‘guys were trying to reverse engineer it..    Another best method  is making a  wrapper around Linux Mali library  .. I know the complexities.. Linux /QNX  library loading mechanism /file format / function loading/ kernel support  everything is different . but since linux is open source , it should be possible to make it …  one can’t take these kind of work without QNX team support.   Another Door is closed. 


Some one did a nice job on raspberry  porting to WinCE(very basic)..  I wanted to add USB mouse & Keyboard support .. I had a baremetel code for that , but WinCE compiler was very older than the one my code was targeted for…  spend some days on that , don’t want to procced further on that.

 Next I was searching for something cheaper than raspberry, but with proper Network & USB hardware support … there Orange Pi came. I have QNX 6.5 & WinCE 7   , at the time these software were released ,no quad Core ARM Cortex was born.. The compiler is very old , not all the multi core instructions are supported.  

Lessons
1.   Always strict to open source (especially for something you do it as a hobby)
2.   Choose the best hardware or stay close to the well supported OS
 

will continue to do FreeRTOS porting .  Well  I am cleaning the Orange Pi code..  will release the basic code in a week .

Sunday 6 May 2018

Raspberry Pi3 FreeRTOS

Raspberry Pi3 FreeRTOS  is out ... 

https://github.com/varghes/Raspberry_Pi3_FreeRTOS

Single core is running ..    

All set to add QNX & WinCE Support ..

Sunday 11 February 2018

UART 2M Baud rate experience

UART is a terrible protocol , be carefull while considering it for higher data transfer . There are bottlenecks everywhere hardware /software /driver /buffer .. which includes even if you have a flow control in place . .. I had earlier serious data loss, attempted everything to stop it . changed timeout / added flow control .. overlapped read write to normal ...   now no loss


tested using CH340G    (timeout can be adjusted to get 1000polls/sec) , loop back method (tx/rx  connected)  64byte per transfer   (CTS/RTS connected)

Experiment 1:

9600 - 15 polls /sec - no loss
14400-  23 polls /sec - no loss
19200-  30 polls /sec - no loss
38400-  56 polls /sec - no loss
57600-  88 polls /sec - no loss
115200-  174 polls /sec - no loss
128000-  190 polls /sec - no loss
230400-  334 polls /sec - no loss
460800-  650 polls /sec - no loss
921600-  1120 polls /sec - no loss
1500000-  1593 polls /sec - no loss  (removed CTS/RTS(both software & hardware) & checked ,no effect )
2000000-  30 polls /sec - loss started  ...  it looks like loss is because of TX completion , afterwards RX starts ,since single device used . otherwise if I use 2 devices , I guess it should be fine.

Experiment 2:  2 USB-UART devices 

1500000-  666 polls /sec 
2000000-  loss

64*666x 8bits= 340.992Kbps ( both directions )

Experiment 3:

Added 2 threads , one for reception & other for Transmission .. Reception hanged , may be it requires some sort of synchronous .  even if I add 1ms delay , it looks like I cant achieve more than 660 polls 


Experiment 4: 128 bytes per cycle 

1500000-  804 polls /sec - no loss  - reduced to half

Experiment 5: 512 bytes per cycle 

1500000-  230 polls /sec - no loss  - reduced to half 
8x230=>1840 
1840x64x8=942,080  => comes close to 1Mbps
(provided data readily available from controller, otherwise it would cause further delays )

Experiment 6: 1024 bytes per cycle 

1500000-  117polls /sec - no loss  - reduced to half 
16x117=>1872
1872x64x8=958464  => comes close to 1Mbps





Experiment 7:  cp2012 :1024 byte

1500000-  130polls /sec - actually this buad rate is not suppose to work as per their spec
2000000-  130polls /sec
3000000-  130polls /sec
4000000-  130polls /sec (dont know what the fuck is happening with this chip)
6000000-  130polls /sec (no CRO here)
12000000-  130polls /sec (haa haa thats almost protocol speed)
921600 - 83 polls/sec ( back to normal)


Experiment 8:  cp2012 :512 byte

1500000-  250polls /sec - 
921600 - 156polls/sec


Experiment 9:  cp2012 :64byte

1500000-  990polls /sec -  wow matches to 1ms 

921600 - 565polls/sec
460800-  500polls /sec

990x64x8=506.880kbps





Experiment 10:  FT2232D :64byte 

460800-  104polls /sec , mummy ...I am pretty sure this is something related to FTDI timeout. Stoping this experiment here , because its simply waste .

ft2xx command mode 
3000000- 3615polls/sec  -  FTDI is always the master , you could tweak anything & make  it work 
for your application.   poll is beyond the limit , let me connect it to other port 

now reduced to 2200 

2200x64x8= 1.12Mbps


Experiment 11:  FT2232H :64byte High Speed

command mode 
3000000-4770 polls 
12Mbaud-17,000 polls/sec another port it is 7899 polls /sec , close to theoritical calculation 8000


here too , in Serial mode , still has some timeout issue ..


end of research