TheBackShed.com

Forum Index : Microcontroller and PC projects : Micromite V5.04.09 Beta 16

Page 1 of 2

Author

Message

Geoffg

Guru

Joined: 06/06/2011
Location: Australia
Posts: 3292

Posted: 08:33am 26 Mar 2018

Copy link to clipboard

Print this post

I have a new beta version of the Micromite Plus firmware (beta 16) for anyone who would like to experiment.

This implements double precision floating point for the Micromite Plus (the standard Micromite is still single precision). It is an experiment as a significant change like this has the potential to break people's programs - so I would be interested if it works for you or breaks some programs. Other than the improved accuracy the most noticeable change is that when you print a number it will automatically display up to 9 or 10 digits resolution. For example:

> Print 1/7
0.1428571429
>

The number of digits can be changed with the Str$() function. For example, this displays the same number with 16 digits (about the limit of double precision's resolution).

> Print Str$(1/7, 1, 16)
0.1428571428571429
>

It can be downloaded from: http://geoffg.net/Downloads/Micromite/Micromite_V5.04.09_Beta.zip

This beta also includes the other changes introduced in previous betas. For example, the fix for issues with corrupted 5" displays, the ability to use display drivers written in BASIC, STATIC variables, etc.

Geoff

Geoff Graham - http://geoffg.net

OA47

Guru

Joined: 11/04/2012
Location: Australia
Posts: 986

Posted: 09:06am 26 Mar 2018

Copy link to clipboard

Print this post

Thank you Geoff

sagt3k

Guru

Joined: 01/02/2015
Location: Italy
Posts: 313

Posted: 09:26am 26 Mar 2018

Copy link to clipboard

Print this post

Very good improvement
Thanks Geoff

robert.rozee
Guru

Joined: 31/12/2012
Location: New Zealand
Posts: 2442

Posted: 09:53am 26 Mar 2018

Copy link to clipboard

Print this post

hi geoff,
just out of interest - what would be the (approx) flash penalty of adding double precision floating point to the MX170?

cheers,
rob :-)

Geoffg

Guru

Joined: 06/06/2011
Location: Australia
Posts: 3292

Posted: 10:43am 26 Mar 2018

Copy link to clipboard

Print this post

3.5KB flash and 512B RAM.

Geoff Graham - http://geoffg.net

robert.rozee
Guru

Joined: 31/12/2012
Location: New Zealand
Posts: 2442

Posted: 12:20pm 26 Mar 2018

Copy link to clipboard

Print this post

personally, i'd consider that a worthwhile tradeoff. of course, the ram consumed by any arrays would also double - although introducing a 'byte' and 'int16' types would mitigate that

is there any chance of a 'double precision' compile being added for the MX170 at some future time? assuming it wouldn't create any extra work for you. just an extra .hex file in the download (that also notes in the signon message that double precision is included, to prevent any confusion).

cheers,
rob :-)

Geoffg

Guru

Joined: 06/06/2011
Location: Australia
Posts: 3292

Posted: 01:51pm 26 Mar 2018

Copy link to clipboard

Print this post

robert.rozee said introducing a 'byte' and 'int16' types would mitigate that

Aaagghh, no. The three data types are complicated enough. Adding more would cause mayhem (and consume valuable flash).

robert.rozee said is there any chance of a 'double precision' compile being added for the MX170 at some future time?

No, I tried it but the MX170 has less than a couple of KB free and anyway, these are required for bug fixes.

Geoff Graham - http://geoffg.net

robert.rozee
Guru

Joined: 31/12/2012
Location: New Zealand
Posts: 2442

Posted: 11:33pm 26 Mar 2018

Copy link to clipboard

Print this post

i was thinking more of a version that had the flash available for the basic program reduced proportionately - it would be just for those who need/want the double precision for specific applications. and with the 1455 programmer becoming a 'standard item', changing over the firmware isn't such a big issue as it used to be.

then again, i may be the only person who would use the double precision! we really do need microchip to double the flash again (aka the thus far fictional MX190).

cheers,
rob :-)

redrok

Senior Member

Joined: 15/09/2014
Location: United States
Posts: 209

Posted: 12:01am 27 Mar 2018

Copy link to clipboard

Print this post

Hi Robert

robert.rozee said then again, i may be the only person who would use the double precision! we really do need microchip to double the flash again (aka the thus far fictional MX190).
cheers,
rob :-)

Count me in the Double Precision for the MX170 crowd.

redrok

Phil23
Guru

Joined: 27/03/2016
Location: Australia
Posts: 1667

Posted: 09:16pm 27 Mar 2018

Copy link to clipboard

Print this post

