 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 MkII V4.6b Update
Page 1 of 2   |
|||||
| Author | Message | ||||
Geoffg Guru  Joined: 06/06/2011 Location: AustraliaPosts: 3165 |
This is a quick note to say that there is a new version of the Micromite MkII (V4.6b) firmware for download from http://geoffg.net/micromite.html This is a minor updates that fixes a few bugs and adds support for NEC IR remote controls and Maximum/Dallas real time clocks (eg, DS1703, DS3231 and DS3232). In both cases the relevant commands remain the same and the new devices are automatically recognised when they are used. One other new feature is the RTC SETREG and RTC GETREG commands to set and read the registers in a real time clock chip. They can be used to manipulate special features of the chip (alarms, output signals, etc) and store temporary information in the RTC's battery backed RAM. Details are in the Change Log and the updated User Manual. Geoff Geoff Graham - http://geoffg.net |
||||
| twofingers Guru Joined: 02/06/2014 Location: GermanyPosts: 1138 |
Hi Geoff, this is a quick note to say THANKS again! 
>Maximum/Dallas Maximum = MAXIM Integrated?! I like this very cheap (@WW: and chinese  ) DS3231 modules.
Best regards Michaek |
||||
| Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3165 |
Damn, yes I meant Maxim. I have been making silly mistakes like this all day. Geoff Graham - http://geoffg.net |
||||
| viscomjim Guru Joined: 08/01/2014 Location: United StatesPosts: 925 |
Jeeeez Geoff, this is awesome. NEC and DS3231, YEAH!!!! Just out of curiosity, the manual shows that no matter which rtc you are using, the command to set and get are the same. How do you detect which rtc module is being used? Thanks again, this is getting really awesome, especially with the possibility of the 64 and 100 pinners in the future and the crazy fast C functions (even though I still can't completely wrap my head around them)!!!! Arduino be damned!!!! JK... |
||||
| Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3165 |
It tries the Maxim I2C address first and if there is no response it tries the Philips address. The process is quite fast, about 0.08mS. The IR protocols have different timing on the start pulse and that is used to determine which protocol is being used when an infrared signal is received. Geoff Geoff Graham - http://geoffg.net |
||||
| ajkw Senior Member  Joined: 29/06/2011 Location: AustraliaPosts: 290 |
Long Lines =
{option display x,132} |
||||
jman Guru Joined: 12/06/2011 Location: New ZealandPosts: 711 |
Fantastic Thanks Geoff Jman |
||||
| PicFan Senior Member Joined: 18/03/2014 Location: AustriaPosts: 133 |
Hi Geoff! Thank you for your great work! I only have 2 small problems: I have built a wireless measurement system with 4 transmitters and 1 receiving center (433MHz or 2.4GHz). It works for months with PIC150MX128B without problems, but since I upgraded to PIC170MX256B following problems have occurred. 1.) If I Change the batteries in the transmitters at 3 times will exchange, minimum 1 times the Basic program is deleted. The pins console TX / RX are not wired, they are open. With and without capacitor connected to pin 1, the problem persists. (During batteries replacement, the CPU is in sleep mode) 2.) In the receiving center, the COM1 of Micromite 1 is connected to the console of Micromite 2. Upon loss of power supply, loses Micromite 2 almost always the program, Micromite 1 also, but less frequently. I have replaced the chips, but the same problem. I think the problem is related to the "option PIN" together, if you forget your code to delete the program.(Console RX Connect to TX and Power on) Maybe it would be better to delete the program after 3 or 5 incorrect Code entries? (Configurable ?) Sorry for my bad English ! Thank you and best regards from Austria ! Wolfgang 
|
||||
| Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3165 |
These sound like more than "small problems" to me. I must admit that I have lost patience with the "reset by shorting Tx and RX" feature. It seemed like a good idea at the time but it has caused quite a few problems. One solution would be to just not bother with this feature. With PICKit 3 clones as cheap as $20 it would be simpler to just reflash the chip. Another solution would be to have yet another option to disable/enable the "short Tx/Rx" detection - however that is messy as there are already too many options in MMBasic. Does anyone have a bright idea? There must be a simple way of telling the MMBasic to reset the flash when access via the console is impossible. Geoff Geoff Graham - http://geoffg.net |
||||
| ajkw Senior Member Joined: 29/06/2011 Location: AustraliaPosts: 290 |
Some ideas... None may work!! MCLR To Console Tx or Rx MCLR to Gnd 'or is this a normal reset already?? A very particular resistance across Con TX RX, not just shorted. Anthony. |
||||
| WhiteWizzard Guru Joined: 05/04/2013 Location: United KingdomPosts: 2794 |
Could you not simply dedicate an I/O pin to this function which is checked upon power-up? I know on a 28-pinner this means losing one of only 19 I/O pins; but on a 44pinner (and the hopefully upcoming 64 & 100 pinners) then one pin is no real loss. It also eliminates any reset issues caused by an 'external' device on the RxTx pins. I would think that checking at power up for a certain condition on such a 'dedicated pin' would work better if the same check is done repeatedly a number of more times within say the initial 5-10 seconds. Then, and only then should the MM 'reset'. I say this to eliminate 'slow' power-up conditions which has also been the 'trigger' of this issue (and possibly still is). Note: if the 'dedicated' pin is not initially sensing a 'reset' condition the the MM should boot as normal i.e. immediately. Only if the dedicated pin senses a Reset condition should it enter this 'timed check'. Hope this makes sense; interested to know if I have totally overlooked something though 
WW For everything Micromite visit micromite.org Direct Email: whitewizzard@micromite.o |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2292 |
i've commented on this issue before :-) personally, i would be happy to see the "short together console TxD and RxD" feature removed completely. it does seem to cause a small but distinct set of users a great deal of trouble, and i feel sorry for these folks. the present system also precludes creating any micromite based product where the console pins are exposed. an alternative? if one is indeed needed: how about a 'key' that has to be plugged into the console connection. perhaps an inverter between TxD and RxD pins? this would requite just 1 transistor and maybe a base resistor. configure the internal pullup on RxD as the collector resistor. the onboard current limiting on the TxD pin may be adequate to eliminate the need for a base resistor. if TxD could be configured as an analog input, it would also be possible to measure the transistor's Vbe as an extra level-2 check. and here's an absolutely foolproof, albeit bizarre solution - require a DS18B20 to be plugged into the console to achieve a reset. connect TxD to the sensor's Vcc pin, RxD to the data pin. one could even require the user to touch their finger to the sensor before performing a reset, to prove they are actually human, and not a robot! cheers, rob :-) |
||||
| hitsware Guru Joined: 23/11/2012 Location: United StatesPosts: 535 |
> MCLR to Gnd 'or is this a normal reset already?? Right ... What's wrong with that ? |
||||
| ajkw Senior Member Joined: 29/06/2011 Location: AustraliaPosts: 290 |
Do you mean, 1. What's wrong with using it for a firmware default? or 2. It is already a reset to restart the MPU. If so there is nothing wrong with that. It therefore would be unavailable for a 'restore to factory default' and it would be thus difficult to change given others may a have reset switch on their PCB's) |
||||
TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 5921 |
One option would be: If you press the reset between 2 and 5 seconds of starting, a full restore is performed. To be safe, the restore could require the action 3 times (each press within the 2 - 5 second window after each reset). In the firmware, On each startup, check a flag and if 3 or greater, perform a restore. else 2 seconds after startup, increment the flag 5 seconds after startup, clear the flag Jim VK7JH MMedit MMBasic Help |
||||
| hitsware Guru Joined: 23/11/2012 Location: United StatesPosts: 535 |
> It is already a reset to restart the MPU. > If so there is nothing wrong with that. > It therefore would be unavailable for a > 'restore to factory default' and it would > be thus difficult to change given others may > a have reset switch on their PCB's) I'm obviously missing something  |
||||
| ajkw Senior Member Joined: 29/06/2011 Location: AustraliaPosts: 290 |
Oh, it can be trying sometimes with forums and discussions....
I have a feeling* others have a push button switch on this pin (MCLR) to Gnd as a hardware reset or restart (the equivalent of turning off then on). If so it would be difficult to change it to a 'firmware default' which wipes everything without doing something like Jim suggested. Following Jim's idea, perhaps just a short press and a long press would work. Short for restart, long to restore to 'factory default' EDIT: If MCLR to Gnd stops the PIC then this wont work, back to Jim's idea. * Perhaps someone else can confirm if this bit is actually correct. NB: restore to 'factory default' = reset the flash Edit: I just tried with a Micromite and taking MCLR to ground does restart the PIC. |
||||
MicroBlocks Guru Joined: 12/05/2012 Location: ThailandPosts: 2209 |
[quote]There must be a simple way of telling the MMBasic to reset the flash when access via the console is impossible.[/quote] I do not understand this requirement. If there is no access through the console the chip is 'broken' and needs to be replaced. If it is to protect against reading the content (PIN) then certainly the console has to work. In that case a simple question at startup before any usercode is run like 'Enter PIN?' would be enough. This will introduce a delay, but is a confirmation that the user wants to change something, and the ONLY way to do that without reflashing is through the console. So it is actually a requirement to have a working console to do the clearing of the flash! Another way is to read the console and see if a key is pressed. (Similar to how PC's check for a key (DEL) at startup to enter setup.) This is probably a familiar way for many users. In my opinion it should actually be totally impossible to brick a chip through software. Especially when it is intended for use in embedded systems. The firmware has to be in utter control at all times. Clearing flash that contains information that is needed by the firmware to remain control is, again in my opinion, absolutely forbidden. After that being said, it might be good to evaluate the importance of a PIN. I can think of a few scenarios. 1 ) someone makes a project and has no problem that anyone can read the code no pin is used. No pin is needed. 2 ) a project is made that does need protection from people reading and tampering with the source code. Flash it with a protection bit set. A pin will not protect against reading the content of the flash. No pin is needed. 3 ) Stop the user from reading code AND a console is part of the solution AND you just want to put up a tiny barrier to protect against a casual user to prevent modifications Use a pin. When the user stops the program with ctrl+C or an option in the program he should not be able to list the program. Any console command should then ask for a pin. Any other scenarios to consider that do not fall under the above three that require a pin? Microblocks. Build with logic. |
||||
| Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3165 |
There are a number of scenarios where the user could loose access to the console: - Set a PIN and then forget what it was. - Set an incorrect (or unknown) baudrate for the console. - Accidentally invert the console. - Set OPTION CLOCKTRIM to an extreme value. If autorun was set and: - Disable the break key and let the program execute an infinite loop - Set a very short watchdog timeout which does not allow the user time to CTRL-C There are probably others that I have not thought of but they all mean that you loose access to the console. The idea of shorting Tx and Rx was that it allowed a user who has bought a pre-programmed Micromite to rescue the chip by resetting everything to the initial defaults and thereby restoring access to the console. Thanks for the inventive ideas but I still cannot see a solution that is simple and effective. Grounding MCLR will not work as the chip is held in reset and so the firmware looses control and does not know what is going on. Dedicating one pin to this purpose sounds rather wasteful given that most people use the 28-pin Micromite. Timing between resets has technical issues (timing info would have to be repeatedly saved to flash). Inverting the signal could easily cause false resets as the current system does. I like the idea of connecting a DS18B20 (now that was "thinking outside of the box") but it is complicated and hard to explain. However it would certainly stop inadvertent resets and program wipes. With the cheap PICKit 3 clones perhaps the best course is to just remove the reset feature and tell people to reload the firmware. If the worse happened to someone who bought a pre-programmed Micromite they would only be $20 out of pocket. Hopefully this would be a rare event and the bonus would be that they could then load future updates. All food for thought, Geoff Geoff Graham - http://geoffg.net |
||||
Grogster Admin Group  Joined: 31/12/2012 Location: New ZealandPosts: 9073 |
For what it's worth, I favour just re-programming the chip if you lock it up somehow in a serious way. I am biased in that comment somewhat, cos I already have a PK3, but as mentioned, the clones are getting very cheap these days.... When I bought my clone(about 18 months ago), they were still $40 or so, so they have halved in price since then. Smoke makes things work. When the smoke gets out, it stops! |
||||
| Page 1 of 2 |
|||||
 Print this page |
