TheBackShed.com

Forum Index : Microcontroller and PC projects : Micromite and Micromite Plus Beta 23

Page 3 of 5

Author

Message

Chris Roper
Senior Member

Joined: 19/05/2015
Location: South Africa
Posts: 280

Posted: 01:15am 16 Aug 2015

Copy link to clipboard

Print this post

Another thought on Name Disambiguation that came to me as I was labelling chips:

MM = MaxiMite
MM150 = Micromite V1
MM170 = Micromite V2
MM470 = MicroMite +

Cheers
Chris

http://caroper.blogspot.com/

cosmic frog
Guru

Joined: 09/02/2012
Location: United Kingdom
Posts: 302

Posted: 01:29am 16 Aug 2015

Copy link to clipboard

Print this post

Why not just call it what it is?
Maximite=Maximite
Micromite=Micromite
All this mm+ and mmii is just confusing and makes you want to give up sometimes.
Just call it what it is.

Dave.

Chris Roper
Senior Member

Joined: 19/05/2015
Location: South Africa
Posts: 280

Posted: 01:50am 16 Aug 2015

Copy link to clipboard

Print this post

cosmic frog said Why not just call it what it is?
Maximite=Maximite
Micromite=Micromite
All this mm+ and mmii is just confusing and makes you want to give up sometimes.
Just call it what it is.

Dave.

Because there would still be confusion between the 3 current flavours of MicroMite and anyway we are all electronics/computer people we love our Acronym's

Also, because I have them as loose chips floating around the bench, I need to be able to label them too and with my eyesight trying to write "MicroMite Release II Beta 23" on a 28 Pin SPDIP Package is nigh on impossible. Hence my Chips are labelled as MM150, MM170 and MM170b (For the Beta versions).

EDIT:

I also use PIC32MX Devices with ChipKIT bootloaders in various flavours so they are labelled as:

BB250U - ChipKIT Bootloader with USB Console
BB250S - ChipKIT Bootloader with Serial Console - USB Host
BB150S - ChipKIT Bootloader with Serial Console
BB170S - ChipKIT Bootloader with Serial Console

That way I can distinguish between the different MicroMites and ChipKIT's if the end up as a pile of, otherwise, identical Chips

I have not seen much talk of ChipKIT here in the Back Shed though.Edited by Chris Roper 2015-08-17

http://caroper.blogspot.com/

matherp
Guru

Joined: 11/12/2012
Location: United Kingdom
Posts: 10180

Posted: 02:04am 16 Aug 2015

Copy link to clipboard

Print this post

Quote Why not just call it what it is?
Maximite=Maximite
Micromite=Micromite

The problem is that titles on the BB are very limited in characters but it is important to let prospective readers know what the thread is about.

I've recently been using:

MM2 for the MX170
MM+ for the MX470

as I don't work on either the Maximite or original Micromite

For titles I'd be happy with:

MM = MaxiMite
uM = Original Micromite (MX150)
uM2 = Micromite MKII (MX170)
uM+ = MicroMite + (MX470)
uM2(+) = either MX170 or MX470

Obviously in the text we can be more specific where required (e.g. minimum firmware version numbers)

Gizmo: is there any way you could let the original thread posters change the title after the fact to be more consistent?
Edited by matherp 2015-08-17

Greg Fordyce
Senior Member

Joined: 16/09/2011
Location: United Kingdom
Posts: 153

Posted: 01:37am 26 Aug 2015

Copy link to clipboard

Print this post

On page 25 of the MicroMite Advanced Features manual there is a schematic showing the connections required for a ps2 keyboard. I think it would be a good idea to add the uM+ pin numbers to the schematic.

Geoffg

Guru

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

Posted: 06:07am 26 Aug 2015

Copy link to clipboard

Print this post

Thanks, I will have a look at that. The issue might be that the pin numbers will vary between the 64-pin and 100-pin implementations.

Geoff Graham - http://geoffg.net

Greg Fordyce
Senior Member

Joined: 16/09/2011
Location: United Kingdom
Posts: 153

Posted: 09:28am 30 Aug 2015

Copy link to clipboard

Print this post

A couple of small typos spotted in the Advanced Features manual.

Page 10;

However many buzzers require more that this so a transistor might be necessary to buffer the Micromite Plus output and drive the buzzer.

should read;

