[SOLVED] usb coneection active only when required?(pic 18f4550)

[mafrasm]

for my project i collect some datas from ADC for a while,and later on i want to transfer those datas to pc through usb connection,
first i built ADC section separately and now i can sense and save required data(processed ADC values) in my pic.(using variables.):wink:
then i built usb transaction:-now i can communicate with pic through usb(in fact i was success in executing usb read/write example provided with mikroc.):wink:
next i need to combine these two and i want to use my pic in two modes:?:
1)temperature sensing mode
2)usb transaction mode
(i tried with switches:- in position 1,pic act as temperate sensing equipment and in switch position 2 it act as usb communicator. even though i could compile this in mikroc it shows stack underflow error in proteous:-()so please help me to over come this.
please help me with any idea to combine these two together and form a single hex file.

 

[mafrasm]

plzzzzzzzz any body help me .............if the question is not clear pls ask!

 

[BradtheRad]

Is this a stack usage issue? Or a dropped USB connection issue?

Are you pushing and pulling from the stack in correct sequence?

Do you have two routines using the stack simultaneously? Out of order?

Does your USB routine skip a stack use if it sees no USB communication?

Does it pull from the stack without there being a value available for it?

 

[Sink0]

With no code is almost impossible to predict waht happened....

 

[mafrasm]

Is this a stack usage issue? Or a dropped USB connection issue?

this is about stack usage issue,if i compile and run only the mikroc read,write example then it works perfectly.....similarly if i compile and run my "adc usage project" then it also works perfectly but when i try to combine these two (i transfer obtained "adc usage project" results to pc through USb) and make a new code for this combined project although mikroc doesnt show any errors; in proteous and in real hardware it doesnt work(in proteous it shows stack over flow error)

Are you pushing and pulling from the stack in correct sequence?

in mikroc code i didnt use push or pull code.

Do you have two routines using the stack simultaneously? Out of order?

im not sure about this ill post my code here,

Does your USB routine skip a stack use if it sees no USB communication?

plz refer to my code i dont know how to figure out the answer for this

Does it pull from the stack without there being a value available for it?

plz refer to my code and if possible explain me the question as well.im sorry im very new to usb...


finally thank you very much for your responses!

---------- Post added at 20:01 ---------- Previous post was at 19:37 ----------

her is my code,in fact im building a digital multimeter,this part containes only the USB and voltmeter section..

 

[BradtheRad]

You say a stack error occurs when you run both routines combined. But no error when you run each separately.

To use the stack it requires that you use it a balanced number of times. For every item you push on the stack, you must pull off the same amount of items.

Can you track down when the stack error occurs?

Possibilities which I think of:

1.

USB hardware may use the stack. And perhaps the USB protocol cannot wait while your other routine executes?

Try putting a delay loop or dummy function inside the USB routine. Run it by itself. The idea is to see if the USB protocol generates the stack error.

2.

Or is the error because of your ADC routine? To find out, add a delay loop before it exits. Run the ADC and USB routines. You may get time to notice what's happening in the ADC loop as the error occurs.

3.

Your code contains an interrupt statement.

Questions:

* Do you have an interrupt routine which uses the stack with or without your knowing about it?

* Or does hardware use the stack without your knowing about it?

* Does hardware push a value on the stack? It may do this to tell you that it did do something or didn't do something. You must pull off that item each time because if you don't you get an error eventually.

* Does hardware expect you to put a value on the stack? Because when it doesn't it find it, you will get an error after enough times.

Hardware has instructions for using its routines. You need to be aware regarding what use is made of the stack, what values to pass to a routine, what time factor there is to do things, etc.

 

[mafrasm]

You say a stack error occurs when you run both routines combined. But no error when you run each separately.

exactly..

Can you track down when the stack error occurs?

i think its because of USB usage...in my code i check a pin(RB0) to start USB transaction(if the pin is high then pic knows its time to start USB transaction),but even without that pin(RB0) is high i think USB always runs and keep on stack to be full....

and also im not sure that whether this is the best way to use USB and another function together....if there is any other way to do this (other than checking a pin )plzz let me know how to do it(may be using interrupts..,but im bit scared of use it because i already have an interrupt routineused for the USB...)

USB hardware may use the stack. And perhaps the USB protocol cannot wait while your other routine executes?

so what can i do to stop it in software...

Try putting a delay loop or dummy function inside the USB routine. Run it by itself. The idea is to see if the USB protocol generates the stack error.

i tried this! but no matter how much large i put delays the stack over flow happens in the same speed...so i think its because of the interrupt i use, so for ur this question

* Do you have an interrupt routine which uses the stack with or without your knowing about it?

i dont have enough knowledge about it...(but i know that USB HID works through interrupts,i dont know the exact mechanism)

* Or does hardware use the stack without your knowing about it?

this may be a reason too but i dont know how to check it...


thanks for replying my post........
plz help me...if i could complete this project, im planning to post it once my grades are given for the project..........coz i didnt see any project which combine both USB and some other operation.....in the internet

 

[BradtheRad]

More ideas...

USB protocol is designed to handle many devices.

Each device must observe USB protocols.

Example, to prevent data collisions from happening. USB must do things in sequence so traffic won't interfere.

USB waits for reports from devices. (But only for a few cycles.)

Or USB talks to one device and tells all other to wait.

Do you have other devices on USB? DOes USB see your program pausing (your ADC routine)? Does USB stop expecting your program to send data, so therefore it seeks out other devices? It may do this even if you have no more devices.

Etc.

USB protocol wants to see certain things from devices. Therefore when you execute your USB routine, does USB expect a certain number of bytes when you send your data? When your routine is finished sending data, does USB expect a certain value at the end?

---------- Post added at 19:43 ---------- Previous post was at 19:38 ----------

More to consider...

Was the stack problem an overflow error? Or an underflow error?

If you're getting a stack overflow, then pull an item off the stack sometime during your routine. Not sure if it should be at the beginning or end of your USB routine.

If you're getting stack underflow, then push an item on the stack at the beginning or end of your USB routine.

This is likely to crash something. It's only a shot in the dark. However it may get around the stack error long enough to give you a chance to discover some reason for the malfunction.

 

[mafrasm]

i changed to the mikroc version 3.2........which solved all the problems....thankyou very much for helping me..........
i think in version 3.2 it allows you to work even without usb active..........otherwise i should have done dual booting the PIC. One configuration for collecting data, the other for sending data over the USB port and a jumper to select the mode.this i got from a forum....thanks for his thought too..........