Linux Port :)

You have successfully tested a non-tested PIC model, programmer interface, created a new devices.ini paragraph, performed a new translation, don't hesitate to publish that information here.

Re: Good project :)

Postby Death Knight » 05, 2010 Jun Sat 11:19 pm

Hi again,
The problem with ASCII chars are that, they coded with TCHAR's which windows depended, cannot use those in linux, mac, etc... Needed to remove them all, also all tchar.h files too.

If we choose port 1:1 than we needed to use old standard sprintf functions instead of _stprintf functions that depended to windows.

So we don't have problem ASCII char strings, but TCHAR strings... We needed to change all string compare / string copy functions with standard C strings to make this program running in linux natively..
When we make something like that, It's better to make it via wxStrings because it's easy to code a == b, instead of strncmp(a,b). Also its more readable and reduces the complexity, shortens code. So If we have to change them to compile wxPIC with gnu gcc or we cannot do anything.

I also noticed uint8_t like definitions. Thanks. I wish you changed the PDWORD with "uint32_t *", it's pointer, I learned recently and confused little :)
I am fixed lots of file path problems and filenames.. It's looks ok. Since I removed <tchar.h>, program shows lots of errors at compile time. Needed to silence those errors one by one :)

Today I programmed my PIC with RCD Programmer with wxPIC, using thru wine, a compatibility layer for windows executables, and everything is fine. But prefer native program instead of it. ;)

Now look at rev 11. When you saw the removed functions, it's easy to understand and more easier than changing with std c strings.
I also changed _T() with wxWidgets compatible wxT().

Erdem
Death Knight
 
Posts: 53
Joined: 30, 2010 May Sun 10:18 pm

Re: Good project :)

Postby admin » 06, 2010 Jun Sun 8:42 am

Hi Erdem,

I understand now your problem with _stprintf. I did not realized that Linux had no unicode macro. This means that most of the static wxChar arrays have to be replaced by dynamic wxStrings. The good thing is that the resulting code will be simpler for a performance impact that will not be significant as the text processing is limited.

I have verified that there is no PDWORD except in files where it is legal to keep it (the portability zone of PIC_HW and in WinRing0)

I have compiled your second diff. I have a problem with:
Line 59 of PIC18F_PRG.cpp: no sys/times.h (I have only sys/time.h and sys/timeb.h)
Lot of wxString passed to printf without the .c_str()
The DWORD_PTR in WinRing0 that have been replaced by uint32_t_PTR
Lot of unicode Strings passed to 8bit char method of PIC_HW such as the sz40DeviceName field of T_PicDeviceInfo in device.h that should have stay char*.
The wxChar PIC_error_string that has been converted to char causes a lot incompatibilities (wxString would have been the right move for this one but it would have caused the same errors until all the _stprintf are fixed)

I have stopped there, there are probably others of the same kind in the following files.

Philippe
admin
Site Admin
 
Posts: 153
Joined: 12, 2009 Jul Sun 7:20 pm

Re: Good project :)

Postby Death Knight » 06, 2010 Jun Sun 11:28 am

sys/times.h required for linux because no clocktick like function as in windows. So that could be removed via #ifdef macro, so no problem :)

I am continuing porting at Branches/posix-porting branch, trying to port strings carefully this time. Keep eye on it for errors. And commit changes as much as possible :)
Death Knight
 
Posts: 53
Joined: 30, 2010 May Sun 10:18 pm

Re: Good project :)

Postby Death Knight » 06, 2010 Jun Sun 1:46 pm

I am looking deeply and see that you are also using chars instead of strings.
Also you needed to use wxcommandlineparser.
That make porting job harder. I think you needed to move that CLI interface to wxCommandLineParser... Also you cannot use '/' in linux/posix systems as an argument.
Code: Select all
user@linux> wxPic /overwrite

means wxPic trying to load file overwrite at root.. :roll:

Edit:
Also find that your are using chars on new code. :(
_vstprintf functions to be moved also. I think you could convert all of this to wxString.
In 2010, there is no any performance gain with this approach. Even a cell phone processor is speedy enough to work with Strings...
I am stopped at your code try to fix those too but you already know the code follow, It's easy to port for you.
Uploaded the svn revision 13 & waiting your commit to solve that _vstprintf problems.
Death Knight
 
Posts: 53
Joined: 30, 2010 May Sun 10:18 pm

Re: Good project :)

Postby admin » 06, 2010 Jun Sun 2:23 pm

Death Knight wrote:I am looking deeply and see that you are also using chars instead of strings.

