Project In Progress - New Serial Terminal, Taking Suggestions

idbruce

Hello Everyone

For those of you who are anticipating the arrival of PropCom, well I am sorry to say that there is not way that this software will be ready today.

Who was it that mentioned being able to track pin state changes?

Bruce

tdlivings

Bruce
Looks like your rolling right along with good progress.
Is the text in you jpg pictures coming in serially from a propeller board.

Tom

idbruce

Tom

Is the text in you jpg pictures coming in serially from a propeller board.

Nope not yet, it is only about a one minute job to make it happen, but I am just not ready for it. I am still trying to get the GUI finished up, and then I will concentrate on making the serial connection and fixing any problems that I may find.

I will have a new pic to post in a couple minutes, with a very serious change to the GUI.

Bruce

idbruce

Okay so here is some new pics.

One pic shows a docked LED toolbar to indicate pin status, and another pic shows the LED toolbar floating.

I have the programming all in place to control the pin status indicators on the GUI side, but I really don't know how this is going to work serially.

Bruce

jmg

idbruce wrote: »

One pic shows a docked LED toolbar to indicate pin status, and another pic shows the LED toolbar floating.

Those are showing PropPins ? - will you have a similar view for the Serial port handshake lines ?

Someone watching pins, is likely to want to group them (eg P0..P7 as Byte) P8 as WRN, P9 as RDN etc
(and even rename them?)

idbruce

@jmg

Those are showing PropPins

That toolbar is meant to show high/low states of the prop pins. I don't even know it it is feasible.

will you have a similar view for the Serial port handshake lines

I you are refering to tx and rx, then yes, but in the future. If data is being transmitted through the software, a simulated LED for the tx pin will remain lit while data is being transmitted, and likewise, if data is being received through the software, a simulated LED for the rx pin will remain lit while data is being received.

Someone watching pins, is likely to want to group them (eg P0..P7 as Byte) P8 as WRN, P9 as RDN etc
(and even rename them?)

If that is the case, then I apologize, because I don't do miracles.

Bruce

idbruce

I was doing a little research on serial ports when I came across this software:

http://www.aggsoft.com/serial-port-monitor2.htm

I can now understand some of the things that you folks want. PropCom was never intended to be anything like this software. It would take me quite a while to create something like that.

Bruce

jmg

idbruce wrote: »

@jmg
I you are refering to tx and rx, then yes, but in the future.

I was meaning the Pin-States of the control/handshake lines, found on most serial ports.
You can read/write these Pins, easily in software, up to a certain repeat/refresh rate.
On a real serial port, you can read/toggle at some 10's of KHz, whilst on a USB port, something under 1KHz
is supported.
Polling/display a few times a second, should be easy.

1	CD  	«— 	Carrier Detect
2	RXD 	«—	Receive Data
3	TXD 	—» 	Transmit Data
4 	DTR 	—» 	Data Terminal Ready 
5 	GND 		System Ground 
6	DSR 	«—	Data Set Ready
7	RTS 	—»	Request to Send
8	CTS 	«— 	Clear to Send
9 	RI  	«— 	Ring Indicator

idbruce

jmg

I suppose I could create another toolbar for that, but I am not in any rush for that task . Here are some of the functions in the Serial source code for determing their status.

1. Unknown
2. CSerial::Read
3. CSerial::Write
4. Unknown
5. GND
6. CSerial::GetDSR
7. Unknown
8. CSerial::GetCTS
9. CSerial::GetRing

I am sure one of the "Unknown's" could be replaced by the following function:

CSerial::GetRLSD

Bruce

jmg

idbruce wrote: »

1. Unknown
2. CSerial::Read
3. CSerial::Write
4. Unknown
5. GND
6. CSerial::GetDSR
7. Unknown
8. CSerial::GetCTS
9. CSerial::GetRing

I am sure one of the "Unknown's" could be replaced by the following function:

CSerial::GetRLSD

Bruce

Yes, GetRLSD aliases to read the Carrier Detect.
The DTR and RTS output lines, can be cloned to give a variable you can display,

Cluso99

1. is DCD (or RLSD)
4. is DTR
7. is RTS

idbruce

Ray

That is what jmg also said, however I do not have any function available for determining DTR or RTS status.

Bruce

jmg

idbruce wrote: »

however I do not have any function available for determining DTR or RTS status.

Not directly,. but as they are output pins, Open() can be expected to default them, (check by linking to pins you can read) and then you create new calls that SET DTR and also SET DTR_State, and clr etc, and now you have tracking variables you can read/display - users should be able to manually flip these two lines, as connecting one to Input lines, is a common diagnostic tool.

Cluso99

Bruce: You are controlling DTR & RTS and they are outputs from the pc to the prop. Of course, normally we do not usually control the inputs CTS, DCD, DSR or RI from the prop. IIRC the propplug (using the FTDI chip) will default these (CTS, DCD, DSR to active and RI should default to inactive).

idbruce

@Cluso99

Sorry it took so long to respond. After smoking cigarettes for several decades, I finally decided to quit and do it "cold turkey" style. I am on my third day of no smoking and as you can imagine, I am currently going through Nicotine withdrawl. Needless to say, I am frazzled.

