I think that the version of mpasm that he is using will replace 'reset' with a retlw 0 and issue a warning:
Warning[227] xxx.ASM 104 : Substituting RETLW 0 for RETURN pseudo-op.

It can also issue warning for directives outside of col 1, but once the substitution is made, that gets rectified.

Since he does have a call, I think a retlw 0 is fine unless I am missing something.

It seems to me that one possibility is that with MCLR enabled and unconnected, he is in a continual state of reset. I don't know if that chip has any kind of internal pullup and seems possible that it is happening. In which case, he might never see a voltage on that pin.

MPASM might offer suggestions on replacing RETURN with RETLW but not for ‘reset’. I assembled it and it’s just a label. (It’s also in column 1 so no warning there, either). But you make an interesting point from a portability aspect. It would be nice if MPASM recognized reserved words from other PIC’s instruction sets and warned you of missing instructions or those that work a little differently. I usually port to the bigger archectures so didn’t know about the ‘return’ substitution.

Best,
J

 

MPASM might offer suggestions on replacing RETURN with RETLW but not for ‘reset’. I assembled it and it’s just a label. (It’s also in column 1 so no warning there, either). But you make an interesting point from a portability aspect. It would be nice if MPASM recognized reserved words from other PIC’s instruction sets and warned you of missing instructions or those that work a little differently. I usually port to the bigger archectures so didn’t know about the ‘return’ substitution.

Best,
J

Yep, you are quite right - I am tired and confused. G'night

 

Me too, buddy.
Good night to you as well.

 

It isn't of course. The assembler takes it as a LABEL and the code just drops through to LOOP1, which ends in a RETLW, which will underflow the stack *boom*. Maybe the code should GOTO the top where the 'reset' is?

Nice flow chart. Maybe that will get the TS through the course.

As for "reset," obviously it is not an instruction. And it gives an error/warning that a label is not in column 1 when compiled from the TS's original code. MPLAB 8.92 does not make a replacement. I left it in the code as a label so as not to change the code too much.

My focus was to see whether bsf GPIO,0 was reached, as "getting no voltage" seemed to be what the TS felt was the major error. It is reached, but it is done screwy, and if the MIC signal buffered by the LM324 is not real clean, it may do strange things like a badly bouncing switch. I am assuming the purpose of the circuit is a noise or clap detector based on the MIC input, as I have not followed this saga on multiple forums. Why he needs two "on/off" cycles to get through the early delays and what the TS wants to happen when it doesn't is unclear.

After more thoroughly going through the code I did get it to reach bcf GPIO,0 but then it seems to get stuck in a SCAN2/Loop unless I carefully step through it with the stimulus pulse on GPIO,1 (next sentence).

As you point out, RELAYDEACTIVATE goes to Loop1 which falls through to Loop2 and that leads to the RETLW and stack underflow. I wonder whether the TS intends "reset" to be a "goto START?"

Edit: Seems to simulate (MPLAB SIM) smoothly with that change, as expected. GPIO,0 toggles when stimulus is applied to GPIO,1 . But as others have said, I am not quite sure it will do what the TS wants it to do. The need for multiple inputs to GPIO,1 is bothersome. Is that for debouncing or to filter sounds that might be false alarms? If the latter, the second test/delay loop needs an exit back to the START. Otherwise, the code will tend to idle on the second test/loop and still respond to false signals.

 

Hello guys,

Changed MCLR OFF and when testing I get these results. (attached photo voltage.jpg)

 

That is something different.

Maybe it is time to tell us exactly how the program should behave?

Also, what did you want to happen at reset (your line 92 in the code in your first post to the thread)? RESET is a legitimate instruction for some Pics, but not the 10f222.

I have to, again, admit my earlier skipping over this issue or confusing it with the RETURN issue - in my defense, some of us also missed this in one of the earlier threads https://forum.allaboutcircuits.com/...-command-on-pic10f222-microcontroller.157233/ [not much of a defense ]

 

First, get the debugger working:

• Right Click the project name in the Projects window and click Properties.
• Select AC162070 in the Supported Debug Header drop down.
• Select PICkit3
• Connect it all up. Install the Debug Header using the DIP-8 package pinout.
• Open the source assembler file and click in the left-hand margin on the instruction after the label 'initialize:' to set a breakpoint.
• Click Debug Main Project on the MPLABX toolbar. The project will build and the code will be loaded to the debug header.
• Execution will start automatically and will stop at the breakpoint you set.
• If it doesn't get there, FIX YOUR DEBUG ENVIRONMENT before proceeding. Don't try debugging without the header. The 10F has no native debugging and just programming the chip and wondering why it doesn't work (program and pray method) is not a good way to do it.

