Debug vs. Smartpins while programming SPI interface [Solved]
I am working on a multipurpose SPI implementation using Smartpins and Streamer + assembly language.
As I am making many mistakes and searching for errors a lot of the time, I started using the debug function of the Propeller 2.
Doing so, I have stumbled across something, which I cannot really explain:
If I activate the debug function in the Propeller tool (even if I don't use debug statements in my code), the smartpins and streamer seem to stop working. If I deactivate the function, they work normally without any further changes to my code:
With debug enabled:
Without debug enabled:
Is there maybe an explanation for this behaviour?
I couldn't really find something in the Spin2 Manual and I also tried to search the forum, but without success.
I have attached the corresponding code to this post. However, please keep in mind that it is still a work in progress, not optimized in terms of code size and performance and could contain some flaws.
For hardware debugging purposes I also used the LED matrix and control board from the P2-ES Eval Board Accessory Set together with the libraries P2ES Control and P2ES Matrix from JonnyMac.
thanks for your reply. I added the according links to my original post.
Turns out those files weren't needed since those routines weren't being called anyway.
Well, compiling in Flexspin it don't work either way ...
Looking at the setup() routine, on a hunch I added a
coginit()and it now works using Flexspin - You've got a race timing issue. Debug must be affecting the timing around coginit()'s.
change_clk()would already be waiting before the Pasm cog has started. The launchee Cog takes a short while to load up. Meanwhile the launcher Cog is free to continue.
Thank you very much, evanh.
It now works also with debug enabled and I would never have found this race condition all by my own.
I didn't delve any deeper myself but it would be a good exercise for you to nut out if there is a cleaner solution than just adding a pause there. Often an extra state variable is needed, so is debatable as to which solution is cleaner. Maybe it's a case of just improving how the
operationvariable gets used. Adding an extra case to that would be clean.