Anyhow, pertaining to your last post..... I can really appreciate the information that you provided.

So now I must ask myself, do I want this application to be Propeller chip specific?, Or even though the Propeller chip is my main target, do I still want to make it useful for other types of communication?

Bruce

Cluso99

Bruce: There are a lot of nice and good terminal programs and serial debug programs out there. You would never compete with them. However, none do the Parallax font and none do the download protocol. They mostly fall over (or need options set) to prevent DTR from resetting the prop.

Therefore, IMHO I would concentrate on just the propeller. We do not need all the features of the other terminal programs.

Personally, what I would like the best, was if bst had the extra terminal functions in its serial window to support an equivalent interface to the VGA or TV driver. Then we could just substitute the PC driver on the prop, and the terminal program on the PC to emulate the VGA or TV display. It is pretty close now, but just not there.

prof_braino

idbruce wrote: »

After smoking cigarettes for several decades, I finally decided to quit and do it "cold turkey" style. I am on my third day of no smoking

Hang in there buddy. Its worth the effort. Cold turkey almost 20 years here.

Cluso99

I concurr with prog_braino. My wife gave up when we got engaged. She cold-turkied and we've been married 31 years!

jmg

idbruce wrote: »

So now I must ask myself, do I want this application to be Propeller chip specific?, Or even though the Propeller chip is my main target, do I still want to make it useful for other types of communication?

Fully supporting the handshake lines, is not really moving non-prop specific.

They are there on all USB chips and COM ports, and some high speed comms need handshake lines to pace the link.

Users/students can also use handshake lines, as progess feedback flags

idbruce

Hello Everyone

While I ponder a few other things, I have decided to take Beau's suggestion, and provide multi-file support at the click of a button.

In addition to the normal "SENDFILE" button, there will be an additional (9) buttons for which you can specify filepaths. In theory these buttons will do exactly the same thing as the sendfile button, except these filepaths can be predetermined, and will not change until the program is either shut down or until manually altered, whereas the sendfile button will not maintain state.

Bruce

idbruce

As it pertains to my previous post, the latest addition, per Beau's request, has brought on a new level of complexity. I would try to explain it, but ......

Anyhow, here is a pic of a rough draft with the latest addition. There are still some problems that need to be worked out to make it fully functional and aesthetically pleasing.

Bruce

RS_Jim

Bruce,
Interesting project, keep up the good work.

Sorry it took so long to respond. After smoking cigarettes for several decades, I finally decided to quit and do it "cold turkey" style. I am on my third day of no smoking and as you can imagine, I am currently going through Nicotine withdrawl. Needless to say, I am frazzled.

23 years ago a Dr. said, "you have the onset of emphasema", I quit cold turkey after many years of HEAVY smoking. The frazzeled part goes away after 30 days. When you feel frazzeld, drink a glass of OJ, it helps and is a healthy alternative to Nicotine. Chest X-ray's after six years showed no signs of emphasema, whew no time to tow an O2 bottle. Today I swim, weight lift at the Gym and work 35 to 45 hours a week.
Jim

idbruce

@RS_Jim

I carried that monkey way too long One week and still going strong. NICOTINE FREE!!! YIPPEEE!!!

Yes it is an interesting project, but it is taking a little longer than I expected. There are too many CControlBar derivatives in this project, and now I have two of them fighting for the same window space. I just try to work on it when I have the time and ambition.

Thanks for dropping by.

Bruce

Beau Schwabe

"...As it pertains to my previous post, the latest addition, per Beau's request, has brought on a new level of complexity...." - Hmmm, sorry about that :-)


Keep up the good work on the non-smoking front.... I myself am a former smoker. For 13 years at one point up to 2 and a half packs a day. I too went cold turkey. The hardest part was the first two/three weeks, after that it was much easier to deal with. Now it's been 15 years since a cig, and while I don't mind the smell (I'm odd that way), I haven't had an urge to light-up.

idbruce

@Beau

Hmmm, sorry about that :-)

That's alright Beau, I like a good challenge, and I believe this will be a real challenge to make it work and look the way I want it to.

Thanks for the words of encouragement on breaking the smoking habit. It is also worth mentioning that I gave up another bad habit over a year ago. Two down, one hundred more to go

Bruce

idbruce

Hello Everyone

Here is an update for those of you who have been following this thread and have a general interest. As indicated in a few previous posts, I have been attempting to provide multi-file support for the PropCom interface. My initial plan was to have all the functionality for this endeavor encapsulated within one CDialogBar object, which is a derivative of the CControlBar object. My thoughts were to display all the controls contained within the CDialogBar object when obtaining information, but then to hide the majority of the controls for general use. By referring to the attached pic, you can see the affected problem area outlined within a red border.

To make a long story short, when I try to hide most of the controls and resize the view area, the Windows OS kicks in and takes over, and attempts to maintain "STATE". In probably 99% of all applications, this would be a desirable trait, but in this particular instance, it is truly annoying. If I do not find a remedy soon, I will have to abandoned this plan and seek out another solution.

