 Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me. |
Forum Index : Microcontroller and PC projects : Micromite and Micromite Plus Beta 36
  Page 3 of 3 |
|||||
| Author | Message | ||||
MicroBlocks Guru  Joined: 12/05/2012 Location: ThailandPosts: 2209 |
A nice example of what we both worked on is the keyboard for the uMite. If it needed a feature that was only available in a 64 or 100 pin would it then still be as interesting to do. The chip cost more, takes more room is more difficult to solder needs a crystal etc. For strictly embedded purposes i would prefer having more features. Because an embedded solution very very often ends up in a small box and is just being used. With the internal editor never being used. Once you start combining two chips to form a computer like a uMite and a VT100, you could ask the question why is the editor not in the VT100 chip? What Jim mentioned using the phone as a Terminal, is that more to see the input/output of the program or editing it. Because editing can still be done in a text editor and using xmodem to transfer it. What do you do when using the terminal and internal editor to change the program. You don't transfer it to your pc so it can be saved? And if you do save it on your pc is it then not easier to edit it there, using GIT for source control, file history to be able to go back when something does not work etc. Using the internal editor is very limited and using it is actually detrimental when programs start to get a bit bigger. Is the 'best practice' to use the internal editor? I hit the limit of that after a few days (on the color maximite). I have done a few workshops using the micromites (28 pinners) and for a new person starting with nothing the best results we get is with using mmedit. You can program even without having a chip working. It connects easier, requires very little setup and just works. One click to send the program and run it. If you hit an error you are guided to the line that created the error, etc. Microblocks. Build with logic. |
||||
kiiid Guru Joined: 11/05/2013 Location: United KingdomPosts: 671 |
I value very much the presence of the internal editor. It is a distinct feature which make the system fully independent from the outside world. Sure, it can be improved a lot (especially from point of view of speed when working with larger sources), but it is there for a purpose, and should stay there. Probably the ideal option would be if it can be irreversibly 'uninstalled' thus freeing up the taken flash. That will make everyone happy I think. http://rittle.org -------------- |
||||
atmega8 Guru Joined: 19/11/2013 Location: GermanyPosts: 724 |
And Linux user? |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2442 |
matherp has just pointed out to me that unfortunately the PIC32's ADC can only use AVcc or an external source as the reference voltage. alas, the 1.2v bandgap can not be used - i had not been aware of this. the earlier approach of using PIN(0) as a means of reading the bandgap's voltage relative to AVcc was a less than optimal solution, as doing so effectively reduced the resolution of readings by a couple of bits. cheers, rob :-) |
||||
Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3292 |
As you and matherp have pointed out the internal bandgap has problems when used as a reference so that is not practicable. I have plans for an option to use an external voltage as the reference but I am not sure when it will appear. As it happens I have just finished adding this to the next beta due out tomorrow. This one has come up before and while I understand that you are keen to see it go many people like the editor and rely on it - so I prefer to see it remain. Having two versions (with and without the editor) is not a practical alternative, it would just confuse newcomers and it is a real pain to maintain and test multiple versions with different feature sets - I am already feeling it with the MX170 and MX470 versions and I would not want to make it worse. Geoff Geoff Graham - http://geoffg.net |
||||
| MicroBlocks Guru Joined: 12/05/2012 Location: ThailandPosts: 2209 |
How is having to use a PC with teraterm 'independant' from the outside world. I have only my own observations and my own use as a reference so my opinion is based on that. What i see others do, at a few workshops i organized, is that once they have used MMEdit is that they never ever use the internal editor anymore. For me it is the same. For insdtant feedback the command prompt is invaluable, even for just small test just toggling a pin to see if the connections are right it is great. For a Maximite or CMM with a keyboard and screen it is also great because then it is really an independent system. That will probably also be true for the new MM+. But specific for the uMite (150 and 170) i could live without an internal editor without having any less functionality or ease of use. Microblocks. Build with logic. |
||||
| MicroBlocks Guru Joined: 12/05/2012 Location: ThailandPosts: 2209 |
I think the 'hurt' will become more as the versions of the MX170 and MX470 are getting more far apart because the lack of flash in the 170. Again only my personal opinion is that i think it would be easier to maintain and offer more functionality to both MX170 and MX470 if the MX170 has a bit more flash available. When i read the manual now it is works on MM+ only, unsupported on the MX170 etc. This will probably grow in the future. The other option is that MX170 has no internal editor and the MX470 has. The rest is equal. This would then increase the compatibility between the two as programs could still run on both. I am happy how everything is anyway, it is just that i see very difficult decisions in the near future with what to keep and what to leave out. Microblocks. Build with logic. |
||||
Grogster Admin Group  Joined: 31/12/2012 Location: New ZealandPosts: 9610 |
Dare I say it? OPTION EDITOR DISABLE? Not sure if that is even possible. Smoke makes things work. When the smoke gets out, it stops! |
||||
| WhiteWizzard Guru Joined: 05/04/2013 Location: United KingdomPosts: 2944 |
But that will still occupy memory space won't it?? As kiid suggested, something like OPTION EDITOR REMOVE could be better (based on permanent removal). If you wanted the editor back then you would simply reload firmware. The fact there has been several posts about this topic just go to show there is no one simple answer that satisfies everyone's needs (but EDITOR REMOVE is a solution that could meet most peoples requirements IF it were a simple thing for Geoff to implement) 
WW |
||||
| MicroBlocks Guru Joined: 12/05/2012 Location: ThailandPosts: 2209 |
I think it will be more like. The MX470 has SD card support but the MX170 not. Without an editor it might be possible to have SD in the MX170. When it comes to that decision then i would prefer the SD support over the editor. This is just an example, to make my point more clear. I have no idea about how it would be to pull that off. :) Microblocks. Build with logic. |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10315 |
The editor uses 6696 bytes of flash memory in the mX170 The file system and SD card support on the MX470 uses 48880 |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2442 |
this could be quite useful - from the datasheet it looks like this can be set up to use a single pin with the external reference returned to ground. using two pins (ref+ and ref-) does have some applications, though a bit more esoteric. re the internal editor, i think this is one of the things that makes the micromite something a little special 
cheers, rob :-) |
||||
| JohnL Senior Member  Joined: 10/01/2014 Location: SeychellesPosts: 128 |
As embedded controller, I still strongly believe that there should be at least 1 core basic bare bones version without most of the current bloated peripherals. There is a C functions and Library option that should be able to take care of most of the individual customized needs. For some people may mean to roll their sleeves up and stop relying on spoon feeding from Geoff. Ongoing bloating is increased the complexity and reduced reliability of the Micromite. How many tricky difficult bugs and how long has the current beta been going? At the end of the day, an embedded controller is going to be very much task specific and will not need to have the editor and dozen different LCD drivers, IR, distance, humidity, rotary encoder, keyboard, etc. etc. built in. Beauty of Basic was the simplicity, lets have at least one simple core version that works reliably. |
||||
disco4now Guru Joined: 18/12/2014 Location: AustraliaPosts: 1003 |
Thanks Geoff. I should have been patient just one more day! Latest F4 Latest H7 FotS |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9610 |
JohnL makes good points.... For those situations, there is nothing stopping you from using a release earlier then 4.7 for example. Smoke makes things work. When the smoke gets out, it stops! |
||||
| Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3292 |
The subject of loadable modules keeps coming up. On the surface it sounds great, Windows has DLLs, browsers have plug-ins, etc. So, why cannot you have a simple BASIC interpreter and dynamically load and unload other features (such as the editor, SD card support, etc) as required? The simple answer is that Windows has a lot more resources (CPU, memory, etc) and a lot more programmers employed by Microsoft. But it is worth some more explanation. Any compiled program will have jumps (some times called branches) to various fixed locations in the program. Also, data (such as error messages) is embedded into the program and must be placed in a fixed location so that the program can find it. Normally this is not a problem as the compiler knows the address that the program will be loaded into and in the last stage of the build process the linker will adjust these references so that they are pointing to the correct places. However, if you want to dynamically load/unload modules into program memory you cannot guarantee the address where the code will be placed and therefore these references will point to invalid addresses. Windows fixes this by dynamically adjusting these references as a DLL is loaded (dynamic linking) but this is a complex task and is not possible inside a small microcontroller. I suppose that I could write a dynamic loader in Windows to create a loadable hex file but I only have one lifetime and there are other things to do. Another possibility is position independent code. This is where all references to addresses are made relative to the to the current instruction (ie, jump to +100 bytes from the current location). CFunctions use this technique but unfortunately the PIC32 C compiler continues to use some absolute address even when it has be told not to. This makes it a pain to develop CFunctions (as matherp will attest) and makes it impossible to create large and complex lumps of code like a loadable editor. All of this means that currently it is impossible to break MMBasic into modules that can be loaded or unloaded at will. The best hope is that Microchip will someday fix the C compiler to generate true position independent code but I am not holding my breath (and please, don't tell me to use ARM). Geoff Geoff Graham - http://geoffg.net |
||||
| Page 3 of 3 |
|||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
