Remote Control By Location Part 2

[camerart]

Hi,
Update:
I'm not sure exactly what happens with the GPS BAUD rate, but it's at 9600 now and working.

Tha master and slave are now working, but there's an issue with the SPI between them, which isn't reliable, so that's what we're looking at now.
C

 

[camerart]

Hi, (Also posting on AAC)
I try all kind od techniques to help me program, including a kind of flow chart, but mine are simple and linea.
i've just realised that the problem I'm having with SPI between 2x PICs is because I'm working linearly, and the CODE seems to need a kind of parallelism, as 2x things are kind of happening at the same time.
This is difficult, but now I see it, I hope to be able to sort it out, [let's see].
C

 

[tumbleweed]

It sounds like you're beginning to get it.

Interrupts are asynchronous events that can occur at any time. When you get an interrupt, you stop executing the main loop of your program and it branches to the interrupt handler code. When that's done you return to the main loop right where you left off.

This can occur right in the middle of some main loop statement, so it can change the timing of things in your main loop. It's also why you have to watch out for things like accessing the same hardware in the main loop and interrupt code (such as an SPI or I2C transaction), shared variables, or timing-related code like a software UART.

Trying to simulate something like that usually doesn't work very well, so a sim is pretty much useless in most situations once you have interrupts involved.

 

[camerart]

It sounds like you're beginning to get it.

Interrupts are asynchronous events that can occur at any time. When you get an interrupt, you stop executing the main loop of your program and it branches to the interrupt handler code. When that's done you return to the main loop right where you left off.

This can occur right in the middle of some main loop statement, so it can change the timing of things in your main loop. It's also why you have to watch out for things like accessing the same hardware in the main loop and interrupt code (such as an SPI or I2C transaction), shared variables, or timing-related code like a software UART.

Trying to simulate something like that usually doesn't work very well, so a sim is pretty much useless in most situations once you have interrupts involved.

Hi T,
Early in the year on another thread, I had INTERRUPTS timing explained to me, and was surprised at the speed things happen, and I kind of understood it then, but it didn't really help with my programming around it skills.
Interruptions while concentrating is a similar example, it's hard to keep track, whie being interrupted.

I rely on the simulator, as a visual aid to programming steps, and understand that it can't show me both PICs at the same time, and also use a digital analyser to further help, also sometimes an ocilloscope.

It's also why you have to watch out for things like accessing the same hardware in the main loop and interrupt code (such as an SPI or I2C transaction), shared variables, or timing-related code like a software UART.

I'm using most of the above, except I2C. As for shared variables, my mate has tidied the CODE up with PROCEDURES, INCLUDES and FUNCTIONS, but sometimes, to his horror, I have to put them back in line, and use my own individual variables, just so that I can read it.

Cheers, C.

 

[camerart]

Hi,
Hurray!
The 2x PIC are now talking via SPI.
There's a few corrections, but I'll try not to break it.

C.

 

[camerart]

Hi,
A quick update:
I've just kind of wasted a few weeks simulating the programs, to make sure they were discriminating good sentences from bad ones at the beginning of the sentence e,g, GNRMC=GNRMC.
I simulated every odd sentence as bad, which appeared to be working, but I've just found out that the SIM was missing every second sentence, which looked as though it was disciminating
C.

 

[camerart]

Hi,
I'm hoping that all messages between BASE and REMOTE and GPS are ok, so I'm leaving out the message 'good sentence discrimination' section till later.

I think all is working on the BASE PIC pair, so some tidying up, then copy most of it to the REMOTE PIC pair, with the obvious? differences, and hope they start talking to each other.

Thank you all for getting me this far
C

 

[camerart]

Hi,
At last BASE and REMOTE are 'talking' to each other! There are a lot of glitches in it, and it needs coaxing to keep it running.

The REMOTE's output, which would be stuff like battery voltage, isn't wired up, to it sends a dummy message, so the system works.

Here's an image: The top view is a terminal connected to a PIN on the PCB, for monitoring.
The Bottom is the messages between them, so the long line would have CONTROL DATA in it.

There are a lot of glitches in it, and it needs coaxing to keep it running.

EDIT: I've just noticed the 2xPRESSURE from each unit are results are very different, the SLAVE is wrong. It was ok earlier.
There is only 1x bit of DATA correct so far and that's the '1' in TOFRO.
C.

 

[camerart]

Hi,
When a sentence is read ($ to W) it is put in a BUFFER, either gnrmc_buf or bori().
There are 4x programs. 2x of them show the BUFFER like the CHAR image and 2x show the BUFFER as the BYTES image. I want them to look like the CHARS image, not the BYTES image.
Can someone tell me how to do this please.
Here are the images and the possible CODE where this is done?

EDIT: I found the answer! I changed this line: Dim bori As String '(48) As Byte '
C

On High Interrupt
Save System

'OVERRUN ERROR
If PIE1.RCIE = 1 Then  'EUSART Receive Interrupt Enable bit
    If RCSTA.OERR = 1 Then
        Gosub irqinitbuf  're-init buffer, discard bad sentence
        Goto RXIRQdone  'done, wait for next character
    Endif  'OERR

    'FRAMING ERROR
    If RCSTA.FERR = 1 Then
        dumpchar = RCREG  'Read char to clear RCIF and FERR
        Gosub irqinitbuf  'Re-init buffer, discard bad sentence
        Goto RXIRQdone  'wait for next
    Endif  'FERR

    'No UART errors, process character
    If PIR1.RCIF = 1 Then
        RXIRQchar = RCREG  'read the received char, clears RCIF

        'Look for $, start/restart filling buf when found
        If RXIRQchar = "$" Then  'Start (re)filling buf on any $
            Gosub irqinitbuf  'init buffer, index and flags@
            gnrmc_buf(gnrmcpsn) = RXIRQchar  'store $ $ ADDED instead of RXIRQchar, because no $ was being stored
            gnrmc_buf_filling = 1  'start storing the sentence
            Goto RXIRQdone  'done with this character
        Endif  'char was $



        'no UART errors and character was not $
        'If $ was found previously, process character looking for W and no buffer overflow.
        'If haven't found $ yet, just ignore character.

        If gnrmc_buf_filling = 1 Then  'if filling buffer, see if there is room in buf
        Break  '<<<<<<<<<<<,
            If gnrmcpsn >= (rxbufsize - 1) Then  'last char was at end of buf - buffer overflow so..
                Gosub irqinitbuf  'restart buffer, discard sentence
                RXerr = 1  'let main know that the buffer overflowed and is restarting
                Goto RXIRQdone  'done, resume looking for next $
            Endif  'buffer overflow

            gnrmcpsn = gnrmcpsn + 1  'else, there's room in buf so bump index and store character, might be W
            gnrmc_buf(gnrmcpsn) = RXIRQchar

            If RXIRQchar = "W" Then  'if end of sentence..
                RCSTA.CREN = 0  'shut down UART
                PIE1.RCIE = 0  'Enable off
                gnrmc_buf_filling = 0
                gnrmc_buf_full = 1
                Goto RXIRQdone  'and bye!
            Endif  'RXIRQchar was W
        Endif  'If gnrmc_buf_filling = 1
    Endif  'RCIF=1
Endif  'RCIE=1

    'Exit point for each RXinterrupt. Process timers
    RXIRQdone:

Resume

 

[camerart]

Solved

 

[camerart]

Hi,
Up to now, approx 6 years, this project has been dealing with 4 PIC programs, on 2x PCBs BASE and REMOTE, getting all of the sensor peripherals to 'talk' to each other and send messages beteen BASE and REMOTE. I think we are just about there.
If there are any questions regarding CODE for the above, please post it here. The CODE now needs proof reading and I'm sure there will be lots of modifications to the CODES. Once they look about right I'll post them here.

EDIT: Any change recommendations, or ideas for the above please post here!

I'm going to start another thread for the actual control, between these modules, which is the whole idea for the project, and a completly different thing, that I'm looking forward to.
Thanks for all of the help
C.

 

[camerart]

Hi,
The 4x programs are kind of working, between the BASE and REMOTE.

As a test, I'm simply using the project as normal radio control works, until I've smoothed out the peripherals etc.

When I move the BASE joysticks, the SERVOs move on the REMOTE, which is quite good to see.

I've got the BASE to work quite well, and can see the BORI (DATA sent from the BASE) act almost immediately.
I've yet to speed up the REMOTE.

What is happening however, is both SLAVE PICs stall occasionally, and need resetting.
Previously, GUARDS were added to watch for missing signals, I'll have to check around them.
I would like to know how to go about finding errors like this, if anyne has ideas?
C.

 

[DogFlu66]

The project is too extensive and the forum, not being in my language, makes it difficult for me to help with such extensive projects. What I can tell you when talking about my professional projects is that I always leave the pins involved in the ICSP free to use them later for debugging and I even usually leave an RS232 TTL port also for the same thing. In this way you can send information from several cards or even from several microcontrollers on the same card with certain information as appropriate for the developer and therefore to facilitate debugging.

 

[camerart]

The project is too extensive and the forum, not being in my language, makes it difficult for me to help with such extensive projects. What I can tell you when talking about my professional projects is that I always leave the pins involved in the ICSP free to use them later for debugging and I even usually leave an RS232 TTL port also for the same thing. In this way you can send information from several cards or even from several microcontrollers on the same card with certain information as appropriate for the developer and therefore to facilitate debugging.

Hi D,
Any help is good help, so thanks.
I only use the ICSP pins for programming.
I also use a serial out pin for monitoring. e,g [ Serout PORTB.0, 9600, "SLAVE-RDY ", CrLf ]

The Oshonsoft simulator is handy for individual PICs, but with 4xPICs running at once, it all needs to run 'live'.

Using the serial out, I can work though the CODE somewhat, and I need quite a bit of intuition, to get the feel of things while watching it.
Cheers, C.

 

[DogFlu66]

It's quite challenging to explain a method. After nearly 20 years of developing and manufacturing microcontroller-based automation systems, I've created a sort of 'mini operating system.' Everything is based on interrupts and the distribution of time across functions. For example, if there's a function waiting for data, you must always include an exit route in case the data doesn't arrive. The programming and debugging methods are skills that come with experience and are also very personal. My programs aren't entirely linear; they are based on distributing time among functions as much as possible. Anyway, the concept of a program being 'blocked' is quite relative. It might just be that a module of the microcontroller got stuck for some reason, but that doesn’t mean it stopped working entirely. It was just that a function or part of the code was waiting for something, and if the code is too linear, everything else stops functioning.

 

[DogFlu66]

For instance, I once wrote an article for an electronics magazine about the 555 timer. In the article, I stated, 'The 555 is an integrated circuit that could fill an entire book on its own.' The editors of the publication added in parentheses, '(In fact, such a book has already been written).' The same can be said for the various methods and approaches to debugging software; the methodology is truly extensive. Just as the 555 timer has inspired numerous discussions and publications due to its versatility and broad application in electronics, debugging techniques in programming are vast and diverse. Each strategy can be deeply explored, reflecting the complexity and nuances of software development. These methods evolve with technology, continuously requiring new literature and expert insights to address emerging challenges in the field.

 

[camerart]

It's quite challenging to explain a method. After nearly 20 years of developing and manufacturing microcontroller-based automation systems, I've created a sort of 'mini operating system.' Everything is based on interrupts and the distribution of time across functions. For example, if there's a function waiting for data, you must always include an exit route in case the data doesn't arrive. The programming and debugging methods are skills that come with experience and are also very personal. My programs aren't entirely linear; they are based on distributing time among functions as much as possible. Anyway, the concept of a program being 'blocked' is quite relative. It might just be that a module of the microcontroller got stuck for some reason, but that doesn’t mean it stopped working entirely. It was just that a function or part of the code was waiting for something, and if the code is too linear, everything else stops functioning.

Hi D,
"you must always include an exit route in case the data doesn't arrive."
This is something I need to understand better. 'GUARDS' were put in for this reason, which counti if something doesn't happen and reset, back to the loop, this may happen 'say' if a radio signal was lost.
I have a friend that help me, who says the this should be done differently, but he hasn't explained yet.
C

 

[camerart]

For instance, I once wrote an article for an electronics magazine about the 555 timer. In the article, I stated, 'The 555 is an integrated circuit that could fill an entire book on its own.' The editors of the publication added in parentheses, '(In fact, such a book has already been written).' The same can be said for the various methods and approaches to debugging software; the methodology is truly extensive. Just as the 555 timer has inspired numerous discussions and publications due to its versatility and broad application in electronics, debugging techniques in programming are vast and diverse. Each strategy can be deeply explored, reflecting the complexity and nuances of software development. These methods evolve with technology, continuously requiring new literature and expert insights to address emerging challenges in the field.

Hi D,
Today I was watching part of an op-amp video, which is explaining many different uses for them, which is similar to your 555 stuff.
C

 

[camerart]

Hi,
Today I was watching the radio signals using a terminal, where messages like this would appear: [ ROBI,111,1,11,W ] so take the first group 111, this is obviously 3xBYTEs 1 and 1 and 1, but it represents a WORD, so 2x BYTES 00000000 and 01101111.

The 2xBYTES are converted to digits, transmitted/received dissected, and presented, so I can read them.

If I sent them as 00000000 and 01101111, I wouldn't be able to check them, but it would be much more efficient.

So, Ive got to try and take this step, even though it would be uncomfortable, and I'll have to figure a way of checking it.
C.

 

[DogFlu66]

I understand you. I'm currently working on some functions to decode the data contained in the data frames generated by AIS equipment. The first thing I did was create a function to check the frame's checksum before processing it. If the checksum is incorrect, the frame is discarded, thus saving time by not processing it. I also have another function that, for now, only extracts the Maritime Mobile Service Identity (MMSI) number from the vessel.

In the following example of a data frame, among other information, the MMSI number 224026920 is included. The data frame is represented as '!AIVDM,1,1,,A,13EaQ:?P00wgp<RE0kU>4?w420SA,0*27'. This format encapsulates various pieces of data essential for maritime communication, including the unique identifier for the vessel.