Programming protocols, Includes, subroutines, procedures.

BobaMosfet

Joined Jul 1, 2009
1,012
Hi E,
I agree it is a mess, but it's the only way I can keep things in groups. I've spent months trying, then having to start again because I lost my way, until I started using this method.
Not to worry, I'll carry on and see what happens for a while, then post the result.
C.
@camerart- Have you considered learning how to flow-chart? Programs are expressions of logic. You can create a flow-chart to describe an entire process of how to do something, in simpler terms, and then write code to match the flow-chart.

A simple example:

upload_2019-9-30_14-54-9.png

The flow-chart describes the logic in a very high-level human-understandable form, and let's you code it in any language you wish.
 

djsfantasi

Joined Apr 11, 2010
6,196
Are you starting with code or do you write out a set of requirements first? In English or whatever your native language is.

I always start with a set of requirements. And they dictate how I organize my program. They should make procedures obvious.

I also hear what you are saying about how you can understand program execution in serial. But by breaking steps into tasks or procedures, believe me, it is much easier to develop and debug.

Let me explain...

First, I mentioned tasks and procedures. The way I think, a task is what needs to be done in your requirements. A procedure is the code to execute that task. A procedure can be a function or subroutine (Gosub).

What makes development and debugging easier, is you write only one procedure at s time and test it by itself. Once it works, you should be able to be confident that it will work in a larger program, meaning you should have less to test. Here is what one of my programs (in pseudo-code) looks like.

Code:
Main()
Check_Inputs
Set_Outputs
End Main

Void Check_Inputs()
  Check_Sensor1()
  Check_Sensor3()
End Check_Inputs

Void Check_Sensor1()
  Read Sensor_1
  If Sensor_1 == someVal {
     Set Flag_1=true
  } else}
    Set Flag_1=false
  }
End Sensor1
Note that this is a simple example. I have a one to one relationship between tasks and procedures. I stopped before showing any other procedures as I hope that the procedures for checking inputs can be generalized by you to setting outputs.

The main code is simple and unencumbered by the specific code required by other tasks. It should be obvious that you sketch checks some inputs. And based on those results, manipulates outputs.

In practice, if your procedures are called but once, instead of a procedure, you can define them in a code block.

You will have to become familiar with the scope of your variables using this approach. I don’t know about Oshonsoft Basic, but in C you can define all variables as global to start. As your programs become larger, you can learn how to localize your variables.
 

Thread Starter

camerart

Joined Feb 25, 2013
1,827
Hi B and d,
I'm sorry to say, but others have tried to explain 'Flow chart' and 'setting up requirements' before and I fail to be able to put it on paper, although I suppose I do have it in my head. What I started with was an idea, that I had no concept of how it could be done, and what PICs I was going to use.

First I've tried to change from the BASIC language I learnt in the 80s, and failed. The word VOID didn't help, my head says 'ridiculous' every time I see it.

I picked one section out of my mind, 'say' ALTITUDE, and looked for a CHIP. I tried programming different pressure peripherals e,g, Nss607, GY-282, HMC9250, perhaps 6 or 7 different PCBs, till I got one going (BMP280) During this testing, I changed to SPI instead of I2C. Now I had a program that READ TEMP and PRESSURE.

I picked a second section, 'say' COMPASS and went through the same process. All of the time being helped and corrected by forums such as this.

Each time I get a program working I etch a PCB and test it live. All good practice! I had a professional breadboard, with LEDs switches and clock, but didn't get on with it.

Along the way, I have to change PICs, due to speed or memory, and even add a second one, for the QEI.
I've tried keeping the sections in INCLUDES, then once I added lots of comment lines like: AAAAAAA BMP280 AAA to separate each peripheral, I was able to sort out the order of things, till last week when it all started working after perhaps 4 years of this.

After advice, I put everything into PRODEDURES and started testing.

Today, after being advised to lessen the comment lines, then being advised to put the DIMs back to the top of the program, got mixed up again, so will go back to the working program of last week, and have another go.

NOTE: I remember when I adopted capital letters for computing words to help me scan posts, approx 4 years ago, I dropped into the 'chat room', and found I was being mocked for it. Remedy, I haven't looked in the chat room since;)

Thanks, C.
 

dl324

Joined Mar 30, 2015
10,072
What I started with was an idea, that I had no concept of how it could be done, and what PICs I was going to use.
Adding "structure" to a program can make it use more memory and run slower. How much memory/storage do you have and how much are you using?
 

Thread Starter

camerart

Joined Feb 25, 2013
1,827
Adding "structure" to a program can make it use more memory and run slower. How much memory/storage do you have and how much are you using?
Hi d,
What are you calling 'structure'? Do you mean adding PROCEDURES and GOSUBS?

