Hi,
I've been using Ublox modules succesfully for years, where they output NMEA sentences into RX of a PIC.
As the PIC RX only allows 1x source, it needs a switch, that I would like to remove if possible.
To do this I hope to use the PIC SPI to WRITE/READ the GPS.

I've been trying for weeks, but I haven't found the correct way to do this yet.
GPS modules can be programmed using U-CENTER, but that means removing them from the PIC PCB and connecting to U-CENTER then back again.

I've done a lot of research, and post it if there is interest.
Is there anyone that wants to help me 'crack' this please?
Cheers, Camerart.

 

hi,
Check this PIC,
E

 

hi,
Check this PIC,
E
View attachment 262611

Hi E,
Thanks, I have similar PICs, but I'm using 18F46K20 PICs: https://www.microchip.com/en-us/product/PIC18F46K20
I'm used to using the 18F46K20 with SPI with other peripherals, but the difficulty lies when programming the GPS Ublox M8N.
C.

 

Remember to tie D_SEL (pin 2) of the GPS to ground, that enables SPI. Otherwise it remains in UART mode.
Make sure you are not running "too fast", maximum clock rate is 5.5Mhz (maximum transfer rate 125kB/s)
Re-check the Ublox SPI timings in section 4.4 of the datasheet.

 

Remember to tie D_SEL (pin 2) of the GPS to ground, that enables SPI. Otherwise it remains in UART mode.
Make sure you are not running "too fast", maximum clock rate is 5.5Mhz (maximum transfer rate 125kB/s)
Re-check the Ublox SPI timings in section 4.4 of the datasheet.

Hi S,
I am pretty sure I've followed those settings ok, but haven't got any signs of SPI reply from the module.

The modules when bought aren't wired for SPI, so I have added a couple of extra connections, see attached.

Today I realised that U-center uses UART mode, as there are only 4x connections: +V, -V, TX/MISO, RX/MOSI.
I connected the module to U-center, along with a digital analyser, to see what is being sent.
Here is an example of setting a 200ms sentence delivery: [B5 62 06 08 06 00 C8 00 01 00 01 00] =200. The readout showed a 'checksum'.
I have not used 'parity bits' or any other bits, as I don't know about them, perhaps they are needed. Also I haven't yet tried sending the sentence above using the program.

My method of sending an ARRAY, is long hand, meaning e,g, CODE below. This is too cumbersome, as you may imagine, so I'm trying to find examples of, I think it's VAR or something? I'll have to get used to it to speed up tests.
EDITED.
C

MAIN:
m2s(0) = 0x00
m2s(1) = 0x00
m2s(2) = 0x00
m2s(3) = 0x00
m2s(4) = 0xb5
m2s(5) = 0x62
m2s(6) = 0x06
m2s(7) = 0x08
m2s(8) = 0x06
m2s(9) = 0x00
m2s(10) = 0xc8
m2s(11) = 0x00
m2s(12) = 0x01
m2s(13) = 0x00
m2s(14) = 0x01
m2s(15) = 0x00


gps_cs = 0  'CS ON
WaitUs 50

SSPBUF = m2s(0)
While Not SSPSTAT.BF
Wend
WaitUs 2
WaitMs 10
s2m(0) = SSPBUF
Hserout "s2m(0)= ", #s2m(0), CrLf
WaitMs 100

SSPBUF = m2s(1)
While Not SSPSTAT.BF
Wend
WaitUs 2
WaitMs 10
s2m(1) = SSPBUF
Hserout "s2m(1)= ", #s2m(1), CrLf
WaitMs 100

SSPBUF = m2s(2)
While Not SSPSTAT.BF
Wend
WaitUs 2
s2m(2) = SSPBUF
WaitMs 10
Hserout "s2m(2)= ", #s2m(2), CrLf
WaitMs 100

SSPBUF = m2s(3)
While Not SSPSTAT.BF
Wend
WaitUs 2
WaitMs 10
s2m(3) = SSPBUF
Hserout "s2m(3)= ", #s2m(3), CrLf
WaitMs 100

SSPBUF = m2s(4)
While Not SSPSTAT.BF
Wend
WaitUs 2
WaitMs 10
s2m(4) = SSPBUF
Hserout "s2m(4)= ", #s2m(4), CrLf
WaitMs 100

SSPBUF = m2s(5)
While Not SSPSTAT.BF
Wend
WaitUs 2
WaitMs 10
s2m(5) = SSPBUF
Hserout "s2m(5)= ", #s2m(5), CrLf
WaitMs 100

SSPBUF = m2s(6)
While Not SSPSTAT.BF
Wend
WaitUs 2
WaitMs 10
s2m(6) = SSPBUF
Hserout "s2m(6)= ", #s2m(6), CrLf
WaitMs 100