Just tried it in an E64 & it resolved the issue I was having with IEEE754 conversions mentioned here.

So are floats stored as 24 bits & is it just the conversion that has changed, or has the bit count changed also?

Phil.

Edit:- Meant 32 bit vs 64. Think I get it now.Edited by Phil23 2018-03-29

sagt3k

Guru

Joined: 01/02/2015
Location: Italy
Posts: 313

Posted: 06:04am 30 Mar 2018

Copy link to clipboard

Print this post

Hi Geoff
I'm tryng new firmware with my board with pic32 mx 64pin connected via USB and a MPU6050 via I2C at 400khz and res pullup 10k.
I view strong delays and possible loss ofconnections with I2C when I use USB. While if I connect a usb/uart as CP2102 in console the communication is fluid.
Where could the problem?
Thanks
Antonio

Geoffg

Guru

Joined: 06/06/2011
Location: Australia
Posts: 3292

Posted: 07:53am 30 Mar 2018

Copy link to clipboard

Print this post

Interesting.

Is this a new issue?
Did it work OK with a previous release?
If so, what was the release version?
Are you using the built in I2C functions (I2C OPEN, etc) or the I2CPort CFunction?

With a bit more information I can setup a test circuit to investigate.

Geoff

Geoff Graham - http://geoffg.net

Geoffg

Guru

Joined: 06/06/2011
Location: Australia
Posts: 3292

Posted: 08:04am 30 Mar 2018

Copy link to clipboard

Print this post

BTW, 2.2kΩ pullups are recommended for 400 kHz.

Geoff Graham - http://geoffg.net

sagt3k

Guru

Joined: 01/02/2015
Location: Italy
Posts: 313

Posted: 08:19am 30 Mar 2018

Copy link to clipboard

Print this post

Thanks Geoff
I will try, I will let you know.
Thanks
Antonio

sagt3k

Guru

Joined: 01/02/2015
Location: Italy
Posts: 313

Posted: 01:05pm 30 Mar 2018

Copy link to clipboard

Print this post

Hi Geoff
I tried different combination.
If I connect with usb standard console and I use i2c, after a lot a data at 115kbaud ..afetr 10 sec ...and I use I2c ...the var MM.I2C return 2.
Same circuit, same code, same slave i2c modules but I use a cp2102 connected on console same code same baudrate it works several minutes without problems.
Now I try changing with old firmware...
Some idea?
ThanksEdited by sagt3k 2018-03-31

Geoffg

Guru

Joined: 06/06/2011
Location: Australia
Posts: 3292

Posted: 01:26pm 30 Mar 2018

Copy link to clipboard

Print this post

I guess from your response that you are using the built in I2C functions BUT I still need the answer to these questions:
Is this a new issue (with the current beta)?
Did it work OK with a previous release of MMBasic?
If so, what was the release version?

Geoff Graham - http://geoffg.net

sagt3k

Guru

Joined: 01/02/2015
Location: Italy
Posts: 313

Posted: 05:32pm 30 Mar 2018

Copy link to clipboard

Print this post

HI Geoff
Then, tried with an old version 5.4 same problem of 5.4.9, with simple board and complex board and this is the output after 264sec of execution (in this example) with Micro 64MX+USB, block in random time. I deduce, and I do not know how using usb and i2c happens the problem.
With CP2102 in console the code it works indefinitely, same code, same module.

264541
ACCEL_XOUT 1656
ACCEL_YOUT 356
ACCEL_ZOUT 17780
TEMP_OUT 21.9
GYRO_XOUT -74
GYRO_YOUT -162
GYRO_ZOUT -100
DI64 0
AN22 4.65
MM.I2C 2
ID 3143

1.1 Degrees (+/-)
1.1 Degrees (0-360)

This is the module (that has its resistances in pullup):

This is the code original by TassyJim:

' TassyJim
' 16 October 2015
' MPU-6050 gyro/accelerometer

'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
Option EXPLICIT
Option BAUDRATE 38400
Dim MPU = &h68 ' MPU-6050 address
Dim temp, accelX, accelY, accelZ, gyroX, gyroY, gyroZ, tilt, accelM, lc
Dim gyro(14)
Dim ID As Integer
SetPin 22,ain
SetPin 2,dout
SetPin 64,din
SetPin 55,dout : Pin(55)=0
Print Chr$(27)+"[2J" ' VT100 CLS

