TheBackShed.com

Forum Index : Microcontroller and PC projects : Micromite V4.5D for the MX150 and MX170

Page 2 of 3

Author

Message

G8JCF

Guru

Joined: 15/05/2014
Location: United Kingdom
Posts: 676

Posted: 01:39pm 02 Sep 2014

Copy link to clipboard

Print this post

What actual chip are you running MMBasic on ?

Try this on your uMite

Print "MMBasic version=";MM.ver

print "Platform=";MM.device$

print "Device ID=";
for I=3 to 0 step -1
print hex$(peek(&hbf80,&hf220+i));
next
Print

Print "Memory"

memory

when run on a 28 pin 170F the output is

> RUN
MMBasic version= 4.0504
Platform=Micromite
Device ID=2661053
Memory
Flash:
0K ( 0% of 58K) Program (9 lines)
0b ( 0% of 1536b) 0 Saved Variables

RAM:
0K ( 0%) 1 Variables
0K ( 0%) General
54K (100%) Free
>

when run on a standard 28 pin 150F the output is

RUN
MMBasic version= 4.0503
Platform=Micromite
Device ID=14D06053
Memory
Flash:
0K ( 0% of 20K) Program (9 lines)
0b ( 0% of 1536b) 0 Saved Variables

RAM:
0K ( 0%) 1 Variables
0K ( 0%) General
22K (100%) Free
>

73

Peter

The only Konstant is Change

Geoffg

Guru

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

Posted: 01:47pm 02 Sep 2014

Copy link to clipboard

Print this post

Thanks Peter and Rob (who emailed me) for confirming that the MX170 28-pin chip works. I will post the upgrade on my website ASAP.

G8JCF said have you increased the number of user defined functions/subs up from 32 ?

No, it is still 32. Because so many people were waiting on the 170 version my intention was just to get it out the door with the minimum of delay.

I now plan to go through the interpreter and tweak it to take more advantage of the 170's increased memory and add some new features. I have quite a few items on my todo list including 64 bit integers (but no guarantees there). This will take at least a couple of months and then I can release the new 170 version as V4.6.

Geoff

Geoff Graham - http://geoffg.net

Grogster

Admin Group

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

Posted: 02:28pm 02 Sep 2014

Copy link to clipboard

Print this post

Does that mean you have to re-write for Harmony or do you have another clever idea up your sleeve to get around that?

Smoke makes things work. When the smoke gets out, it stops!

G8JCF

Guru

Joined: 15/05/2014
Location: United Kingdom
Posts: 676

Posted: 02:52pm 02 Sep 2014

Copy link to clipboard

Print this post

@Geoff

but I do understand the rationale.

Thanks for getting 4.5D released so quickly despite the (Microchip) obstacles !

Peter

The only Konstant is Change

JohnS
Guru

Joined: 18/11/2011
Location: United Kingdom
Posts: 4071

Posted: 09:11pm 02 Sep 2014

Copy link to clipboard

Print this post

A quick note to anyone still worried about damaging a PIC32 during programming.

Unlike earlier PICs, PIC32 are flashed using only low voltages. There's no Vpp at 13V or the like. It's all 3V3 logic levels.

The danger of damage would be using an old-style circuit - so don't.

ICSP is a variant of JTAG / EJTAG, and just drives a number of state machines.

Unless you're using an OTP part (who is?), if programming fails you just erase & do it again.

JohnEdited by JohnS 2014-09-04

ajkw
Senior Member

Joined: 29/06/2011
Location: Australia
Posts: 290

Posted: 11:04pm 09 Sep 2014

Copy link to clipboard

Print this post

re DS18B20 & 4.5D

Geoff,

Why does a connection error with a DS18B20 have to cause a inglorious return to the command prompt?

I would have thought a returned value of -127 (or other out of range number) can be discretely tested for and dealt with within a running program instead to having to try catch and somehow deal with with a watchdog.

Anthony.

