TheBackShed.com

Forum Index : Microcontroller and PC projects : New version of MMBasic (ver 4.2)

Page 1 of 2

Author

Message

Geoffg

Guru

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

Posted: 11:43pm 31 Dec 2012

Copy link to clipboard

Print this post

A new version of MMBasic (ver 4.2) is available for download from http://geoffg.net/maximite.html#Downloads

This is a minor update that fixes a couple of bugs and adds some extra facilities. New is the CHAIN command, the KEYDOWN command/function and support for RS485 and CAN (Controller Area Network).

To avoid adding unwanted complexity to MMBasic I have created a separate version of MMBasic for the DuinoMite and Colour Maximite that supports CAN. You will see it listed on my download web page. Most people, who do not want CAN, can ignore this and download the standard version.

The Change Log and MMBasic Language Manual (included in the update download) details the changes.

BTW - My automatic build process still produces a firmware update for the monochrome version of the UBW32 with 50 I/O pins. When I came out with Colour MMBasic (which also ran on the UBW32) I retired the monochrome version but if someone out there still uses the mono version and wants the 4.2 update for it, send me an email and I will forward it to you.

Geoff

Geoff Graham - http://geoffg.net

aargee
Senior Member

Joined: 21/08/2008
Location: Australia
Posts: 255

Posted: 12:19pm 01 Jan 2013

Copy link to clipboard

Print this post

Thanks, Geoff, for your continuing development of the Maximite.

Happy New Year to you and your family.

- Rob

For crying out loud, all I wanted to do was flash this blasted LED.

ratall
Newbie

Joined: 27/11/2012
Location: Australia
Posts: 12

Posted: 07:37pm 01 Jan 2013

Copy link to clipboard

Print this post

Hi Geoff
Being one of those people who are really easily confused I just want a little clarification.

4.2 (standard) implenents rs485 control on com1:
(A=pin 16, B=Pin 17, tx on(DTE?) = Pin 17)