Once the debugger is working and stopped at initialize, step through the code by clicking the orange arrows in the debug toolbar.

• Set a breakpoint on RELAYACTIVATE
• Click RUN in the debug toolbar.
• Operate your button.
• If the code does not break there, go up the program steps setting breakpoints until you get one.
• Step the code from there to see where your logic breaks down.
• You can bypass the loop1 delay by right-clicking on the RETLW instruction then selecting RunToHere. For that subroutine you can also click 'Step Out' on the debugger toolbar. That will run the code until it hits a 'RETLW' instruction

Don't forget to replace 'reset' with a GOTO somewhere..

Good luck!
BTW: if you are using the 10F322 in a SOT23-6 package soldered to Microchip's SOT23 to 8pin DIP adapter you should know that the resulting pinout does NOT match the regular DIP8 chip. You'll have to buzz it out to see how it connects up.

EDIT: I flowed out your code for you. You should always do that BEFORE you code anything. When you do, it validates your logic or exposes errors in your thinking. Things like what happens after turning the relay OFF jump right out. When you are happy with your flow chart, just code each symbol and your code will work.

What if he did a goto MAIN or INITIALIZE instead of RESET?

 

Thank you all for your answers. I will try to test PIC with the ASM code on my PCB tomorrow, after I will do some changes in my PCB with the bad transistor replacement to a new ordered one. I will also try today start debugger working by JohnInTX tutorial. The code goal is to get 0-5V again and again to my output PIN#5, but maybe the multimeter can't detect the changes, because it is too fast? I am thinking about to connecting oscillator on PCB and testing if there is changes in the amplitudes when doing some kind of sounds which should be higher than 1.5V because of my voltage divider near amplifier LM324.

 

Thank you all for your answers. I will try to test PIC with the ASM code on my PCB tomorrow, after I will do some changes in my PCB with the bad transistor replacement to a new ordered one. I will also try today start debugger working by JohnInTX tutorial. The code goal is to get 0-5V again and again to my output PIN#5, but maybe the multimeter can't detect the changes, because it is too fast? I am thinking about to connecting oscillator on PCB and testing if there is changes in the amplitudes when doing some kind of sounds which should be higher than 1.5V because of my voltage divider near amplifier LM324.

I would STRONGLY encourage you to step back and take a good long look at the flow chart that @JohnInTX prepared for you in post #19.

You really have to address the RESET issue and I am not sure that you understand that because you do not mention it at all above.

Again, giving us a clear idea of what it is supposed to do would help us help you.

 

Thank you all for giving so many ideas how to solve this problem. Already changed reset to goto START. I am testing Vdd and PIN#5 OUTPUT, when I start to program code, sometimes I get 0 - 4.75V again and again, do not want to predict if anything is working or not, because I will have to test it on PCB how it works with other components after I receive ordered trans and replace it with bad one.

 

Thank you all for giving so many ideas how to solve this problem. Already changed reset to goto START. I am testing Vdd and PIN#5 OUTPUT, when I start to program code, sometimes I get 0 - 4.75V again and again, do not want to predict if anything is working or not, because I will have to test it on PCB how it works with other components after I receive ordered trans and replace it with bad one.

ok, got ya...
From this thread, https://www.microchip.com/forums/m1093815.aspx I now see that you are attempting to design some kind of clap on/off switch. (BTW they also missed the RESET issue). What is new, is a blown transistor.

This project is about Clap ON/OFF process. I have already made a PCB and soldered whole circuit, but the relay is not working from the sound of clapping it works only when you put on and off cabel to the 230V socket. I have also tested with multimeter the microphone voltage which reacts to the sound and gives different voltages. I guess that it is microcontroller code fault, because when testing my PIN#5 OUTPUT with multimeter I do not get any voltage which should proceed to relay (check circuit).

I realize that I do not know how much you know or how much you have done so far. Nevertheless, I really believe that you are making this much harder than it has to be because you seem to refuse to test parts first and not the whole. I said that and I have now read it by many people on multiple sites. There is a reason why people keep telling you this and that reason is because it is the best way to succeed.

In this case, why not start by getting GPIO 0 toggle every second? The code simply configures the chip and toggles the relay...on an off. This would be a bit of a sanity check, but I really think that it needs to be done. We can help with the code. You would ONLY use this part of your schematic.


You should hear the relay clicking on and off. It will check for a stable power supply and it will check that you have configured the chip accurately and it will check the components.

Once you are satisfied that you can do that, THEN you move on to the next part.....I'm telling you, please believe me, there is a reason why you keep hearing about this approach.

 