SSPBUF = m2s(7)
While Not SSPSTAT.BF
Wend
WaitUs 2
s2m(7) = SSPBUF
WaitMs 10
Hserout "s2m(7)= ", #s2m(7), CrLf
WaitMs 100

SSPBUF = m2s(8)
While Not SSPSTAT.BF
Wend
WaitUs 2
s2m(8) = SSPBUF
WaitMs 10
Hserout "s2m(8)= ", #s2m(8), CrLf
WaitMs 100

SSPBUF = m2s(9)
While Not SSPSTAT.BF
Wend
WaitUs 2
s2m(9) = SSPBUF
WaitMs 10
Hserout "s2m(9)= ", #s2m(9), CrLf
WaitMs 100

SSPBUF = m2s(10)
While Not SSPSTAT.BF
Wend
WaitUs 2
s2m(10) = SSPBUF
WaitMs 10
Hserout "s2m(10)= ", #s2m(10), CrLf
WaitMs 100

SSPBUF = m2s(11)
While Not SSPSTAT.BF
Wend
WaitUs 2
s2m(11) = SSPBUF
WaitMs 10
Hserout "s2m(11)= ", #s2m(11), CrLf
WaitMs 100

SSPBUF = m2s(12)
While Not SSPSTAT.BF
Wend
WaitUs 2
s2m(12) = SSPBUF
WaitMs 10
Hserout "s2m(12)= ", #s2m(12), CrLf
WaitMs 100

SSPBUF = m2s(13)
While Not SSPSTAT.BF
Wend
WaitUs 2
s2m(13) = SSPBUF
WaitMs 10
Hserout "s2m(13)= ", #s2m(13), CrLf
WaitMs 100

SSPBUF = m2s(14)
While Not SSPSTAT.BF
Wend
WaitUs 2
s2m(14) = SSPBUF
WaitMs 10
Hserout "s2m(14)= ", #s2m(14), CrLf
WaitMs 100

SSPBUF = m2s(15)
While Not SSPSTAT.BF
Wend
WaitUs 2
s2m(15) = SSPBUF
WaitMs 10
Hserout "s2m(15)= ", #s2m(15), CrLf
WaitMs 100


gps_cs = 1  'CS OFF
WaitMs 1

Toggle rled
WaitMs 1000

Goto MAIN

 

Also, pin 18 is SPI chip select, is that wired ok?
Not sure what is "optional" or not, depending on model of the M8. According to datasheet, the UART pins are used by SPI when D_SEL is low. Why jumpers?

 

Also, pin 18 is SPI chip select, is that wired ok?
Not sure what is "optional" or not, depending on model of the M8. According to datasheet, the UART pins are used by SPI when D_SEL is low. Why jumpers?

Hi S,
1/ Why jumpers? Do you mean my added wires? They are connected to PIN 18-C/S and 19-SCK on the left side and PIN 2-D_SEL on the right. I added extra PINS, which connect to the PIC (Just out of sight in the image)

2/ Optional M8N has a FLASH-RAM and ROM, they save settings in the FLASH and with a back-up battery will hold some settings in the RAM.

3/ I usually hold D_SEL LOW-SPI, but have tried HIGH, with it set either way I intermittently get UART, I'm not sure what other settings cause this.
C.

 

D_SEL has to be floating or high to use UART (default setting), and held low to use SPI via the TX/RX pins.
Ok, makes sense for the two wires for pins 18 and 19
Otherwise, hard to diagnose this without actually using one, which I do not have.... Try verifying the signal levels on pin2 and 18, whether they are high or low when you try to communicate via SPI

 

D_SEL has to be floating or high to use UART (default setting), and held low to use SPI via the TX/RX pins.
Ok, makes sense for the two wires for pins 18 and 19
Otherwise, hard to diagnose this without actually using one, which I do not have.... Try verifying the signal levels on pin2 and 18, whether they are high or low when you try to communicate via SPI

Hi,
Yes, difficult to diagnose without the actual set-up, but I can test and report back..

I use a digital analyser to 'see' what the PINS are doing.
C.

 

Have you read the manual?
https://www.google.com/url?sa=t&sou...cQFnoECAMQAQ&usg=AOvVaw2V1OQIpoEoQZSjyeofGEx_
The SPI hardware and protocol is different from for example PIC SPI.
There are two extra lines, Master rdy and Slave rdy

 

Have you read the manual?
https://www.google.com/url?sa=t&sou...cQFnoECAMQAQ&usg=AOvVaw2V1OQIpoEoQZSjyeofGEx_
The SPI hardware and protocol is different from for example PIC SPI.
There are two extra lines, Master rdy and Slave rdy

