Completion of serial transmission - strange behaviour

[Robin2]

The Meccabrain is somewhat limited although it can be driven from a tablet via Bluetooth. Some of the peripherals are interesting and I'm looking into how they can be used. The published document mentions servos and "Smart LEDs" but the MAX robot also has "Smart motors" and an ultrasonic sensor using the same protocols.

I'm also working on a signal sniffer that can read the traffic on one of the lines which will hopefully allow me to work out how an Arduino can make use of these devices. Again, I've got the communications sorted apart from a minor timing issue.

I  have not had time to re-study the PDF yet but I am commenting on this because it does not answer the question in my Reply #13, and a clear answer will make my study of the PDF much more effective.

...R

[bmd1103]

My objective is to use an Arduino to monitor and control the Meccano peripherals. This will allow them to be used in a much wider range of applications than the very limited ones for the kits they are supplied with.

[Robin2]

My objective is to use an Arduino to monitor and control the Meccano peripherals. This will allow them to be used in a much wider range of applications than the very limited ones for the kits they are supplied with.

I sorta figured that out a while back.

But you have still not answered the question in Reply #13 - perhaps in my confusion I have not asked the right question.

Can you post a diagram that illustrates the relationship between the Mega and the various Meccano items and the data flows between them. It would also help if you indicate which sections of the PDF relate to each of the Meccano items in the diagram.

I am very confused, but I suspect I could help if you can clarify stuff.

...R

[bmd1103]

I can't definitively produce a diagram showing how the various parts connect as I am trying to find out what potential the Meccano modules have for use with Arduino systems, and that is still a work in progress.  The diagram shows the official connections to the MAX system, and what I hope to be able to do with the Arduino.  As shown in the protocol document, each channel on the Meccabrain can handle up to 4 modules in positions 1 to 4, daisy-chained so that 1 is the module connected directly to the Meccabrain, 2 is connected to 1, etc.  The Meccabrain unit described in the Protocol Description is an older unit with 8 channels whereas the one I am dealing with has only 4, as shown in the diagram.



Each channel uses the signal formats specified in Sections VI and VII as shown in the diagram - commands from the Meccabrain to the modules use the standard serial protocol described in Section VI while the responses from the modules to the Meccabrain use the "PWM" format described in Section VII.  The Meccabrain also provides power to the modules and this places a limit on the number of modules that can be connected to each channel.  Since the modules reply one at a time in turn, the existing format is very inefficient - commands are issued about every 45 ms, but each module replies once in 180 ms.  If no module is connected, the others in that channel still have to wait for the full cycle.

I intend to replicate this structure, but in a more flexible way, so that any unconnected modules can be skipped, and that the full channel capacity can be used if possible.

I honestly don't know what other information I can give you - since this is an exploratory exercise intended to find out the capabilities of the system, I can't say definitely that I want to achieve a specific objective.  Thanks for your time and assistance.

[Robin2]

Your diagram is a big help - it seems like you do want the Mega to take the place of the Meccabrain - which was my question in Reply #13

However the 2 sides of your drawing are not equivalent. On the Meccabrain side there are familiar things (servo, motor. LED, sensor) all of which are regularly used with Arduinos but on the Arduno side you have Modules. I don't understand why the two sides are different.

If the ultimate purpose of the Meccabrain system is to control servos and motors then why not ditch the whole system and just use the Arduino to control those things directly - cut out the middle-man. My guess is that the Meccabrain was designed for those unfortunate folks who don't have Arduinos

...R

[bmd1103]

My "modules" can be any of the items listed in the other diagram, so I should be able to connect up a string  with two servos and an ultrasonic sensor into a single channel, for example.  The "off-the-shelf" configuration is quite limited but has some promise as the basis of a flexible system that allows the mechanical/structural components of the Meccano world to include some computer control.

So I am trying to cut out the Meccabrain element and allow the various components that are provided with the Meccano "robot"s to be connected into the Arduino world.

[Robin2]

OK so it seems like your requirement can be summarised like this ...

You want to program an Arduino Mega to communicate with Meccabrain modules in place of the Meccabrain master unit. The definition of the communication from the master unit to the modules is defined in Section VI of the manual and the communication from the modules to the master is defined in Section VII. You need help with implementing code to deal with the communication from the module to the Mega acting as master.

If that is a fair summary it would have saved a lot of time if you had put it in your Original Post.

My approach to interpreting the data from the modules (as described in Section VII) would use a series of interrupts. First you need to detect the start bit (a LOW to HIGH transition) and save the time (micros() ) then at each subsequent transition also save the time. If it is a HIGH to LOW transition then the interval from the last saved value will be the HIGH pulse width. After 8 bits you will be back to waiting for a start bit.

...R

[bmd1103]

As I have said in a number of the preceding posts, I have got two-way communication with the various supplied modules from an Arduino.  I am also successfully decoding the traffic between the Meccabrain and the various modules.

I am using an interrupt-driven approach exactly as you described.  I am connecting the Meccano signal line to pin 18, using it as TXD1 during the transmit part of the operation, then as INT3 for the receive part.

