Looking for suggestions pertaining to new object

idbruce

Hello Everyone

In the attachment below, you will find an object that I have been working on. Most of the code has been tested, but some of it has not been tested. I am not asserting that it is error free, because I have no way to test it. I am just looking for simple suggestions to make it better, and perhaps a good set of eyes to look it over and find obvious errors, before I try to implement it with my machinery.

EDITED: Let me state for the record, this was initially intended to be a learning exercise for me and to provide me with the framework necessary for InterProp communications for my current project. In my current project, I have no need for highly repititious transmissions. As was pointed out to me, although I was aware of the potential problem, if this object were used for highly repititious transmissions, there would be a race condition for getting the available data out and overwriting the available data. In it's current state, the parent object would have to get the data out before a new transmission is received. Even though this will work for me, I believe it would be a much better object for all people if a solution were provided.

As a possible solution, I was thinking along the lines of having an array of LONGs where incoming data could be stored and read in a FIFO type manner. And then during idle time, after all data had been processed, clear the values contained within the array working backwards.

Another possible solution would be some type of BUSY indicator being set until the data had been processed by the parent.

Or perhaps a combination of both of these suggestions.

I am definitely open to complete solutions pertaining to the forementioned matter.

Additionally, although this has not been changed in the attachment below, the following method has been changed as seen below.

PUB GetDataFields(DataField1Pointer, DataField2Pointer)
  'This method can only be called once by the
  'parent object, and then DataField1 and DataField2
  'are set to zero.
  'LONGMOVE(DataField1Pointer, @DataField1, 1)
  'LONGMOVE(DataField2Pointer, @DataField2, 1)
  LONG[DataField1Pointer] := DataField1
  LONG[DataField2Pointer] := DataField2
  SetDataFieldsToZero
  NewDataAvailable := FALSE

Thanks

Bruce

Humanoido

There are many of us that appreciate your fine efforts in developing and refining this higher level communications code. When it's ready to test with a simple demo (will the same demo code run in each prop?), I can test it with my new Brain machine over here as currently it's in the wiring phase.

I created a Hybrid interface and one of the options for communications can reproduce your circuit (just by throwing a switch). You may also want to present code to run with 3 props. This would get your name and code into the multi-prop Hall of Fame.

Prop to Prop custom message creation with parsing is still somewhat in its infancy and there is no doubt that your significant contributions to the OBEX will be useful and appreciated.

idbruce

Humanoido

When it is finished, yes the same code will go into each prop.

You may also want to present code to run with 3 props.

That's easy. Just add the same object to the third prop. Pick two different pins in the master for rx and tx going to the third prop. And finally in the master prop, declare another instance of the object with a different name going to the third prop. That will be my setup for my machinery.

Bruce

idbruce

Hello Everyone

I don't know if anyone has tried this before, but this is what I am going to attempt to simulate multi-prop serial communication for testing the object that I am working on.

Lucky for me that I have a spare Propeller Proto Board for testing

On (1) Propeller Proto Board I intend wire in this fashion:

Master - IO Pin 0 - TX - 2.2K Resistor - RX - IO Pin 2
Slave - IO Pin 1 - RX - 2.2K Resistor - TX - IO Pin 3
IO Pin 31 - RX - Prop Plug TX
IO Pin 30 - TX - Prop Plug RX

In the parent object, I will add two instances of my InterComm object, and one instance of FullDuplexSerial as follows:

Master : "InterComm" (requires 2 cogs)
Slave : "InterComm" (requires 2 cogs)
Terminal : "FullDuplexSerial" (requires 1 cog)

The parent object will have access to both the Master and Slave objects and be able to display the results in the Terminal object.

It should work, we me luck

Bruce

kuroneko

idbruce wrote: »

On (1) Propeller Proto Board I intend wire in this fashion:
Master - IO Pin 0 - TX - 2.2K Resistor - RX - IO Pin 0
Slave - IO Pin 1 - RX - 2.2K Resistor - TX - IO Pin 1

One cog's output can be another cogs input and vice versa. Don't make it so complicated. Do you remember this [post=969722]example[/post]? Same principle.

idbruce

Marko



Thanks for the rescue I was heating up my soldering iron

I am going to attempt some minor code modifications. I am going to change both DataField1 and DataField2 into arrays, and add four counters, ReadDF1Counter, ReadDF2Counter, WriteDF1Counter, and WriteDF2Counter for indexing the arrays. I have not got it all figured out yet, but I will probably add handshaking to the application to determine if one side is busy.

Bruce

kuroneko

I was thinking about handshaking yesterday. XON(DC1 = 17)/XOFF(DC3 = 19) should be easy enough to implement.

idbruce

Marko

I did not even stop to think about the example, but now that you mention it, this whole object is based upon that example. LOL But I thought it was accomplished a little differently than what I suggested, but I now see that it is not. If you had not presented that example in the first place, the source code above would not exist. That was the code that really got me thinking.

In my documentation, 17, 18, 19, and 20, are listed as device control without any specifics. Any way it goes, unless I am willing to do in depth research into serial communication protocol, I will just have to wing it. LOL Pick a number, any number.

Bruce

idbruce

Marko

I have also been looking at ENQ(5)

Here is what I found:

ENQ (Enquiry): A communication control character used in data communication systems as a request for a response from a remote station. It may be used as a "Who Are You" (WRU) to obtain identification, or may be used to obtain station status, or both.

I was thinking of using that as an inquiry to a BUSY flag and then using 17 - 20 to indicate status. Additionally, SOH should rightly come before STX.

Bruce

idbruce

Marko

Here is the demo. I don't know why the values are coming back zero. I had similar calls with a different setup working the other day.

EDITED: In the following source remove NewDataAvailable := TRUE, I was using that for test purposes.