However many buzzers require more than this so a transistor might be necessary to buffer the Micromite Plus output and drive the buzzer.

and on page 27;

OPTION LCDPANEL SSD1963_5, L, 4

This will configure the display as a 5" LCD panel in the landscape orientation and the default font will be font 2

should read;

OPTION LCDPANEL SSD1963_5, L, 4

This will configure the display as a 5" LCD panel in the landscape orientation and the default font will be font 4

Greg Fordyce
Senior Member

Joined: 16/09/2011
Location: United Kingdom
Posts: 153

Posted: 12:55am 31 Aug 2015

Copy link to clipboard

Print this post

Starting on page 27 of the Advanced features manual is an example of using the Explore 64 and connecting it to a SSD1963 display.

At the top of the page it shows setting up the sd card by issuing the command OPTION SDCARD 12. Since the Explore 64 board uses pin 14 as the sd Card Detect the command should read OPTION SDCARD 12, 14. A user could configure the card using the first command and then try and use pin 14 for something else only to have weird problems due to pin 14 being shorted to ground without a card being inserted.

This also means that further down the page when it is suggested to connect pin 14 to T_CS on the SSD1963 display you have a conflict. I would suggest changing all references of pin 14 to pin 18 except of course for the above sd card configuration.

GregEdited by Greg Fordyce 2015-09-01

MMAndy
Regular Member

Joined: 16/07/2015
Location: United States
Posts: 91

Posted: 03:13am 31 Aug 2015

Copy link to clipboard

Print this post

I believe this is where I should put my "power save request" for the MM+.

By far, the most power consumption, on our Embedded BASIC Laptop
is the TFT LED backlight. Reducing this power consumption is priority
one to allow extended battery usage and for Lithium battery (capacity) reduced cost.

If "OPTION LCDPANEL" command is used, then only allow an unused function key to adjust the auto backlight timeout/brightness when in the MM+ editor mode only.
Another name for this would be a screen blanker in the full screen editor mode.
This would require a firmware enhancement?

Power Consumption MM+ / keyboard, TFT 7" display:

MicroMite+ running: 77 ma. - 80 ma. @ 100 Mhz
Keyboard: 100 ma. @ 5V
7" Display Electronics: 100 ma. @ 3.3V
7" Display Backlight: 330-620 ma. @5V 10% brightness 133 ma. and 100% 433 ma.

Greg Fordyce
Senior Member

Joined: 16/09/2011
Location: United Kingdom
Posts: 153

Posted: 10:39am 31 Aug 2015

Copy link to clipboard

Print this post

CircuitGizmos said Would it be possible to have OPTION LIST that shows all options?

Example:

> OPTION LIST
LCDPANEL ILI9341 RL 1 2 3
TOUCH 12
SDCARD DISABLED

>

I like this idea but I fear the list wouldn't all fit on one screen, there are a lot of options! How about making the option settings available as MM read only variables. For example MM.AUTORUN 0 = off and 1 = on or MM.AUTORUN$ "OFF" or "ON".

MMAndy
Regular Member

Joined: 16/07/2015
Location: United States
Posts: 91

Posted: 02:39pm 03 Sep 2015

Copy link to clipboard

Print this post

Another "power save" firmware request ...

When the MM+ is setup with a keyboard/TFT display and power is first applied, the backlight brightness, I believe, goes to 100%. This is not an issue running off of AC mains but running off a Lithium battery pack it sucks the joules out of the battery pack at a very high rate. If somehow this 100% backlight is reduced, on power up, to a default of 10 - 50% then this would increase the rundown time of the Lithium battery pack. With editor "screen blanking" (above) it's very possible to run the Embedded BASIC Laptop for a week without re-charging!Edited by MMAndy 2015-09-05

Geoffg

Guru

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

Posted: 05:57pm 03 Sep 2015

Copy link to clipboard

Print this post

Andy, sorry for not replying earlier but I have been trying to figure out how to handle this type of situation. Essentially you are asking for computer type features in something that was intended to be a controller.

Not everyone wants the screen to start at 50% and I am reluctant to add yet another option. Similarly a function key that only works in the editor seems to be a strange way to control the brightness in a controller. And they are just the first of a huge list of features that a computer might require.

For the moment I think that an external backlight control would be the best way to go (ie, a 555 timer with a pot controlling its duty cycle).

