Continue to Site

Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

PIC plus-5110 LCD-GPS-BMP280-HMC5983

Status
Not open for further replies.
Hi,
Here's the combined program so far:
The GPS is working ok and showing on the 5110.
The BMP280 shows on the 5110, but the READing is incorrect, and not updating, I recognise those READings from previous tests. I'll have another try tomorrow.
If anyone can spot any obvious errors, please let me know.

EDIT: Programs 050118 1400 and 080218 0900 are the two WORKING programs I'm trying to combine. (Including the two INCLUDES fontsml and get_neo.)
C
The program here xxx -Combined.bas is the BMP-5110 program, not the combined program.
 
Spisend 0x60 should be Spisend 0xE0

You changed the values of control register and config register.
I don't know if they are wrong now.

Seems that there is no return from get_neo ?
The program here xxx -Combined.bas is the BMP-5110 program, not the combined program.
Hi J,
True I'm combining the Working BMP 5110 program with the earlier Working GPS program to make one longer one. (Later I'll do the same with the next
COMPASS program)
C.
 
Is the Yled toggling in the combined program?
Hi J,
I think your on the right track with the LED flashes. The YLED only flashes on start-up, then no more.
I tried YLED toggles inside each of the GOSUBS. get_neo = Y, get_val = Y, calc = Stays on, print = off, cmd5110= stays on, drt_lcd = Stays on.

I've posted a slightly changed program @ #533 ''18LF4520 5110 GPS BMP280 COMBINED 090218 1200'
This is now showing TIM, LAT, LON all updating TMP and PRS are correct on start-up, then the TMP and PRS stop, and the GPS keeps updating.
If I press the RESET button (which re-boots it) it all updates ok, but only once.
C
 
Last edited:
I think the combined program from yesterday might work, if you replace the last goto get_neo with return.
Give it a try.
Edit: and keep Gosub get_neo
 
Last edited:
I think the combined program from yesterday might work, if you replace the last goto get_neo with return.
Give it a try.
Edit: and keep Gosub get_neo
Hi J,
Before I change anything, will you comment on this first?
C
 

Attachments

  • Compiler warning.jpg
    Compiler warning.jpg
    45 KB · Views: 312
If these are from 08.02 version, the last warning might depend on missing return instruction of the get_neo subroutine or the get_val code is inside the get_neo
Others can be forgotten until now.

Try the changes in #544 and move the get_val outside get_neo
 
If these are from 08.02 version, the last warning might depend on missing return instruction of the get_neo subroutine or the get_val code is inside the get_neo
Others can be forgotten until now.

Try the changes in #544 and move the get_val outside get_neo
Hi J,
get_val is outside the get_neo. (As always)
I tried changing LINE 352 from GOTO get_neo to RETURN. It updates, but the PRINT 5110 is all over the place.
I've removed the sections as last 'compiler warning' out of the program, and now get this warning:
C
 

Attachments

  • Compiler warning.jpg
    Compiler warning.jpg
    21.8 KB · Views: 305
Hi J,
It's working:)
The get_neo RETURN didn't work first time, so I tried a few things, and re-tried it, and this time it worked, I don't know why.
I tried GOSUB PRINT, which didn't work, and I now realise that that section is CALLed not GOSUB (Am I correct?)
There is an artifact on the 5110 shown along with the latest program in #533. It appears to PRINT the 5110 then the artifact appears in a split second.
All in the 'compiler warnings', have been removed, so no warnings now.
Thanks very much.
C.
 
Hi,
I'm now adding a compass module HMC5983 to the test PCB. This is the last one:)

As this is another SPI module, I'm unsure whether in good programming protocol, some of the 'old' code can be used to save program length.
Some guidance please.
C.
 
Hi,
Will someone have a look at the attached jpg please?
Bear in mind that I'm pretty sure that 'burst READ' can't be done in Oshonsoft, so the section with automatic incremental pointer most likely won't work [Perhaps test later]

It looks to me that the WRITE BIT %0000001 isn't needed for all of the registers marked READ. Is this correct? SPI MODE.

C.
 

Attachments

  • Registers.jpg
    Registers.jpg
    198.9 KB · Views: 302
Hi,
I've just got the HMC5983 Compass module to return the X Z and Y register results, shown in the 2x jpg examples.

Reading the D/S, these results are in 2’s complement form.
Can anyone advise me how to do this in Oshonsoft please?
Camerart.
 

Attachments

  • XXZZYY1.jpg
    XXZZYY1.jpg
    136.9 KB · Views: 303
  • XXZZYY2.jpg
    XXZZYY2.jpg
    135.9 KB · Views: 299