MicroBlocks

Guru

Joined: 12/05/2012
Location: Thailand
Posts: 2209

Posted: 12:07am 10 Sep 2014

Copy link to clipboard

Print this post

Would it be hard to have a ON ERROR NEXT available in MMBasic?

I used that a lot in (GW)Basic when working with floppy files (like current SD card access), serial communication (Network) etc.
Every error that occurs is then captured and execution continues on the next statement.
An Err variable then holds an Error code so you would be able to decide what to do.

Dropping into command mode has only one choice and that is using a watchdog to restart the program.
Often errors can be handled more gracefully.

What do you think Geoff, would that be possible?

Microblocks. Build with logic.

G8JCF

Guru

Joined: 15/05/2014
Location: United Kingdom
Posts: 676

Posted: 04:08am 10 Sep 2014

Copy link to clipboard

Print this post

Option Error Resume | Break

The only Konstant is Change

kiiid

Guru

Joined: 11/05/2013
Location: United Kingdom
Posts: 671

Posted: 08:58am 10 Sep 2014

Copy link to clipboard

Print this post

I am going to put some ice in the hot water. Don't jump too enthusiastically into buying lot 170s. There is a 190 (and respectively 290) coming out. In general those are the same crystal as 370/470 with reduced number of pins...

http://rittle.org

--------------

mindrobots
Newbie

Joined: 21/05/2014
Location: United States
Posts: 32

Posted: 12:44pm 10 Sep 2014

Copy link to clipboard

Print this post

The good news is, none of the old ones stop working just because a new chip comes out!

G8JCF

Guru

Joined: 15/05/2014
Location: United Kingdom
Posts: 676

Posted: 12:56pm 10 Sep 2014

Copy link to clipboard

Print this post

@kiiid

Any links to the info about the 190's please ?

Peter

The only Konstant is Change

viscomjim
Guru

Joined: 08/01/2014
Location: United States
Posts: 925

Posted: 07:50am 11 Sep 2014

Copy link to clipboard

Print this post

@mindrobots... I agree, I'm still using those "old" 150 chips... They still work great!!!!

Oldbitcollector

Senior Member

Joined: 16/05/2014
Location: United States
Posts: 172

Posted: 05:51pm 11 Sep 2014

Copy link to clipboard

Print this post

Geoffg said It does not fix the issues with the I2C protocol - that will take more time.

Geoff,

I'm using the I2C protocol pretty extensively in my current project. Would you take a moment to expand on what issues affect the I2C protocol and what effects the fixes will have on them? I'm not sure if I have encountered flaws or not, as I might have simply accepted a bug as normal behaviour from the Micromite being that I have control over the slave side of the connection as well. Should I expected surprises here?

Thanks
Jeff

My Propeller/Micromite mini-computer project.

Geoffg

Guru

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

Posted: 09:15pm 11 Sep 2014

Copy link to clipboard

Print this post

This is what I have in my "bugs database". I have not verified the issue(s):

http://www.thebackshed.com/forum/forum_posts.asp?TID=6527&PN =1&TPN=2

If you stop the slave with ctrl+C without issuing the I2C SLAVE CLOSE, the master does not receive an error. MM.I2C = 0.
If you do issue the I2C SLAVE CLOSE command, the master will correctly see an error. MM.I2C = 1.
If you stop the slave from listening with I2C SLAVE CLOSE and then restart listening with I2C SLAVE OPEN, there is
'garbage' in the slave buffer. This will happen even if you stop the master, pause the slave listening, restart
listening and then restart the master. The buffer gets out of step without any I2C activity on the bus.

See also: http://www.thebackshed.com/forum/forum_posts.asp?TID=6599&PN =1

Geoff

Geoff Graham - http://geoffg.net

Geoffg

Guru

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

Posted: 09:59pm 11 Sep 2014

Copy link to clipboard

Print this post

