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 serial comms issue
Author | Message | ||||
shoots Newbie Joined: 31/07/2011 Location: AustraliaPosts: 32 |
Hi, I am trying to output serial data from my Micromite without success. I am using version 3.6.9 of MMedit and the latest firmware on the MM. I have tried it on two MMs and a friend has tried it on his to no avail. Below is the program I am trying to run. The welcome message on the touch screen comes up OK. The program segment for serial is taken from the MM manual. I have commented out serial input for now- focus on output OPTION EXPLICIT 'we want to ensure variables are declared explicitly: OPTION AUTORUN ON CONST DBlue = RGB(0, 0, 028) ' A dark blue colour COLOUR RGB(green), RGB(BLACK)' Set the default colours FONT 1,1' Set the default font cls text 150,50,"Welcome",cm,1,3 pause 200 DO 'start the do loop that runs forever OPEN "COM1:4800" AS #5 ' open the first serial port with a speed of 4800 baud pause 100 PRINT #5, "Hello" ' send the string "Hello" out of the serial port 'dat$ = INPUT$(20, #5) ' get up to 20 characters from the serial port CLOSE #5 ' close the serial port pause 1000 'print offTime LOOP I fed the output through a CP2101 to real term and get a FF every cycle. The output of pin 21 registers a pulse on the cro from cro: From the data analyser: Any suggestions please? Regards, Peter |
||||
Zonker Guru Joined: 18/08/2012 Location: United StatesPosts: 761 |
Several things need to be sorted out. First, option autorun on is a command line statement. You do not put that command into a program, why..? Because it changes the behavior of the microcontroller when it "starts up". As such, it is a flag that is written into an area of flash memory. In the Micromite manual, on page 47 shows the "startup" behavior of the firmware. Second, you are trying to "open" the com port within the DO Loop. Refer to Appendix A. You should be setting up the com port near the top of your program only. When done, the firmware setup a section of Ram to act as an "interrupt" driven serial data capture system. you don't even have to close it if you don't want to, but if you do, I wouldn't be doing it inside the Do Loop, although, I guess you could. I think what is happening is this. You chouse a rather "slow" baudrate and you end up closing the com port faster that the time it takes to "trasnsmit" your data packet out of the transmit "buffer. Remenber, it is an "intrupt" driven system. There are commands you can use to "ask" if the transmit buffer is empty.. So, make those changes to you program and it will then work correctly. I would choose a higher baudrate and then use the "zoom" knob on the Tec scope to expand the scope's capture buffer to get a better view... Hope this helps..! |
||||
shoots Newbie Joined: 31/07/2011 Location: AustraliaPosts: 32 |
Hi Zonker, All is working now. I left the Autorun option on as this instructs it to start as soon as the power is on:page 11 of manual. Without ON it will not start when power is reconnected. It might be OK if instructed ON from the terminal but I want it to be independent. I did as you suggested and opened the port outside of the DO loop and left out the close command. I also upped the baud rate and may go higher later. All is sweet confirmed by stream visible on cro and into the terminal program. Now to incorporate this into my main program: I want to stream data to Megunolink for plotting. I have appended the changed program in case it helps others. Thank you for your advice. Regards, Peter OPTION EXPLICIT 'we want to ensure variables are declared explicitly OPTION AUTORUN ON CONST DBlue = RGB(0, 0, 028) ' A dark blue colour COLOUR RGB(green), RGB(BLACK)' Set the default colours FONT 1,1' Set the default font cls text 150,50,"Welcome",cm,1,3 dim integer inc=0 pause 200 OPEN "COM1:9600" AS #5 ' open the first serial port with a speed of 9600 baud pause 100 DO 'start the do loop that runs forever inc=inc+1 PRINT #5,"Hello",inc ' send the string "Hello" out of the serial port & count 'dat$ = INPUT$(20, #5) ' get up to 20 characters from the serial port 'CLOSE #5 ' close the serial port pause 1000 LOOP |
||||
CaptainBoing Guru Joined: 07/09/2016 Location: United KingdomPosts: 1995 |
Hi Shoots. glad you got it working. You may have missed zonker's point about autorun. It is not a command you issue "in your program" it should be set at the console before you run or hit F2 or whatever. Consider a brand new virgin MM, you load this program (do not run it) and drop the power... how will the program know to run when it wakes up again? You will never have issued the autorun command. you should issue the command only once, at the ">" i.e. when no program is running. hth |
||||
CircuitGizmos Guru Joined: 08/09/2011 Location: United StatesPosts: 1421 |
This issue seems a bit odd to me. From what I understand there is nothing negative about including OPTION AUTORUN ON in the source of a program itself, and for any code that I have for a MicroMite that I run on a "finished" bit of hardware the autorun is in the source code. Where I don't have it is in temporary code that I run just to test something out, as that code doesn't need to run immediately from reset. It was suggested to include OPTION AUTORUN ON in source code here on tbs, and I've seen it in some example code. I don't think that there is any harm in having OPTION AUTORUN ON in the code - I don't believe that the option is rewritten to flash if it was already set. (That was a suggestion, but I'm not privy to the source.) If it is needlessly rewritten, then perhaps wearing out FLASH would be a potential problem. Can Geoff or Peter advise on this? Micromites and Maximites! - Beginning Maximite |
||||
robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2294 |
there used to be harm in earlier releases of the MX170 code, as the option setting was rewritten to flash every time the line was executed, irrespective of the currently saved state of the setting. this caused quite a bit of mayhem, but that bug has long ago been fixed. i really would like to see all options allowed in basic code (in particular the colour LCD and touch panel ones), so that the basic source code becomes the only thing one needs to type in to get a project running. this could be effected by having the LCD and touch options cause a reset if they result in a change in setting, else be skipped over if they match what is already configured. just my opinion, mind you! cheers, rob :-) |
||||
CaptainBoing Guru Joined: 07/09/2016 Location: United KingdomPosts: 1995 |
Agree with that |
||||
CircuitGizmos Guru Joined: 08/09/2011 Location: United StatesPosts: 1421 |
I agree, but my suggestion was shot down twice. Micromites and Maximites! - Beginning Maximite |
||||
Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9083 |
CG - that MIGHT have been if you were suggesting it around the time of that flash-writing bug that Rob was talking about. That was then and this is now...... Personally speaking, I also tend to include the OPTION AUTORUN ON in the options at the top of the code, but typing it a the command prompt is no big deal for me if I have to do it that way. I also agree that it would be ideal to have ALL the option commands inside the main code, rather then at the command prompt, but I also state that this is just my opinion as well. Having said that, typing in the OPTION commands at the prompt is no big deal(for me) as you only usually need to do it once, unless you have to reflash the firmware often for some reason. Smoke makes things work. When the smoke gets out, it stops! |
||||
Print this page |