Need to implement multithreadding for serial port read and write about cdmaworkshoptool HOT 12 CLOSED

the reason standard .net library was abandoned was due to it not supporting a 
blackberry serial port properly (although it would enumerate it, when a 
connection was attempted it would report a type of handle which .net did not 
believe was a port and refuse connection)

are you a developer? it would be brilliant if you have the know-how and would 
like the contribute any of these things :) 

perhaps a backgroundworker could be used in CommandQueue.Run() or something

I see, I must say I am very impressed with your work, and have been trying to 
chop a few bits to implement into a project I have been working on.

I am no expert and my skills only stretch as far as vb.net but I hope we could 
try and help each other out.

I can send you the solution I created for my project if you would like to take 
a look.

I would like to implement the original .NET SerialPort class as I only need to 
communicate with a Qualcomm device (Samsung Galaxy S III LTE GT-I9305).

I am trying to backup and restore NV Items in a separate thread so the UI 
doesnt lock up but when I tried implementing the background worker it always 
returned an error that there was no device connected.

There are also a few cool functions I added which you could add to your library 
regarding IMEI repair.

Ive attached the Solution for your reference. :)

hmm.. that is a very interesting project indeed. I am located within US and am 
cagey about including IMEI/esn/meid repair support in cdmaDevTerm, but quite an 
interesting project nonetheless(I hope it is GPL ;)). 

So// the issue is/was still present in .2.8(the latest as of writing) but it 
seems it can be(at least under this code base version) prevented by using a bgw 
as demonstrated below

            private void DoNVRead(string fileName,string nvList)
            {
                BackgroundWorker bw = new BackgroundWorker();

                bw.DoWork += (sender, args) => {
                    // do your lengthy stuff here -- this will happen in a separate thread
                    cdmaTerm.ReadNvList(nvList, fileName);
                };

                bw.RunWorkerCompleted += (sender, args) => {
                if (args.Error != null)  // if an exception occurred during DoWork,
                    MessageBox.Show(args.Error.ToString());  // do your error handling here

                // do any UI stuff after the long operation here
                Logger.Add("NV Read - long operation done");
                };

                bw.RunWorkerAsync(); // start the background worker

            }


(granted this is c# as the new cdmaDevTerm GUI is WPF/C#, but there are sites 
online that could probably convert it to vb .net for you--or sharpdevelop has 
it built in I think)

Would you mind if I consider merging some of your changes upstream into 
cdmaDevTerm?(mostly a couple of the code organization ideas im thinking about)

I'm changing the status to fixed(although there is still the possibility it 
would make sense to move the bgw closer to the Q.Run call) although this patch 
only fixes the blocking for Nv Read from list at present...

Thanks for that ill give it a try and post my results here.

Take anything you need for cdmaDevTerm, anything to help make an awesome 
project better! :)

Hi I have tried to implement various methods of asynchronous techniques to get 
the necessary functions to run on a separate thread with no success.

The problem lies with the custom SerialCOM class. This also needs to be 
multithreadded.

Can you be so kind to modify the VB Solution I sent you to use the .NET 
implementation of the SerialPort class rather than the custom SerialCOM class 
as the .NET implementation supports events which are multithreadded.

Thank you so much! :) 

"Can you be so kind to modify the VB Solution I sent you to use the .NET 
implementation of the SerialPort class rather than the custom SerialCOM class 
as the .NET implementation supports events which are multithreadded."

This is the type of request that would be better served at 
http://stackoverflow.com/ or http://www.vworker.com/

I appreciate your reporting the issue, but I have incredibly limited free time 
to do anything, let alone code someone elses project(my time is better served 
developing the main branch and trying to learn enough to contribute to projects 
like nmap)...

As demonstrated above: The UI blocking has nothing to do with the custom 
serialPort(don't belive me? check out the latest code from source and 
build--you can watch the nv read happen in the log tab now)

Okay well thanks for your time and if theres anyhing I can help with then ill 
try my best where time permits. :)

well, thank you for the offer. my suggestion for your project would be to maybe 
see if the new cdmaDevLib would fill your needs--as the code you have forked 
from is dated(and some of it a bit buggy)... that way if I do end up moving the 
'threading fix' closer to the Q, then by using the library packaged version you 
will automatically get all the latest fixes when you update(hopefully without 
causing too much to change in your qcn related code)

also re: your project, it seems you may be in violation of the GPL v3 and my 
copyright on some of the code... the gpl allows you to fork the project as you 
have--but original copyright and licensing must remain in place

see: 
http://www.gnu.org/licenses/quick-guide-gplv3.html

http://opensource.org/faq#preserve-copyright-notices
"Can I strip out the copyrights on Open Source code and put in my own?
    Definitely not! This isn't even about Open Source, really: in general, you should not remove a valid copyright notice, no matter what license it specifies. Copyright notices are legal notices; they are also a source of information about the provenance of source code, and if that information is stripped out, recipients of downstream copies have no easy way to rediscover it."

 ... I believe the accepted practice is for you to add your additional copyright after the original, but it might be easier license/copyright wise too if you just link against cdmaDevLib(although I understand this doesn't give you back the standard .net serial port--I've honestly never run into a phone that didn't work with the included winApiCom and I'm much more likely to fix the threading in cdmaDevLib than in any code that's not current) 

Hi thank you for quick reply I will use your library instead as it is more upto 
date and sorry for copyright removal as I'm still novice I wanted to make the 
code as easy a possible to look at to try and understand it better. Didn't mean 
to breach GPL. As said I will just use your library in future and base my code 
on that.

this perhaps is close, but using this cdmaDevLib in the main branch WPF 
interface is still buggy/quirky.... not sure if its ready for the main branch 

Hi your implementation is working great for my needs, I am just having a go at 
tidying up code and making data from sending commands easier to retrieve to 
update to a textbox for example. I noticed too that you have an ADB 
implementation. I have created an excellent ADB communication framework which I 
would be happy to share with you for your project. It can handle temp/perm 
root, issue root and non root commands, it supports asynchronous operations so 
it doesn't lock up the UI and can gather device details and much more. :) I 
will sort out the code and let you take a look.

Since commands are sent by ref now it is possible to do something like

Dim cmd = New Command(Qcdm.Cmd.DIAG_NV_READ_F, i, New Byte() {}, debugString)
cdmaTerm.Q.Add(cmd)
cdmaTerm.Q.Run()

Dim result = cmd.bytesRxd()

.. do somethng with result

However the basic idea with cdmaDevLib is vaguely a MVVM pattern with 
cdmaTerm.thePhone being the view model and cdmaTerm.thePhoneRxd

cdmaTerm.thePhone implements inotifypropertychanged which allows the form 
elements to use binding to the properties to have them getting updated 
automagicly