PUB ReceiveDataWithCRC | Index, Char, CRCExpected, CRCReceived, RxAttemptsCounter
  REPEAT WHILE TxString == 0
    NewDataAvailable := TRUE

Bruce

kuroneko

Working demo code attached.

idbruce

Marko

Here is a clean version with all my known mistakes removed and a better demonstration.

Bruce

idbruce

Marko

Here is the latest revision. Handshaking is now implemented. It is better, faster, stronger, and more dependable.

Bruce

idbruce

Here is the latest revision which is easier to interface. More to come!

idbruce

Marko

I made some modifications to the object and demo. I am currently testing it within a loop, and as it stands right now, over 10,000 transmissions and receptions have been completed without one single error. I am going to just let it run for quite a while, and I will let you know the results later today. I was thinking that this object is perfect for G-Code transmissions and receptions between Propellers.

As we previously discussed, every situation will be a little different. I can foresee quite a few CNC'ers wanting to modify the parser and data input/output, but ending up in trouble. I think we could possibly make some spare change by making these modifications for them. And we could use the demo to let them know this service is available. I don't mind helping out here and there for free, but writing custom parsers and creating custom data input/output would be a little more time consuming. Would you be interested in something like that?

Bruce

kuroneko

idbruce wrote: »

As we previously discussed, every situation will be a little different. I can foresee quite a few CNC'ers wanting to modify the parser and data input/output, but ending up in trouble. I think we could possibly make some spare change by making these modifications for them. And we could use the demo to let them know this service is available. I don't mind helping out here and there for free, but writing custom parsers and creating custom data input/output would be a little more time consuming.

In general yes, no problems on my side re: small changes. That said, how many sufficiently different kinds of formats do you expect in this area? For example, if the input format is always string based you could detach the parser from the actual InterComm object and let the latter just return the received payload which is then passed to the parser (if applicable). What I'm getting at here is that ATM the parser is hard-wired to the comm object so maybe there should be a way of replacing it other than editing the comm object. So you could have a custom wrapper object (default provided by you) which connects InterComm and parser object.

idbruce

Marko

Over 52,000 transmissions and receptions and still going strong.

if the input format is always string based you could detach the parser from the actual InterComm object and let the latter just return the received payload which is then passed to the parser (if applicable).

And that is another fantastic idea!!!!!

Of course I am just guessing, but I would imagine, that there will we approximately 12 cnc mods per year.

The demo is not completely finished, but let me touch up one other thing, and I will upload it.

Bruce

idbruce

Marko

Here is the latest copy with revisions to both the object and the demo. I will probably go over the demo one more time, to perhaps add one or two more strings. I am not sure yet.

You may want to alter the compact demo.

When I finally stopped it, over 56,000 TX/RX.

Bruce

MagIO2

Hi Bruce,

some comments from my side:
1. You could move parsing after checking the CRC. Then you don't do the work in case the transmission was faulty.
2. Before putting it into the Obex, you should decrease the stacksize to the minimum. Some projects need to squeeze out any byte.
3. I see a problem with the if condition in the trim function. You should add OR CHAR==0. Then the trim will return latest when it found the string-end. With the CRC check before parsing it shoud not happen often that you parse a "rubbish" message, but even with CRC it can happen, as with a bad connection also the CRC could be corrupted and by coincindents match with the corrupt message.

idbruce

MagIO2

I have not looked recently, but I am sure you know what you are saying by:

You could move parsing after checking the CRC. Then you don't do the work in case the transmission was faulty.

I was having a problem and I thought stack size might resolve it. Yes I will lower that.

Before putting it into the Obex, you should decrease the stacksize to the minimum. Some projects need to squeeze out any byte.

I will definitely look at the following:

I see a problem with the if condition in the trim function. You should add OR CHAR==0. Then the trim will return latest when it found the string-end. With the CRC check before parsing it shoud not happen often that you parse a "rubbish" message, but even with CRC it can happen, as with a bad connection also the CRC could be corrupted and by coincindents match with the corrupt message.

Thanks for the tips Andreas

Bruce

idbruce

Marko

Are you still with me?

I definitely need your expertise with this one. I am trying to eliminate the 4 cog requirement for communication, therefore I would like to combine FDS with the InterComm object. I thought this was going to be a simple cut and paste, but I see it goes a little deeper. The attachment appears to be close, but in the "Start" method of FDS, the cognew goes into the "entry" method which is written in assembly. Is there a way to combine our "initialize" method into the "entry" method. Please take a peek.

Bruce

idbruce

Marko

I just noticed several errors. Of course these will have to be remedied. But they are apparent.

Bruce

kuroneko

I'm not quite sure re: 4 cog requirement. Each end only uses two!? Or is the plan to get down to one each?

idbruce

Marko

Yes, that is what I would like to accomplish one each, instead of two. I think it would be a much more attractive object if it only used one cog per comm. Picture a master that must communicate with two chips, that would be four cogs out the window.

Bruce

idbruce

Marko

As much as I would like to participate in this, instead of throwing it on your shoulders, I just don't understand the assembly.

Bruce

idbruce

Marko

This file should be in better shape. All readily apparent errors have been fixed.

Bruce

kuroneko

OTOH, merging both means that the comm channel itself is hard-wired to an FDS style link. I'll have to think about this a bit.

idbruce

Marko

Think away my friend. I know you are a thinker.

Bruce

kuroneko

idbruce wrote: »

All readily apparent errors have been fixed.

Is that why it doesn't compile?

idbruce

Marko

LOL Hmmmmm..... I can't answer that one!

Bruce

idbruce

Marko

I removed the following methods from FDS because they weren't necessary for the InterComm, but perhaps they are necessary for compiling with the assembly code.

• PUB str
• PUB dec
• PUB hex
• PUB bin

Bruce