Switch / case vs if/ else

Discussions of programming Microcontrollers in C
Darryl D
Posts: 38
Joined: Mon Jan 18, 2016 8:40 am

Re: Switch / case vs if/ else

Postby Darryl D » Fri Mar 10, 2017 10:48 pm

Rick
I think you may have set me onto something very useful to accomplish what I want to do. I have bean looking at bit of information and Handshake Enumeration, specifically Serialport XON/XOFF Handshake State that is available in .net using C# commands. I have a lot of research to do but is looking somewhat hopeful that .net will handle much of what I thought I had to do.

It may be, that by changing my code and simply transmitting the XON/XOFF code bytes to the PC and making a few changes in my C# application this may work. I am completely unaware, at this time, as to what effect XON/XOFF serial control protocol may have on RX coming into the PC. This may or may not be as straight forward as it might appear.

Xon 17 Resume data transmission.
Xoff 19 Pause data transmission.



The information that both BM and Rick have provided is very encouraging. The old Nerdkit community and this forum may not be very large at all, but for me it is by far the most friendly and helpful place I can find for the information I am looking for.

Thanks again

User avatar
Rick_S
Posts: 136
Joined: Sun Jan 17, 2016 3:15 pm
Contact:

Re: Switch / case vs if/ else

Postby Rick_S » Sat Mar 11, 2017 5:17 am

XON/XOFF is another method commonly used. DTR/DSR simply toggles a status line. Depending on if the level is high or low, transmission of data will either be on or off. I haven't programmed PC side software in years, but I'd bet there are a lot of examples for communications using flow controll.

I'm just trying to offer you other food for thought. Maybe it'll help, maybe not. Hopefully it will. That's the goal anyway :D

Rick

Darryl D
Posts: 38
Joined: Mon Jan 18, 2016 8:40 am

Re: Switch / case vs if/ else

Postby Darryl D » Sat Mar 11, 2017 9:10 am

I think it may have FINALY occurred to me how I can implement the principals and idea of a constant time unit that BM has been stressing in this thread. I could take an entirely different approach and instead of attempting to limit the amount of data that is sent from the PC to the micro I could increase the amount of data by what would likely be many fold.

Perhaps this is the exact idea that BM had in mind but I am just now recognizing it. I could introduce one more command byte into the list that the micro would recognize as valid. The new byte would be recognized as a do nothing, (ignore this byte) command. Having that in place, every byte in the serial stream would be a one byte command. Each byte received on the serial would be intended to be carried out asap by the micro. There would be no two byte commands required. A very small serial RX buffer could be used on the micro to hold a few bytes just in case the master gets behind executing the bytes as they arrive. There would be no timing done on the micro apart from the rate that the bytes arrive on the serial (baud rate). Most of the bytes, at times well over 99%, would be the new “do nothing command”.

Apart from the “do nothing command” there would be two other possible types of command byte arriving at the micro. The micro would have to recognize and react to these two types of command bytes and be done processing them before the next serial byte arrives at the Baud rate. Master chip commands would require that output pins on the master are either set or cleared. This can be done in one or two C code commands and should be quick and not hold up the CPU on the master micro. There would also be the occasional slave chip command in the data stream. The master would be required to recognize the command is intended for a specific slave. The required information to identify the command type and the target slave are imbedded into each command byte, that would not change. The master would send a slave byte to the target slave and perhaps receive a return byte back from that slave using the SPI. The master would then send that returned byte back to the PC on the Usart serial. This process (slave chip commands) would require considerable more time then the master chip commands, but really may not have to done in between two successive incoming baud rate bytes. As long it is eventually done even if it requires several baud rate intervals. If I could work out how to accomplish that it would be acceptable.

I think that is all that the master would ever have to do. No other timing or processing duties would be required. The code and the duties of the master would be greatly simplified.

All the motor speed settings, motor dwell periods, motor acceleration and motor deceleration would be done by inserting “do nothing commands” into the data stream at the PC. The data flow from the PC would be constant and very large, as compared to what it was in my original system. When the motors are moving very slowly there would be hundreds of consecutive “do Nothing commands” send between each master chip command. The baud rate would have to be high enough to allow for some degree or resolution in the possible high speeds available. To do that even the fastest motor speeds would likely have several do nothing bytes inserted between each successive motor step command byte.

Perhaps one of the issues I can see will be how to send the data to the serial TX on the PC. If I wish to maintain the ability to pause the CNC and do some motor position adjustment from the GUI then it is essential that there is not data sitting in the serial TX buffer that is used by .net to hold outgoing serial. It seems to me that the C# application should send data bytes to the serial (perhaps in small packets at a constant timer interval) at a rate very close to the baud rate. By doing this there should never be much data in the TX buffer at any time.

There is a considerable amount of changes that will be required to the structure of the data stream from what I now have. The C# application will be required to calculate the delay required between successive movement commands and insert “do nothing commands” into the data stream to achieve those delays. Both my master chip code and the PC C# code must be changed.

Spring is almost here, I will not likely get much of this done for months. That delay may give me time to consider ways to accomplish the changes required in the software.

Just writing thing down to post about an issue, seams to help me clarify what I am thinking about. I have occasionally recognized something that I have done wrong, some logical error, just by attempting to describe what I am doing in a post and then do not even send the post because I have determined a solution.

Anyway! This has been an interesting couple of days for me. I now have a lot to consider.

Darryl

BobaMosfet
Posts: 31
Joined: Tue Jan 19, 2016 2:48 pm

Re: Switch / case vs if/ else

Postby BobaMosfet » Mon Mar 13, 2017 9:10 am

Darryl,

Glad I can help, and a huge thank you to Rick for making a continued landing zone possible for NK folks and anyone else that finds it.

Yes, making a 'NOP' or "no op"eration command is as valid as any other, and you are now seeing what I'm talking about. Using the protocol as Rick mentioned is a much better way to manage flow-control.

BM

BobaMosfet
Posts: 31
Joined: Tue Jan 19, 2016 2:48 pm

Re: Switch / case vs if/ else

Postby BobaMosfet » Fri Jan 26, 2018 12:38 pm

Darryl-

I wonder if I'm the only one left on here... Did you go any further with this? Curious.

Warm regards
BM

User avatar
Rick_S
Posts: 136
Joined: Sun Jan 17, 2016 3:15 pm
Contact:

Re: Switch / case vs if/ else

Postby Rick_S » Sat Jan 27, 2018 9:53 am

Yeah, not much activity here or at the NK site. Seems people have moved on or gone to other forums. :( It’s a shame, I for one always liked the friendly and helping environment that began with the members at the NK site and was glad to see some of them here.

Good to hear from you!

mongo
Posts: 36
Joined: Thu Feb 25, 2016 4:45 pm

Re: Switch / case vs if/ else

Postby mongo » Sat Feb 03, 2018 12:03 am

I am still here!. Not as often as I would like, but I do try to get online when I can.

There has got to be a way to generate more interest... I would hate to see it go away.

User avatar
Rick_S
Posts: 136
Joined: Sun Jan 17, 2016 3:15 pm
Contact:

Re: Switch / case vs if/ else

Postby Rick_S » Fri Feb 09, 2018 3:50 am

Sorry I didn’t reply sooner, went out of town and hadn’t been keeping tabs on things like when I’m home. Good to hear from you though! So there are at least three of us that periodically check in. :lol:


Return to “C Programming”

Who is online

Users browsing this forum: No registered users and 1 guest