TZAdvantage said Would it be hard to have a ON ERROR NEXT available in MMBasic?
What do you think Geoff, would that be possible?

This has some issues and needs thinking through.

For a start, when an error is encountered the interpreter is often deep in some logic tree with no obvious answer or way out... this is why the error is thrown. How can the interpreter continue when it is in a non logical state?

It would be better if ON ERROR NEXT only applied to I/O commands/functions but I can still see issues. The DISTANCE command and PULSEIN function do not abort on an error so the only others that this might apply to are the DS18B20 function and RTC command (all the others cannot detect if the hardware is missing). In the case of the DS18B20() function I would have thought that not having the sensor connected would be a serious sort of error. Why would you want to ignore it? What about the RTC command - should it pretend as if nothing happened if the PCF8563 is not found?

I will add ON ERROR NEXT (or something similar) to my list of possible enhancements but I am really searching for a logical and sensible way of handling the issue.

I am beginning to think that the original suggestion of DS18B20() returning a non valid reading would be the simplest approach.

Geoff

Geoff Graham - http://geoffg.net

ajkw
Senior Member

Joined: 29/06/2011
Location: Australia
Posts: 290

Posted: 11:06pm 11 Sep 2014

Copy link to clipboard

Print this post

Quote In the case of the DS18B20() function I would have thought that not having the sensor connected would be a serious sort of error. Why would you want to ignore it?

Geoff,

In my case am not saying I would ignore the error, if I can test the result of a DS18B20 read and find the value is indicating a error then I can make an alert or take other action instead of staring at a command prompt.

Perhaps let me put it this way, if a temp sender in the car engine goes bad the car computer doesn't shut itself and the engine down, it changes the fuel injection mapping to a default safe mode and displays a light on the dash.

Cheers,
Anthony.

robert.rozee
Guru

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

Posted: 04:00am 12 Sep 2014

Copy link to clipboard

Print this post

Geoffg said
I am beginning to think that the original suggestion of DS18B20() returning a non valid reading would be the simplest approach.
Geoff

this could break some existing code that expects all returned values to be valid.

how about instead expanding the function to include an optional error flag:

DS18B20( pin [, error] )

where 'error' is returned set to 0 if the function has found the sensor and extracted the temperature from it, and returned set to 1 if there was an error. if the second parameter is not present and an error occurs, then as with earlier versions terminate the program.

in applications like dataloggers, there may be occasions where it is desirable to carry on when sensors drop out, are destroyed, or are simply not plugged in.

rob :-)

Edited by robert.rozee 2014-09-13

ajkw
Senior Member

Joined: 29/06/2011
Location: Australia
Posts: 290

Posted: 11:07am 12 Sep 2014

Copy link to clipboard

Print this post

Rob,

The change in 4.5D did itself break existing code.

Anthony.

TassyJim

Guru

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

Posted: 11:51am 12 Sep 2014

Copy link to clipboard

Print this post

Geoffg said In the case of the DS18B20() function I would have thought that not having the sensor connected would be a serious sort of error. Why would you want to ignore it? What about the RTC command - should it pretend as if nothing happened if the PCF8563 is not found?
....

I am beginning to think that the original suggestion of DS18B20() returning a non valid reading would be the simplest approach.

Geoff

I have a monitoring system with 5 DS18B20's on long(ish) leads. If a mouse chews through on of the leads (a strong possibility), I want the system to keep monitoring the remaining sensors and report an error on the faulty one.
A non-valid return value would be the easiest for me to live with and is consistent with other types of sensor. The RTC is not so critical as it should be there all the time once the hardware is completed.

Jim

VK7JH
MMedit

Geoffg

Guru

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

Posted: 05:52pm 12 Sep 2014

Copy link to clipboard

Print this post

OK, I agree. In the next release I will change the DS18B20() function to return a non valid reading on an error. The RTC comand can stay the way it is.

Geoff

Geoff Graham - http://geoffg.net

Page 2 of 3

Print this page