I2C OPEN 100,500,PU
I2C WRITE MPU,0,2,&h6B,0 'wake up the MPU-6050
If MM.I2C = 0 Then
Timer=0
ID=0
Do
I2C WRITE MPU,1,1,&h3B 'Reset memory pointer.
I2C READ MPU,0,14,gyro(1) 'Read 14 bytes
accelX=sint16(gyro(1)*256+gyro(2))
accelY=sint16(gyro(3)*256+gyro(4))
accelZ=sint16(gyro(5)*256+gyro(6))
temp=sint16(gyro(7)*256+gyro(8))/340+36.53
gyroX=sint16(gyro(9)*256+gyro(10))
gyroY=sint16(gyro(11)*256+gyro(12))
gyroZ=sint16(gyro(13)*256+gyro(14))
ID=ID+1
accelM=Sqr(accelX*accelX+accelZ*accelZ)

If accelM=0 Then ' avoid divde by zero error
If accelY<0 Then
tilt=-90
Else
tilt=90
EndIf
ElseIf accelZ<0 Then
If accelY<0 Then
tilt= -180 - Deg(Atn(accelY/accelM))
Else
tilt= 180 - Deg(Atn(accelY/accelM))
EndIf
Else
tilt = Deg(Atn(accelY/accelM))
EndIf
If lc>100 Then
Print Chr$(27)+"[2J"
lc = 0
EndIf

Print Chr$(27)+"[1;1H",Timer
Print "ACCEL_XOUT ",accelX
Print "ACCEL_YOUT ",accelY
Print "ACCEL_ZOUT ",accelZ
Print "TEMP_OUT ",Str$(temp,3,1)
Print "GYRO_XOUT ",gyroX
Print "GYRO_YOUT ",gyroY
Print "GYRO_ZOUT ",gyroZ
Print "DI64 ",Pin(64)
Print "AN22 ",Str$(Pin(22)*10,2,2)
Print "MM.I2C ",MM.I2C
Print "ID ",ID
Pin(2)=Not Pin(2)
Print
Print Str$(tilt,4,1),"Degrees (+/-)"
tilt = ((tilt*10+3600) Mod 3600)/10 ' MOD gives the result in integers
'if tilt = 0 then tilt = 360 ' uncomment if you want 360 instead of 0
Print Str$(tilt,4,1),"Degrees (0-360)"
Print Chr$(13)+Chr$(10)
lc=lc+1
Pause 25
Loop
Else
Print "I2C error ",MM.I2C
EndIf
End

Function sint16(x) ' convert to signed 16 bit number
If x>32767 Then
sint16 = x - 65536
Else
sint16 = x
EndIf
End Function
'end

sagt3k

Guru

Joined: 01/02/2015
Location: Italy
Posts: 313

Posted: 07:47pm 30 Mar 2018

Copy link to clipboard

Print this post

Hi Geoff

Then I set autorun, then I tried to connect my board with other configuration and made several tests:
- PIC32USB + USB battery power... I see the led RUN for many times OK
- PIC32USB on PClinux + minicom ... I see the led RUN for 5/10min , after it stops!!
- PIC32USB on ARMlinux + minicom... I see the led RUN after 5/10minutes it stops!!
- PIC32USB on WIN 10 + PUTTY ... I see the led RUN after 2/3minutes it stops!!
- PIC32USB on WIN 7 + PUTTY ... I see the led RUN after 2/3minutes it stops!!
- PIC32USB on WIN XP + PUTTY ... I see the led RUN after 5minutes it stops!!

PIC32 configuration always with MPU6050 + I2C and USB connection

With USB battery power, I connect a PIC32 with an ESP8266 with ESPlink firmware and with my Smartphone with a terminal emulator for 30min many many times.
After I reset the board and retry with this configuration OK !!!
Could it be a USB problem?
Thanks
Antonio

Geoffg

Guru

Joined: 06/06/2011
Location: Australia
Posts: 3292

Posted: 09:33pm 30 Mar 2018

Copy link to clipboard

Print this post

The fact that it works on battery power indicates that it is a power supply issue.

Are you powering your board via the USB connector? That has caused many problems in the past with many people. A USB power supply is often noisy and what is confusing is that the Micromite appears to be working but suffers from intermittent and strange errors. Using a proper power supply (not USB) is the answer.

If you can, switch to a separate lab quality power supply.Edited by Geoffg 2018-04-01

Geoff Graham - http://geoffg.net

TassyJim

Guru

Joined: 07/08/2011
Location: Australia
Posts: 6283

Posted: 03:51am 31 Mar 2018

Copy link to clipboard

Print this post

I can verify the problem with an Explore64 running V5.4.5
I have changed the program a bit to make debugging easier but still can't give any suggestions.
This is the code I am running:

' TassyJim
' 16 October 2015
' MPU-6050 gyro/accelerometer