Hi J,
Thanks for looking.

Sadly, I did come across this, but discounted it, as it is a different module, I'm using M8N
C.

 

Just a note that the M8N runs Slave SPI mode only. So, for NEMA data, it will be output on the TX pin (20)
Remember to check if the lines need pull-ups or not....

 

Just a note that the M8N runs Slave SPI mode only. So, for NEMA data, it will be output on the TX pin (20)
Remember to check if the lines need pull-ups or not....

Hi S,
Yes, I use the M8N in SLAVE MODE.

You say NEMA I say NMEA! If you look at the image #9, you will see that the serial DATA STRING is coming from PIN 20 TX/MISO, but you can also see the D_SEL is LOW, so it shouldn't come as a STRING, but timed by the SCK and CS.

I'll look for Pull up/downs, but I'checked them switching correctly.
C

 

Yes, it is strange that there seems to be UART data before CS goes low (and after). The data on MISO should only come when D_SEL is low and CS is low.
Could it be that the device has to empty some UART buffer first? That is, after setting D_SEL low, wait a few ms before setting CS low to allow any UART buffer to empty first. Just a wild guess.... Only then drop CS to low and try to read the MISO line.
Is there any other device on the same line as MISO? If so, disconnect it.

 

Yes, it is strange that there seems to be UART data before CS goes low (and after). The data on MISO should only come when D_SEL is low and CS is low.
Could it be that the device has to empty some UART buffer first? That is, after setting D_SEL low, wait a few ms before setting CS low to allow any UART buffer to empty first. Just a wild guess.... Only then drop CS to low and try to read the MISO line.
Is there any other device on the same line as MISO? If so, disconnect it.

Hi S,
Previously, I used the GPS (latest is M8N) in UART MODE. This is set in U-center. If you don't know, or haven't got it, it is a program by Ublox for changing settings on the GPS. This uses UART with 4x PINS +V, _V, TX, RX for setting up. When set as you see in #9, it outputs NMEA sentences, (5/SEC).
This could be the problem, and perhaps I have to set the output differently, I haven't found the correct setting yet, so it only outputs with C/S and D-SEl. There are many setting to choose from!

When programming in SPI, a series of ARRAYS or STRINGS are used, see attached. This was generated in U-center, but it could be produced from one of the DATA sheets: https://www.u-blox.com/sites/defaul...ox8-M8_ReceiverDescrProtSpec_UBX-13003221.pdf In the example, if you scroll down to CFG-RATE you will see C8, this is one of the 2x BYTES that make up the rate. C8 = 200 = 5/SEC.

Only MISO both ends.
C

 

You might have to set SPI "enable" in the u-center software. If the GPS module does not know what to do when D_SEL is selected, it won't change anything

 

You might have to set SPI "enable" in the u-center software. If the GPS module does not know what to do when D_SEL is selected, it won't change anything

Hi S,
I think you're correct, but how?
If you look at '$' #9, the module must be set in UART MODE. This is the MODE that U-center uses, and I wasn't sure whether to do the same, or completelly try in SPI.
I am able to set it so that the NMEA sentences don't appear, so I presume this must be se to SPI?

I'll try SPI 'only' next, so I've got to figure out which lines out of the '8-120222' in #15 to send, and how to do it.
I'll make a program and post it, and see if it seems ok.
C

 

Hi,
I tried SPI programming the M8N with the PIC, but was unable to generate an SPI program yet..
I went back to looking at the UART file transfer.
U-center uses the UART to change settings on the M8N.
I intercepted these messages, with a data analyser.
This results in the NMEA sentences coming from the TX at 5/sec, as seen previously.
Here are the files, I've got that shows my results..
The images show where the timings match (almost). I'm trying to copy what U-center sends, so that I can change the settings.
I've chosen RATE, as the setting, I'm trying to change, which shows immediately, by a flashing LED.
If anyone wants me to try a specific test let me know.
Edited.
C.

 

Hi,
Can anyone tell me why the PIC is not sending a 10BYTE message, please?
The first BYTE of MSG1 is B5 but the analyser shows the first BYTE to be C5 ? [ msg1 = "b5,06,04,04,00,00,00,02,00,10,68" + CrLf 'RESET ]
C

 

It is confusing with sending a string, are you supposed to send ACSII characters or binary values?
You are sending "b" "5" "," etc as ASCII characters. Not sure how your receiving device (GPS) handles the comma character.
Also, I don't see your string length declaration:
STRING_MAX_LENGTH - (default value: 16, allowed range: 8-79)
System will default to 16. Your string is about 36 characters long. You assume wrong that it is 40....