OK. It would help you to re-read @jpanhalt 's excellent analysis in #24 especially the 'Edit:'. Does that agree with your test results? Does the flow chart?
It would help if you told us what this thing is to actually do and describe how your implementation goes about doing that. If we know all of that, we can look at your code from a functional perspective rather than guess at it.
Post your current code.
Making progress!

EDIT: while typing, @Raymond Genovese posted another good idea. It will prove out your hardware and firmware development environments. You can use an LED + resistor for the relay while you're waiting on replacement parts.
Nice work, gentlemen.

EDIT: Everyone else is doing such good work, I updated the flow chart to show going back to START after Relay OFF. Not just y'all having all the fun.

 

EDIT: Everyone else is doing such good work, I updated the flow chart to show going back to START after Relay OFF. Not just y'all having all the fun.

Are you using a program to assist with those nice flow charts?

BTW: This line from the OP, "but the relay is not working from the sound of clapping it works only when you put on and off cabel to the 230V socket." is troubling.

 

Are you using a program to assist with those nice flow charts?

BTW: This line from the OP, "but the relay is not working from the sound of clapping it works only when you put on and off cabel to the 230V socket." is troubling.

I use an old version of Edge Diagrammer. Does the job.
http://www.pacestar.com/edge/
TS lives in a 230V part of the world so hopefully that is just him plugging in the isolated power supply. He indicates he's in a university lab so some safety procedures are hopefully in place. As far as it working on the noisy connection on power up.. maybe he's finally getting enough signal out of the analog section as it powers up.

Or maybe the mic is picking the snap-crackle-pop from the sparks...

 

@Raymond Genovese

OT I used to use Lucid Chart (free). It was great but the free version became quite limited. Someone suggested yED (https://www.yworks.com/products/yed ). It is a little clumsy but does the job for free.

 

I use an old version of Edge Diagrammer. Does the job.
http://www.pacestar.com/edge/

OT I used to use Lucid Chart (free). It was great but the free version became quite limited. Someone suggested yED (https://www.yworks.com/products/yed ). It is a little clumsy but does the job for free.

OT I know, but thanks, am checking them out...as I can't find my Archer template and I am tired of PPT, I see one in my future. As expected, I already see that they added every type of chart that I will likely never use...but I do like the "auto routing" feature if it works. Testable/usable online is a plus.

 

Thank you all for help. I will test everything on my PCB tomorrow and give you the news

 

Google is amazing. On a lark, I searched on a segment of the code presented here. I stopped looking after I found this:

https://www.microchip.com/forums/m1093815.aspx
https://electronics.stackexchange.c...222-asm-code-builds-but-not-works-as-expected (previously noted by Raymond)
https://www.instructables.com/id/How-to-make-a-Clap-Clap-on-Clap-Clap-Off-switch-/ ( Including schematics)
Code is here:
http://www.electroniclessons.com/10F222TMPO.ASM

There is more.

Most important, karka317 has revealed elsewhere what it is: "This project is about Clap ON/OFF process." I wish he had shared that information with us. In fact, the delay that I suspected was to filter false responses is for that purpose (Instructables claims 250 ms), but it has the same deficiency as pointed out.

Going to multiple sites is not against any rules here, and sometimes getting other opinions is helpful. I don't object to that. What I am uncomfortable with is a "Homework" project that is plagiarized completely from another source and the student has shown little or no effort to understand the code he is presenting as his own work.

 

@jpanhalt I was aware of his posts on other sites (as you noted and as I brought up), here and elsewhere (e.g., my quote in post #31 revealing the purpose of the circuit). I was not aware of the last two links that you posted. I have looked at them now and I am simply not comfortable participating further. There are multiple sides to the issue and I don't claim to know all of them and, for all I know, there is nothing truly unsavory going on because I don't have the assignment.

I am simply not comfortable participating further.

[BTW wtf is it with the RESET opcode? Yes, it is a legitimate opcode in some pics - I have used it with the 12F1840, but it does not appear in the 10F222 data sheet]

 

[BTW wtf is it with the RESET opcode? Yes, it is a legitimate opcode in some pics - I have used it with the 12F1840, but it does not appear in the 10F222 data sheet]

Some of the comments refer to using an 18F series chip. I am more inclined just to pass it off as Instructable plagiarism.

While I can't imagine anyone submitting this work as his own, perhaps moving it to Homework and requiring the TS to solve the "second event" issue for a chip without interrupts per se would at least show some contribution by him for getting a baccalaureate degree in engineering. I know what I would do, let's see if he understands the code himself to do that (without posting elsewhere for the answer) or something even better.