Re Storage: Does this tell you?
C
 

Attachments

Thread Starter

camerart

Joined Feb 25, 2013
1,827

ericgibbs

Joined Jan 29, 2010
9,575
hi C,
As you know in SPI there is a Master which sets the pace of the Bit by Bit transfer, which is usually set by the divided Master PIC Xtal rate.
It is possible to introduce delays in the Master when calling for a Byte from the Slave, but I am not aware of any method of slowing down the Bit rate clock in the Master.
So it is important that the Slave has at least the same Xtal rate, a higher Slave Xtal works OK.

Obviously it make sense to keep these inter Byte delays as short as possible, but long enough to enable the Slave to load its Buf Register with the next Byte, to be Ready for the next Master Bit by Bit transfer.

In SPI 'burst' Mode, the 'ss' is used Only as Slave Enable/Attention call, issued just prior to exchanging a sequence of Bytes and the 'ss' is Reset at the end of the transfers.

Note: Xtal refers to a crystal or Internal PIC osc.

E
 

Thread Starter

camerart

Joined Feb 25, 2013
1,827
hi C,
As you know in SPI there is a Master which sets the pace of the Bit by Bit transfer, which is usually set by the divided Master PIC Xtal rate.
It is possible to introduce delays in the Master when calling for a Byte from the Slave, but I am not aware of any method of slowing down the Bit rate clock in the Master.
So it is important that the Slave has at least the same Xtal rate, a higher Slave Xtal works OK.

Obviously it make sense to keep these inter Byte delays as short as possible, but long enough to enable the Slave to load its Buf Register with the next Byte, to be Ready for the next Master Bit by Bit transfer.

In SPI 'burst' Mode, the 'ss' is used Only as Slave Enable/Attention call, issued just prior to exchanging a sequence of Bytes and the 'ss' is Reset at the end of the transfers.

Note: Xtal refers to a crystal or Internal PIC osc.

E
Hi E,
I appreciate that it's difficult to follow, exactly what I'm doing, as I have to change things mid-stream sometimes. Having spent a lot of time failing to get 2x PICs to be MASTER and SLAVE using SPI, I gave up, leaving the offer to test any SPI MASTER/SLAVE programs on the other thread #533. I carried on but changed to sending the QEI DATA via SLAVE SEROUT, to the MASTER SERIN, using the SLAVE SS PIN for the transfer. This is working ok.

If I had understood, HSEROUT/SEROUT better, I would have used it in the first place instead of the tortuous SPI route.
C
 

Thread Starter

camerart

Joined Feb 25, 2013
1,827
Hi,
There is a problem with the COMPASS. Using a program that was previously working. I have a selection of compasses

I'm getting intermittent results. sometimes it works, sometimes it doesn't. The connections are ok, SPI signals are showing on the 4620 at the PINS. There is a flashing LED showing that the program is LOOPing, and the other peripherals are working.

Can anyone suggest a test, to find what's happening please, in general terms?
EDIT: I've been testing the COMPASS modules, on a test rig, and it appears that they have all failed :( I'll keep checking and if necessary repair them.
C.
 
Last edited:

Thread Starter

camerart

Joined Feb 25, 2013
1,827
Hi,
Regarding the above COMPASS problem.
I think it could be something to do with either the MODE settings, I have mine set to CONT MODE
Or, I haven't been using DRDY, as I thought that CONT MODE didn't need it.

I'll check around these parameters.
C.
 

jjw

Joined Dec 24, 2013
508
How does the compass fail?
Are you using the SW or HW Spi?
A simple test could be to rotate the compass in for example 30 degrees steps and record the x, y values.
Show the compass part of the software.
 

Thread Starter

camerart

Joined Feb 25, 2013
1,827
Hi,
If a repeating section of CODE could be put as a PROCEDURE, is there a choice regarding the size of the CODE, whether it is worthy of being a PROCEDURE? e,g,
'''''''''''''''''''''''''''''''''''''''''''''''
SPICSOn
For i = 0 To 23
altmtr = 0 'CHIP SELECT BMP280 ON
adr = 0x88 + i
SPISend adr
SPIReceive data
b(i) = data
altmtr = 1 'CHIP SELECT BMP280 OFF
Next i
SPICSOff
''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
the above is fairly short, so would this be a PROCEDURE? It was mentioned that as SPI needs speed, then perhaps is should be left in the MAIN LOOP.

Here is a TXT, with the ALTITUDE BMP280 sections from a MAIN program, which uses SPI.

Taking this example, and noting that there is already a PROCEDURE below the bottom of the TXT (Not shown), will someone show me what sections of the TXT should be put into PROCEDUREs if any please?
C.
 

Attachments

Top