'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
OPTION EXPLICIT
OPTION BAUDRATE 38400
DIM MPU = &h68 ' MPU-6050 address
DIM temp, accelX, accelY, accelZ, gyroX, gyroY, gyroZ, tilt, accelM, lc
DIM gyro(14)
DIM ID AS INTEGER
DIM errorW , errorR, readtime, readstart

SETPIN 22,AIN
SETPIN 2,DOUT
SETPIN 64,DIN
SETPIN 55,DOUT : PIN(55)=0
PRINT CHR$(27)+"[2J" ' VT100 CLS

I2C OPEN 100,500,PU
I2C WRITE MPU,0,2,&h6B,0 'wake up the MPU-6050
IF MM.I2C = 0 THEN
PAUSE 100
I2C CLOSE
PAUSE 100
TIMER=0
ID=0
DO
I2C OPEN 100,500,PU
PAUSE 10
I2C WRITE MPU,1,1,&h3B 'Reset memory pointer.
errorW = MM.I2C
PAUSE 10
readstart = TIMER
I2C READ MPU,0,14,gyro(1) 'Read 14 bytes
IF MM.I2C = 0 THEN readtime = TIMER - readstart
errorR = MM.I2C
accelX=sint16(gyro(1)*256+gyro(2))
accelY=sint16(gyro(3)*256+gyro(4))
accelZ=sint16(gyro(5)*256+gyro(6))
temp=sint16(gyro(7)*256+gyro(8))/340+36.53
gyroX=sint16(gyro(9)*256+gyro(10))
gyroY=sint16(gyro(11)*256+gyro(12))
gyroZ=sint16(gyro(13)*256+gyro(14))
ID=ID+1
accelM=SQR(accelX*accelX+accelZ*accelZ)
I2C CLOSE
IF accelM=0 THEN ' avoid divde by zero error
IF accelY<0 THEN
tilt=-90
ELSE
tilt=90
ENDIF
ELSEIF accelZ<0 THEN
IF accelY<0 THEN
tilt= -180 - DEG(ATN(accelY/accelM))
ELSE
tilt= 180 - DEG(ATN(accelY/accelM))
ENDIF
ELSE
tilt = DEG(ATN(accelY/accelM))
ENDIF
IF lc>100 THEN
PRINT CHR$(27)+"[2J"
lc = 0
ENDIF

PRINT CHR$(27)+"[1;1H",TIMER
PRINT "ACCEL_XOUT ",accelX
PRINT "ACCEL_YOUT ",accelY
PRINT "ACCEL_ZOUT ",accelZ
PRINT "TEMP_OUT ",STR$(temp,3,1)
PRINT "GYRO_XOUT ",gyroX
PRINT "GYRO_YOUT ",gyroY
PRINT "GYRO_ZOUT ",gyroZ
PRINT "DI64 ",PIN(64)
PRINT "AN22 ",STR$(PIN(22)*10,2,2)
PRINT "MM.I2C W ",errorW
PRINT "MM.I2C R ",errorR
PRINT "I2C R time ",readtime
PRINT "ID ",ID
PIN(2)=NOT PIN(2)
PRINT
PRINT STR$(tilt,4,1),"Degrees (+/-)"
tilt = ((tilt*10+3600) MOD 3600)/10 ' MOD gives the result in integers
'if tilt = 0 then tilt = 360 ' uncomment if you want 360 instead of 0
PRINT STR$(tilt,4,1),"Degrees (0-360)"
PRINT CHR$(13)+CHR$(10)
lc=lc+1

PAUSE 250
LOOP UNTIL MM.I2C > 0
ELSE
PRINT "I2C error ",MM.I2C
ENDIF
END

FUNCTION sint16(x) ' convert to signed 16 bit number
IF x>32767 THEN
sint16 = x - 65536
ELSE
sint16 = x
ENDIF
END FUNCTION
'end

I changed it to close the I2C after each read and stop when the timeout occurs.
It also confirms that the error occurs with the READ, not the WRITE.
The reading before the failed one takes the usual time. ie it is not failing gradually.
Changing the delay between reads from 25 to 250mS made no difference.
Adding a few extra delays between various operations made no difference.

I don't have any devices connected to the Explore64 other than the MPU6050.

It is powered from a separate 5V supply and the same supply for USB and Serial tests.
Using TeraTerm on Windows for all tests.

Using the USB connection, the timeout error can occur anytime, up to 250 seconds in some cases.
Sometimes (but not always), if I try to restart the program immediately, the timeout error occurs immediately. Removing power to the MPU6050 clears the error. So (I think)does waiting for a while.

No failures (yet) when using the serial converter for the console.

I haven't tried any other I2C devices to see if it's just the MPU6050 that has issues.

Jim

VK7JH
MMedit

Page 1 of 2

Print this page