Open JohnCC330 opened 9 years ago
I can't see that the LED port is actually changed anywhere, so I suspect that the microprocessor is resetting.
You should be able to trap that in the debugger.
Could this be the result from this activity (which doesn't originate from the program)?
Check your interrupt flags. There could be lots of things happening here.
And, if so, how do I solve this problem?
Debugging :-D
Also, don't waste your time with a 2550. It's an old, expensive, MCU. There are much better 8-bit MCUs from Microchip for a fraction of the price nowdays. Only ancient tutorials and textbooks recommend the 2550/4550.
Alan.
On Mon, 19 Jan 2015 06:45:39 -0800 Alan Ott notifications@github.com wrote:
I can't see that the LED port is actually changed anywhere, so I suspect that the microprocessor is resetting.
You should be able to trap that in the debugger.
Hi Alan,
Thanks for reply. To be honest, I gave up on the m-stack. I don't have any debugger hardware, and I don't think I can simulate this in the simulator.
Interrupts are not enabled at all. I call(ed) the processing function of m-stack continuously, as I only wanted to set port A to the value of the received byte. So, I just put that part in the data_cb function.
This works fine, except that the 'interrogation' after about 2 minutes seems to reset the processor. Maybe the control_transfer left the stack in some precarious state, or maybe there's some callback function missing for one of other transactions.
Check your interrupt flags. There could be lots of things happening here.
No interrupt flags - no interrupts enabled.
Also, don't waste your time with a 2550. It's an old, expensive, MCU. There are much better 8-bit MCUs from Microchip for a fraction of the price nowdays. Only ancient tutorials and textbooks recommend the 2550/4550.
I know that. The only reason I used it is because I had a few left from another project. If I don't use them, I'd be throwing the money away :) And the experiments I'm doing are not for production either.
Cheers, John
To be honest, I gave up on the m-stack. I don't have any debugger hardware,
PicKit 3 - $45 bucks iirc
Interrupts are not enabled at all.
That doesn't meant flags don't get set on reset.
The only reason I used it is because I had a few left from another project. If I don't use them, I'd be throwing the money away :)
Instead you're only throwing time away ;) I do the same kinds of stuff though...
Alan.
On Tue, 20 Jan 2015 18:09:29 -0800 Alan Ott notifications@github.com wrote:
To be honest, I gave up on the m-stack. I don't have any debugger hardware,
PicKit 3 - $45 bucks iirc
Hi Alan,
I've looked around and the cheapest version I can find (in Argentina) is about the equivalent of US$85 (plus 21% VAT, so, about US$100 final). Given the exchange rate, and the local wages, that is not an insignificant amount. Maybe I can get the Olimex clone - I've seen some good reviews.
Interrupts are not enabled at all.
That doesn't meant flags don't get set on reset.
I've solved the problem with the Microchip stack. If I find some time I'll review the m-stack code and see if I can find a solution there.
I was very surprised though that the Microchip USB stack solution only occupied only 4.5k words.
Anyway, again thanks!
Cheers, John
This is my first experience with USB programming, so it is maybe a little adventurous...
I took the control-transfer example C-code, and the unit-test PIC code. I adapted the PIC code for use with the 18F2550, and removed all code from the 'while'. In the data_cb routine I take the first byte of the buf and send it to 4 LEDs which are connected to the PIC.
In the host C code, I changed the code slightly to parse an argument which says which LED to switch on.
Everything works fine, I can select each LED correctly. But after about 120 seconds the LEDs switch off. Checking with Wireshark, I notice that this happens when the host interrogates the hub.
This is the part from the control program:
then, when the LEDs switch off:
I can't see that the LED port is actually changed anywhere, so I suspect that the microprocessor is resetting. Could this be the result from this activity (which doesn't originate from the program)?
And, if so, how do I solve this problem?