4.2 (CAN) inplements a full CAN stack(in the controllers h/w) on COM2:( or at least the pins used for COM2: "A=pin D0, A=pin D1')

CAN is based on the electrical specs of RS485 but somehow avoids the need for tx on ?

So if I have a CGCOLORMAX I can use COM1: and the on board Rs485 chip to say be a PTZ camera controller to an analog security system(PELCO ?). but if I want rs232 with full flow control at the same time I am out of luck.

Also here is no way to use Com2: (D0,D1) along with another pin to implement rs485 on COM2:
OR full duplex RS485 using both sets of pins?

Oh RS$*% I think I've confused myself even more now

.

By the the way geoff love your work, thamks a lot

.

R.

Bill.b

Senior Member

Joined: 25/06/2011
Location: Australia
Posts: 226

Posted: 10:45pm 01 Jan 2013

Copy link to clipboard

Print this post

Hi R

The CGCOLORMAXI uses the PIC32MX695F which does not support CAN.

You would require the PIC32MX795F if you require CAN.

Refer to the change log document on Geoff's website.

[quote]
Implemented the CAN (Controller Area Network) module written by John Harding. This
will run on the Colour Maximite and DuinoMite Mega and is a different firmware update to that used for the standard Colour Maximite and DuinoMite. The Colour Maximite must be fitted with the PIC32MX795F512L processor and a separate driver chip will be required (see http://www.thebackshed.com/forum/forum_posts.asp?TID=5249&PN =1). Go to http://geoffg.net/maximite.html#Downloads to download the CAN version.
[/quote]

In the interests of the environment, this post has been constructed entirely from recycled electrons.

MOBI
Guru

Joined: 02/12/2012
Location: Australia
Posts: 819

Posted: 10:52pm 01 Jan 2013

Copy link to clipboard

Print this post

Quote The CGCOLORMAXI uses the PIC32MX695F which does not support CAN

I have just ordered two of the CGCOLORMAXIs in question. I would like to have the CAN facility. I must have misread somewhere but I thought current versions were using the PIC32MX795F.

Oh well, I might have to either change chips (don't like that option) or get a blank board and, you know the rest..or design a home grown clone.

David M.

David M.

Bill.b

Senior Member

Joined: 25/06/2011
Location: Australia
Posts: 226

Posted: 11:29pm 01 Jan 2013

Copy link to clipboard

Print this post

Question for Rod

In ver 2 of the CGCOLORMAXI are you going to use the PIC32MX795f chip so that CAN can be used.

Bill

In the interests of the environment, this post has been constructed entirely from recycled electrons.

ratall
Newbie

Joined: 27/11/2012
Location: Australia
Posts: 12

Posted: 11:49pm 01 Jan 2013

Copy link to clipboard

Print this post

Hi Bill.b

thanks for the reply.

I did already pickup on the fact the CGCOLORMAX1 does not support CAN the questions re- CAN were regarding the software release just for clarification (I also have the Altronics version of the Colour Maximite). Thanks anyway

My current interest is not so much in CAN but in RS485 as I have a potential application to enhance function the of a PTZ camera running over RS485 using PELCO-D protocal and was hoping to get a clear Idea of what can and can't be done with version 4.2 as regards rs485.

You see there are a number of different approaches to this project the easyest to implement(mininal hardware hacks) requires both rs232 with handshaking and as well as rs485.

Using the CGCOLORMAX looking good as it already has an RS485 chip onboard and some space to build other interfaces required.

R.

CircuitGizmos

Guru

Joined: 08/09/2011
Location: United States
Posts: 1425

Posted: 04:51am 02 Jan 2013

Copy link to clipboard

Print this post

The CGCOLORMAX2 will be built using the '795.

-RobertEdited by CircuitGizmos 2013-01-03

Micromites and Maximites! - Beginning Maximite

MOBI
Guru

Joined: 02/12/2012
Location: Australia
Posts: 819

Posted: 11:45am 02 Jan 2013

Copy link to clipboard

Print this post

Is the 795 a direct repacement for the 695 in the CGCOLORMAXI ?

Is the foot print the same and are there any firmware changes needed?

David M.

David M.

MOBI
Guru

Joined: 02/12/2012
Location: Australia
Posts: 819

Posted: 12:16pm 02 Jan 2013

Copy link to clipboard

Print this post

Disregard the previous post, I had a closer read of Geoff's website and my questions are answered.

There is heaps of info out there, just need the time to trawl through it all.

David M.

CircuitGizmos

Guru

Joined: 08/09/2011
Location: United States
Posts: 1425

Posted: 12:34pm 02 Jan 2013

Copy link to clipboard

Print this post

So that others know:

" Is the 795 a direct repacement for the 695 in the CGCOLORMAXI ? "

Yes - the '795 adds CAN.

" Is the foot print the same and are there any firmware changes needed? "

There is a download for CAN support.

The footprint is the same as long as you pick the same package size.

Micromites and Maximites! - Beginning Maximite

Geoffg

Guru

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

Posted: 01:59pm 02 Jan 2013

Copy link to clipboard

Print this post

ratall said Hi Geoff
Being one of those people who are really easily confused I just want a little clarification.

4.2 (standard) implenents rs485 control on com1:
(A=pin 16, B=Pin 17, tx on(DTE?) = Pin 17)

4.2 (CAN) inplements a full CAN stack(in the controllers h/w) on COM2:( or at least the pins used for COM2: "A=pin D0, A=pin D1')

CAN is based on the electrical specs of RS485 but somehow avoids the need for tx on ?

So if I have a CGCOLORMAX I can use COM1: and the on board Rs485 chip to say be a PTZ camera controller to an analog security system(PELCO ?). but if I want rs232 with full flow control at the same time I am out of luck.

Also here is no way to use Com2: (D0,D1) along with another pin to implement rs485 on COM2:
OR full duplex RS485 using both sets of pins?

Oh RS$*% I think I've confused myself even more now

.

By the the way geoff love your work, thamks a lot

You do sound confused

To clarify:
Yes, 4.2 (standard) implements RS485 control on COM1: (as does 4.2 with CAN).
CAN has nothing to do with COM2: and does not interfere with it.
Yes, RS485 control and flow control on COM1: are mutually exclusive.
Sorry, no there is no RS485 control or flow control on COM2:

The version with CAN should work exactly the same as the version without (ie, you do not loose any features when you use the CAN version). I made a separate version of 4.2 with CAN because the extra CAN code eats into the space available for drive A: (the internal flash drive) and because the extra documentation that came with CAN would only confuse most users.

BTW huge thanks to John Harding for writing the CAN code. He did a great job and it was very easy to integrate.

Geoff

Geoff Graham - http://geoffg.net

TinkersALot
Regular Member

Joined: 20/11/2012
Location: United States
Posts: 72

Posted: 03:28pm 02 Jan 2013

Copy link to clipboard

Print this post

CircuitGizmos said The CGCOLORMAX2 will be built using the '795.

-Robert

Wondering: Is it possible to have that board version be stuffed with all header pins and .100" headers as well (or available as an order option). I, for one, would pay a few $ more for a board that did not need me to do one drop of soldering.

ratall
Newbie

Joined: 27/11/2012
Location: Australia
Posts: 12

Posted: 03:39pm 02 Jan 2013

Copy link to clipboard

Print this post

Hi Geoff
thanks for the clarification.

Part of my problem I think was for some unknown reason this grey squishy thing I call a brain refused to recognise that CAN is on D4,D5 not D0,D1. Then when I found stuff on the internet claiming CAN was based on 485s physical layer(which I now suspect is incorrect) everything sort of got cross linked in my head resulting in a major brain fart.

anyway enough of my excuses.

Thanks for setting me right.

R.

CircuitGizmos

Guru

Joined: 08/09/2011
Location: United States
Posts: 1425

Posted: 03:41pm 02 Jan 2013

Copy link to clipboard

Print this post

TinkersALot said Wondering: Is it possible to have that board version be stuffed with all header pins and .100" headers as well (or available as an order option). I, for one, would pay a few $ more for a board that did not need me to do one drop of soldering.

That is certainly a possibility. I'll consider it as an order option.

-RobertEdited by CircuitGizmos 2013-01-04

Micromites and Maximites! - Beginning Maximite

ratall
Newbie

Joined: 27/11/2012
Location: Australia
Posts: 12

Posted: 05:33pm 02 Jan 2013

Copy link to clipboard

Print this post

quick question re interupts and chaining.

if I have an interrupt pointing to label ComIntHand1 in one program

REM MASTER Control

OPEN "COM1:9600, 32, DE ,ComIntHand1" AS #3
.....
CHAIN "NIGHTMODE.bas"
...
ComIntHand1:
...
IRETURN

then I chain to program another

REM NIGHTMODE Control
.....

ComIntHand1:
...
IRETURN

with a label ComIntHand1 will the the interrupt now point to the new version of ComIntHand1 or will it get confused.

R.

Geoffg

Guru

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

Posted: 06:28am 03 Jan 2013

Copy link to clipboard

Print this post

Ah, good point. The interpreter will get confused so any open interrupts must be closed before CHAINing. In the next version I will make sure that all interrupts are automatically closed.

Geoff Graham - http://geoffg.net

ratall
Newbie

Joined: 27/11/2012
Location: Australia
Posts: 12

Posted: 10:40am 03 Jan 2013

Copy link to clipboard

Print this post

Geoffg said Ah, good point. The interpreter will get confused so any open interrupts must be closed before CHAINing. In the next version I will make sure that all interrupts are automatically closed.

So it would not be possible to have the interpreter dynamically relink the interrupt handlers on the basis of same named labels. The interpreter must do some sort of label resolution search on loading a program.

I can understand it may require carrying forward additional information such as original label names.

I was wondering if an extra option could added when interrupts are set up to specify that it needs to be resilient thru chains. The label could be stored at that point and re-resolved during the chain.

It also could then be errored in a meaningfully if a corresponding label does not exist in the chained program.

If the option is not set the interrupt could be closed possibly with a suitable message.

Another way may be to create an option of a persistant(static) code block that is preserved between chains and require all interupt handling be placed within this block.

The code would have to be bracketed some how. May be as a block at the start of the program.

I realise it would make the load point change for the chain but when the block is defined maybe the load point could be set then.

The programmer would have to be carefull to define only the static area in the primary program and be aware of its (hidden?) persistance in the chained programms.

Also stopping and saveing a chained program could lead to accidental duplication of the static code block so it may be an idea to find a way to not load the static block if specified in a program loaded via the CHAIN command.

Of course I don't know if any of the above suggestions are practical.

I do believe it would be a good idea no matter how the situation is handled to produce some sort of warning when interupts are forced down.

If you do force the interupts closed will you be closing the associated ports and resetting pins and such.

R.

Geoffg

Guru

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

Posted: 10:43pm 03 Jan 2013

Copy link to clipboard

Print this post

The problem is that MMBasic keeps pointers to the interrupt locations in the BASIC program, (for speed) and these will be invalid when a new program is CHAINed in. It is possible (in theory) for MMBasic to also store the label and/or line number of every interrupt (or specific interrupts with an option) in case a CHAIN command is used and recalculate them following a CHAIN but that will consume extra memory.

Keeping a static block of code in place is even more complex and would be a nightmare to implement.

This is one of these things that has a diminishing rate of return. If only 20% of users use the CHAIN command and only 20% of them want to keep an interrupt open then that means just 4% of users would find all this complication and extra documentation useful.

When interrupts are forced close by the CHAIN command the input settings will remain in force. It is very easy for the 4% of users who want to retain interrupts to modify their CHAINed program to reset the interrupts by using SETPIN, et al. The only exception would be users who want to keep serial or I2C interrupts open but they would represent just 20% of the above (ie, 0,8% of users).

GeoffEdited by Geoffg 2013-01-05

Geoff Graham - http://geoffg.net

Geoffg

Guru

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

Posted: 10:57pm 03 Jan 2013

Copy link to clipboard

Print this post

ratall said ... resulting in a major brain fart

I just love this phrase, I am going to remember it for future use (it happens to me often).

GeoffEdited by Geoffg 2013-01-05

Geoff Graham - http://geoffg.net

Page 1 of 2

Print this page