As I said in another thread, perhaps I should create a computer version of the MM+. I will look at this after the current MM+ beta has finished.

Geoff Graham - http://geoffg.net

JohnS
Guru

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

Posted: 07:52pm 03 Sep 2015

Copy link to clipboard

Print this post

Would it not be fairly simple to request the MMBasic sources and make a small change for that particular wish?

(Or could an auto-run program do the setting...)

John

Geoffg

Guru

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

Posted: 12:11am 04 Sep 2015

Copy link to clipboard

Print this post

The source is in a huge mess at this time (because the code is in beta) and I am reluctant to release it in this state. My normal routine is to spend a couple of days cleaning up the source ready for release when the beta test has finished.

I have had another idea for satisfying one of Andy's request (set default brightness). At this time I am thinking of something like a command called LIBRARY SAVE. This will take whatever is in memory (BASIC code and/or CFunctions) and make it permanent in flash. This means that it will not show with LIST and will not be deleted by NEW but it will be available to any program subsequently loaded into flash. The hex code of CFunctions will also be stripped out so that flash space is not wasted as in the current scenario. LIBRARY DELETE will delete the code previously saved.

One of the features of this is that somehow a section of this code could be designated to run at boot or run and that code could set options like the brightness.

More thinking required...
Edited by Geoffg 2015-09-05

Geoff Graham - http://geoffg.net

MicroBlocks

Guru

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

Posted: 12:16am 04 Sep 2015

Copy link to clipboard

Print this post

I like the idea of Library Save/Delete. More space efficient and you could then load 'drivers' to be used from basic.

Microblocks. Build with logic.

Geoffg

Guru

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

Posted: 12:22am 04 Sep 2015

Copy link to clipboard

Print this post

TZAdvantage said you could then load 'drivers' to be used from basic.

Exactly - and they could be BASIC subroutines or CFunctions.

Geoff Graham - http://geoffg.net

matherp
Guru

Joined: 11/12/2012
Location: United Kingdom
Posts: 10180

Posted: 12:51am 04 Sep 2015

Copy link to clipboard

Print this post

Quote At this time I am thinking of something like a command called LIBRARY SAVE. This will take whatever is in memory (BASIC code and/or CFunctions) and make it permanent in flash. This means that it will not show with LIST and will not be deleted by NEW but it will be available to any program subsequently loaded into flash. The hex code of CFunctions will also be stripped out so that flash space is not wasted as in the current scenario. LIBRARY DELETE will delete the code previously saved.

Geoff

As you may suspect I would be a huge supporter of this. On the uM2 this is of course even more important then on the MM+.

If this causes any space problems on the uM2 then it would be fine to strip out in-built support for the ST7735 and ILI9163 displays as these could then be easily loaded as LIBRARY drivers.

Chris Roper
Senior Member

Joined: 19/05/2015
Location: South Africa
Posts: 280

Posted: 01:09am 04 Sep 2015

Copy link to clipboard

Print this post

matherp said If this causes any space problems on the uM2 then it would be fine to strip out in-built support for the ST7735 and ILI9163 displays as these could then be easily loaded as LIBRARY drivers.

The same holds true for the MM+, in fact I would strip out all display drivers, fonts etc. On the MM+ to maximise memory, for Controller applications.
The User can then load only the display type needed, possibly as CFunctions.

Cheers
Chris

http://caroper.blogspot.com/

twofingers

Guru

Joined: 02/06/2014
Location: Germany
Posts: 1566

Posted: 01:43am 04 Sep 2015

Copy link to clipboard

Print this post

Chris Roper said

I support this idea too!
Who knows which type of displays or sensors are tomorrow available?
A LIBRARY with a AUTOEXEC function would be fine.
And perhaps it means that more users share their ideas.

Michael

causality ≠ correlation ≠ coincidence

matherp
Guru

Joined: 11/12/2012
Location: United Kingdom
Posts: 10180

Posted: 02:02am 04 Sep 2015

Copy link to clipboard

Print this post

Quote in fact I would strip out all display drivers,

I think it is important to have one driver in each version so that graphics are immediately accessible for newcomers.

SSD1963 for the MM+
ILI9341 for the uM2

and of course on the MM+, console functionality is completely dependent on the SSD1963

Page 3 of 5

Print this page