Hi,
I'm using SPI to READ the HMC5983. I'm getting results showing on the 5110 screen.

Here's a couple of attachments, showing the section of program with READ x3 plus the output on screen.

For the moment I've commented out the '2.s compliment' equations, just for testing.

The digits are changing ok, but don't look correct to me.

(I'll correct the screen artifacts another time)

EDIT: Here's another attachment from Oshonsoft regarding LONGs. I'm pretty sure my problem is something to do with .HB .LB and e,g, .0B

C
 

Attachments

  • READ REGISTERS.jpg
    READ REGISTERS.jpg
    96.2 KB · Views: 297
  • READ REGISTERS 2.jpg
    READ REGISTERS 2.jpg
    193.3 KB · Views: 299
  • LONGS.jpg
    LONGS.jpg
    196.4 KB · Views: 309
Last edited:
Hi,
I'm using SPI to READ the HMC5983. I'm getting results showing on the 5110 screen.

Here's a couple of attachments, showing the section of program with READ x3 plus the output on screen.

For the moment I've commented out the '2.s compliment' equations, just for testing.

The digits are changing ok, but don't look correct to me.

(I'll correct the screen artifacts another time)

EDIT: Here's another attachment from Oshonsoft regarding LONGs. I'm pretty sure my problem is something to do with .HB .LB and e,g, .0B

C
The numbers are too big.
They should be 0-4096.
Do you use longs ?
 
The numbers are too big.
They should be 0-4096.
Do you use longs ?
Hi J,
I've found the problem, but not the solution 'yet' It's something to do with where the BYTEs are in the LONG.

Here's my effort so far:
I've been changing it. If I don't use the '2's compliment' section I get 5 digits as expected (I understand it needs the 2's compliment calc!)
NOTE: I've copied the DIMs from earlier in the Program.

'READ X REGISTER
SPICSOn
For i = 0 To 1
compss = 0 'CHIP SELECT COMPASS ON
addr = 0x83 + i 'READ XDATA ADDRESS
SPISend addr 'READ XDATA 0X83 0X84 ADDRESS
SPIReceive data
b(i) = data
'WaitMs 100 '67 MS ????????????????????????????????????
compss = 1 'CHIP SELECT COMPASS OFF
Next i
x_raw.HB = b(1) 'CHECK ORDER???????????????????
x_raw.LB = b(2)

x_hlb.LW = x_raw

If x_hlb > 32767 Then '2'S COMPLIMENT CALC
x_hlb = bit17h - x_hlb
x_hlb = x_hlb + 1
Endif

strxhlb = #x_hlb
''''''''''''''''''''''''''
'Dim x_raw As Word
'Dim x_hlb As Long
'Dim strxhlb As String
''''''''''''''''''''''''''''''

EDIT: There is also something wrong with the READs XZY all show the same result.

C.
 
Last edited:
x_raw.hb = b(1) -> x_raw.hb = b(0)
x_raw.lb = b(2) -> x_raw.lb = b(1)

What is the value of bit17h ?
Using long x is not needed as was discussed in the other thread.
2's complement:
If x_raw > 32767
x_raw = 65535 - x_raw // also x_raw = Not x_raw should be ok
x_raw = x_raw + 1
endif
 
Are the register addresses right?
Hi J,
I've tried the i2C READ with 0x3D before the READ, and the SPI 0x8x before the READ.
C.
x_raw.hb = b(1) -> x_raw.hb = b(0)
x_raw.lb = b(2) -> x_raw.lb = b(1)

What is the value of bit17h ?
Using long x is not needed as was discussed in the other thread.
2's complement:
If x_raw > 32767
x_raw = 65535 - x_raw // also x_raw = Not x_raw should be ok
x_raw = x_raw + 1dif
Hi J,
I'm working with distant memories , but I'm pretty sure Oshonsoft won't work unless LONGs are used here??
bit17h is BIT17H or %1 0000 0000 0000 0000 or 65536

EDIT: I just searched and found the area where the Oshonsoft problem was discussed. Where I am using LONGs I think I should be using SINGLES for the calculation, am I correct?
See post #408

C
 

Attachments

  • LONG.jpg
    LONG.jpg
    84.7 KB · Views: 292
Last edited:
The syntax error:
x raw = should be x_raw =
Long is not needed when x_raw = 65535 - x_raw
better use x_raw = Not x_raw
then no need to remember magic numbers.

Singles are needed, when you calculate angles from x,y, unless you have arctan function using integers.
 
Status
Not open for further replies.

Latest threads

New Articles From Microcontroller Tips

Back
Top