Yes. My job is to work on software performance. So I like to use the most efficient code (even at place where the performance impact is minor). And static strings are much more efficient than allocating dynamic strings. So each time the resulting code complexity is reasonable, I avoid using wxString. But I just understood that Linux does not allow that.

Death Knight wrote:Also you needed to use wxcommandlineparser.
That make porting job harder. I think you needed to move that CLI interface to wxCommandLineParser... Also you cannot use '/' in linux/posix systems as an argument.

You are right. I did not think at that Linux issue either!
Porting lets you discover a lot of problems that you had not seen initially. That's interesting.
admin
Site Admin
 
Posts: 153
Joined: 12, 2009 Jul Sun 7:20 pm

Re: Good project :)

Postby Death Knight » 06, 2010 Jun Sun 3:13 pm

I also move my DivFix++ to Linux and MacOSX from Windows before, walked this roads before.
I also like performance optimizations, specially with Assembly optimizations like using SSE codes and OpenMP like multiprocessing code.
But I don't think that GUI part is optimize-able specially for character string :)
Optimization also makes code dirty. That hardens maintaining/supporting for multi-developer environment. Personally it's better to keep optimized code under core only.

I don't know if there is much line waiting for port since Code::Blocks stops 6 error lines. Will try to find other error via altering codeblocks settings :)
Cheers
Death Knight
 
Posts: 53
Joined: 30, 2010 May Sun 10:18 pm

Re: Good project :)

Postby admin » 06, 2010 Jun Sun 7:00 pm

I have removed the _vstprintf by replacing them with wxString::PrintfV. I tried to compile all so I fixed some remaining errors. But at the end there were some link errors. I committed the repository in that state.

Philippe
admin
Site Admin
 
Posts: 153
Joined: 12, 2009 Jul Sun 7:20 pm

Re: Good project :)

Postby Death Knight » 06, 2010 Jun Sun 8:36 pm

Okey, I am found a shotcut. Adding a definition macros to Appl.h that reverts tchar strings to wxChar stringg functions.
It's really efficient to handle that windows depended code.
So we don't have to write your code with wxStrings. But I still prefer wxString because more elegant, safe & readable code.
So I commit to repo. There is no problems about that string problems now...
But will you wanted to convert those to wxString with it? If you overwrite them with wxString, It's better...

New problem is "QueryPerformanceFrequency" function. Does those really required in this program? It's looks like cosmetic thing at mainframe-2 : 309
In linux, cpu ticks set as 1000hz, 300hz, 100hz at kernel file. In-depended from CPU clock rate. We can still have real cpu clock via CPU's timer stamp register. But that is the meaning of it? Since we have multiple CPU's and multiple clock rates depending CPU load. And at new cpu's some cores could close itself and that might lead reading cpu clock low or close to zero :)

I think we are close to working gui in close time... Than look into serial port functions..

Erdem.
Last edited by Death Knight on 06, 2010 Jun Sun 9:56 pm, edited 2 times in total.
Death Knight
 
Posts: 53
Joined: 30, 2010 May Sun 10:18 pm

Re: Good project :)

Postby admin » 06, 2010 Jun Sun 9:53 pm

QueryPerformanceFrequency is not usefull by itself. It is used to be able to interpret QueryPerformanceCounter. A replacement of both in Linux may exist in a single method. The use of these methods is to generate the short delays (few µS). As the OS delays are usually not precise at this level (even if they have a delay parameter expressed in nS) because they are limited by the ticks you indicate. Using this hardware counter, it is possible to perform calibrated short active waits (to activate the clock and the data pins at the right rate). All hardware I know have such a performance counter but of course it is very dependent on this hardware. Is there no standard interface provided by Linux (like in windows) for performing short delay measurements (used typically to measure the software/hardware performances)?

Note that the performance counters are usually 64bits so there is no risk that they loop back in the CPU lifetime.
admin
Site Admin
 
Posts: 153
Joined: 12, 2009 Jul Sun 7:20 pm

Re: Good project :)

Postby Death Knight » 06, 2010 Jun Sun 10:16 pm

Okey I put performancecounters too.
Now looking pic_hw part. Code is really crowded.
Original author doesn't handle LPT and COM parts separately.
Don't know how to handle and/or where to start.
It's better to look the code for some days and make research on how COM port controlled on posix. ;)
Death Knight
 
Posts: 53
Joined: 30, 2010 May Sun 10:18 pm

PreviousNext

Return to WxPic contributions

cron