Bruce

idbruce

For Those That May Be Interested

As it pertains to the problems discussed within my last several posts, here is what I intend to do to provide multi-file support. The CDialogBar which was discussed and outlined in red in the previous post, will now be used a "Property Page" within a "Property Sheet", and will be used for user settings. To replace this CDialogBar in the main window, I have simply added (9) numbered buttons to the main toolbar. These buttons will remain inactive until a user supplies file paths for each of the individual buttons within the forementioned "Property Page" and "Property Sheet". If and when a valid file path has been entered for a button, the associated toolbar button will become active, and the associated file name from the provided file path will be displayed as a "tool tip" for that specific button.

And of course, here is a new pic.

Bruce

Sapieha

Hi Bruce.

It starts look Very nice

idbruce wrote: »

For Those That May Be Interested

As it pertains to the problems discussed within my last several posts, here is what I intend to do to provide multi-file support. The CDialogBar which was discussed and outlined in red in the previous post, will now be used a "Property Page" within a "Property Sheet", and will be used for user settings. To replace this CDialogBar in the main window, I have simply added (9) numbered buttons to the main toolbar. These buttons will remain inactive until a user supplies file paths for each of the individual buttons within the forementioned "Property Page" and "Property Sheet". If and when a valid file path has been entered for a button, the associated toolbar button will become active, and the associated file name from the provided file path will be displayed as a "tool tip" for that specific button.

And of course, here is a new pic.

Bruce

idbruce

@Sapieha - Thanks for the kind words Sapieha.


@Everyone -

All right folks, here is the final determination.

There will be (3) detachable toolbars.

1. Main toolbar
2. Multi-File support toolbar
3. Pin status toolbar

Considering that most people will probably not use toolbars 2 and 3, these toolbars will be hidden at program startup, but can be enabled through the view menu at anytime. As you can see from the attached pictures, the toolbars are detachable and capable of floating as seperate toolbar windows.

Now we can move forward once again.

Bruce

idbruce

Hello Everyone

And the topic of the day... You guessed it, problems with my plan for multi-file support...

To replace this CDialogBar in the main window, I have simply added (9) numbered buttons to the main toolbar. These buttons will remain inactive until a user supplies file paths for each of the individual buttons within the forementioned "Property Page" and "Property Sheet". If and when a valid file path has been entered for a button, the associated toolbar button will become active, and the associated file name from the provided file path will be displayed as a "tool tip" for that specific button.

It sounded simple enough when I wrote the comments above, in fact most of it was simple, until I got to the final step, which was as stated:

the associated file name from the provided file path will be displayed as a "tool tip" for that specific button.

I have never messed around with the CToolTipCtrl class before, so this is all new to me, and possibly someone here might now the answer to my problem, which is getting access to the tool tip control. The multi-file toolbar is created with the following code:

if (!m_wndMultiFileBar.CreateEx(this, TBSTYLE_FLAT, WS_CHILD | WS_VISIBLE | CBRS_TOP
  | CBRS_GRIPPER | CBRS_TOOLTIPS | CBRS_FLYBY | CBRS_SIZE_DYNAMIC) ||
  !m_wndMultiFileBar.LoadToolBar(IDR_MULTIFILE))
 {
  TRACE0("Failed to create multi-file bar\n");
  return -1; // Failed to create multi-file bar
 }

As you can see in the code above, this toolbar should support tooltips by including the "style" CBRS_TOOLTIPS. At first glance, you think it will be easy, just grab the tooltip control from the toolbar and write the appropiate value.....

Well, yes and no.....

After struggling with it for a while, I did a little more research and came up with is docoument:
http://support.microsoft.com/kb/151894

This document basically states that the CToolTipCtrl for a CToolBar object is not unique or specific for any given toolbar, unless you jump through some hoops to create it for yourself. Instead, Microsoft offers a "thread" specific solution for gaining access to the tooltip control, which can be accessed as follows: (!#$%^&* SUPPOSEDLY *&%^$@)

_AFX_THREAD_STATE* pThreadState = AfxGetThreadState();
CToolTipCtrl* pToolTip = pThreadState->m_pToolTip;

Okay, so if it did work, the CToolTipCtrl class object has a method of UpdateTipText and documentation for that method can be found here:
http://msdn.microsoft.com/en-us/library/aa315728(v=VS.60).aspx

So here is a simple function that I wrote in an attempt to alter the tool tip text for one of the buttons:

void CMainFrame::OnTestToolTipUpdate() 
{
 _AFX_THREAD_STATE* pThreadState = AfxGetThreadState();
    CToolTipCtrl* pToolTip = pThreadState->m_pToolTip;
 
 pToolTip->UpdateTipText("Hello Bruce", &m_wndMultiFileBar, IDC_RUN1);
}

And for those that might be truly interested IDC_RUN1 is the control id for the first button on the multi-file toolbar and the following declaration is in the MainFrm.h header file.....

CToolBar m_wndMultiFileBar;

If anyone has any input on why the proceeding function is failing, I would love to hear the theory.

Bruce