My original question arose because, depending on the value of the timeout I selected to cover the case where there is no connected module, the TXC1 interrupt appeared to be triggered mid-way through transmitting the 6-byte command string instead at the very end of it.  I can see no mechanism that would give rise to any interaction between the timer setting and the operation of the UART.

I have never stated that I need help in code to implement the communication, and I have said several times that this was not a problem.

Further testing ...

I changed the value of the timer preset to see if that had any effect - the program fails for values of the preset between 0x8A6F and 0x8D9F.  I have not tested much outside this range.  I have also tried changing to Timer 3 with no effect on the problem.

As the program is working with a delay of 12 ms - preset of 0xA23A -  I'm moving on with other areas.

The sequence I am using is based on a state transition approach.  The first set of states deal with the command transmission.  Once the command has been completely sent (I am using the TXC flag to signal this), the system moves on to the receive function, where it looks for a low-high transition on the pin previously used as TX1. When this is detected, the time is grabbed and the INT function changed to look for the next high-low transition. This then allows the pulse width to be calculated and the response bit set or cleared as appropriate.

I have got working code for this, and with the 12 ms delay I can manage to decipher the response strings. However, I am still baffled as to why the TXC flag is apparently triggered early if the timeout is within a fairly restricted range of values.

I do not need any assistance with either communication format.  I am sure I am not the only one who has wanted to do something similar with an Arduino, but can't find any references to this situation. There   is quite possibly a very simple explanation and I am simply trying to find out why the timer setting apparently affects the operation of the UART.

I'm sorry if you feel you have been wasting time on this, but I think I have made it clear in a number of posts that getting the communications going was not the issue.

[Robin2]

I'm sorry if you feel you have been wasting time on this, but I think I have made it clear in a number of posts that getting the communications going was not the issue.

OK. So I got my summary of the problem wrong.

Now can you describe the real problem equally succinctly?

...R

[bmd1103]

OK- I'll try again.

In the program I have written to transmit commands from the Arduino to a Meccano slave module, I an using Serial1, using the TXD1 function of pin 18. When the 6 bytes of the command have been transmitted, I have to change function of pin 18 so that I can use the INT3 function of pin 18 to detect transitions, using a LO-HIGH interrupt to indicate the start of a pulse and  a HIGH-LOW transition to find its end.


Since I cannot stop the serial transmitter and enable INT3 until the serial transmission has been completed, I am using TXC1 which according to my research fires when the last bit of the byte has been sent and the UDR1 transmit buffer is empty.  Because it is likely that for at least half the commands there will be no slave module at an address, I have to use a timeout feature so as not to wait forever for the INT3 interrupt.  I am using a 16-bit timer in the "normal"mode of operation (WGM33:WGM3:0 =0000) pre-loading a fixed value into the TCNT3 register. Initially I was aiming at a 15-ms timeout, with a counter preset of 0x8ACF or decimal (65535 - 30000) and prescaler of 8:1.  However, I found that the timeout was occurring at about the end of the 4th byte of the 6-byte command stream, instead of at the end of the 6th byte as I expected.  This effect is shown in the first pair of screen dumps in my initial post.  The yellow line shows when the timer is active - the green line is the activity on the signal line.

When trying to see if I could find what was affecting this, I adjusted the timeout delay down to 12 ms using the value of the timer preset set of 0xA23F.  With this value, the timeout commenced at the end of the transmission as expected, and as shown in the second pair of screen dumps.  I tried a number of different values of the timer preset and found the expected operation for values of preset outside the range of 0x8A6F - 0x8D9E.  The issue was present with Timer3 and also with Timer5.

So it appears that there is some mechanism connecting the timers with the Serial1 UART. I can visualise a number of different possibilities but without a detailed knowledge of the processor's internal operation these will be speculative only.  As my application operates quite happily with a 12 ms timeout, the problem is not preventing any sort of progress.  However, I would like to know if anyone has come across this before, or if there is some totally stupid glitch in my code.

[Robin2]

In the program I have written to transmit commands from the Arduino to a Meccano slave module, I an using Serial1, using the TXD1 function of pin 18. When the 6 bytes of the command have been transmitted, I have to change function of pin 18 so that I can use the INT3 function of pin 18 to detect transitions,

Why are you using pin 18 for both purposes? If the module responds on the Tx line then why not use a jumper to connect it to another convenient I/O pin and use your ISR on that?

You must also allow for the fact that the normal Serial behaviour is to hold the Tx line HIGH when nothing is being sent.

...R

[bmd1103]

I don't see that my choice of pin changes the issue - I still have to change the function of the Arduino between transmit and receive modes, and would still have the issue of the timer preset apparently interfering withe UART.

[Robin2]

How about starting the timeout (by saving the value of micros() ) when you start sending the data. If you know how many bytes you send then the time taken to send them should be easy to calculate. And if you are working to a 12msec interval no great precision seems to be required such that Hardware Timers add any value.

It would also mean that the timeout was entirely separate from the finer detail needed to decode a response if one arrives.

...R