Programming error

Discussions about the Coyote-1 O/S software, or other non-Effects-Module Coyote-1 programming.

Programming error

Postby Tunnelman » Mon Aug 25, 2008 5:19 am

Well i finally figured out how to load tube distortion onto the stomp, looking at the other effects showed me the way. Actually pretty simple once i saw how everything was connected in the editor. I had a bit of a problem with error 6, timeout on write. It seemed if i used run first, i would get the error when trying to load the patch after. I had to reboot the stomp, then load, and it worked okay. Any reason this is happening? .
Tunnelman
 
Posts: 12
Joined: Sat Aug 16, 2008 9:55 pm

Re: Programming error

Postby eric_admin » Mon Aug 25, 2008 4:10 pm

Were you running version 0.0.2 or 0.0.1? 0.0.1 had a bug that caused it to trash some RAM space, causing unpredictable behavior. 0.0.2 is posed on the forum and corrects the problem. If you had the problem with 0.0.2, then I'll do some banging on it and see if I can reproduce (and correct) the error.

Did you feel like there should be more documentation on installing patches and modules?
User avatar
eric_admin
Site Admin
 
Posts: 121
Joined: Wed Aug 13, 2008 6:10 pm

Re: Programming error

Postby Tunnelman » Mon Aug 25, 2008 5:00 pm

Hi Eric


I'm using the new version, i erased the patch and tried it again with the same result. Maybe its' something i am missing here, i really don't know at this point. I guess until some others start working with it, don't know if it is just a problem with my setup, or it is general. As far as the instructions go, possibly a more detailed step by step tutorial on routing and loading a patch. Anyway, gotta go for now, i will do some more testing tonite.

Kel
Tunnelman
 
Posts: 12
Joined: Sat Aug 16, 2008 9:55 pm

Re: Programming error

Postby Tunnelman » Wed Aug 27, 2008 6:27 am

Back again. I tried to recreate the same problem with the other patches, but it seems to only happen with the tube distortion. Anyway, no big deal right now, it can still load from file to get on the coyote. I am sure you have enough other things to deal with, and i would like to move on and start looking into the programming part.
Tunnelman
 
Posts: 12
Joined: Sat Aug 16, 2008 9:55 pm

Re: Programming error

Postby Steve_b » Wed Aug 27, 2008 10:15 pm

Hi Eric,

I was actually able to load the Tube Distortion effect.
I then tried to build my own patch/module (not sure what it is to be honest....maybe this is where documentation would correct me....but then I'd have to read it! hehe)....

Anyhow, I added tube distortion to the distortion effect and wasn't able to load it as a patch...however, I was able to just click on "Run Patch" and it loaded fine and I was able to annoy the wife pretty quick (the pooch bolted too!).

Not sure what happened....I added the two effects. Then changed the patch name and author name at the top and saved it as a different filename. Then I went to patches (bottom right) and "loaded from file" and that's where it choked on an Error 6 (timeout writing the I2C buss)...I thought you hadn't turned on the I2C yet.

Otherwise having fun! :mrgreen:
Steve_b
 
Posts: 13
Joined: Fri Aug 15, 2008 7:07 pm

A workaround

Postby eric_admin » Sun Aug 31, 2008 9:54 pm

Here's a workaround for the elusive "Error 6" (ERR__I2C_WRITE_TIMEOUT) when saving patches.

Change line 121 of COYOTE1_I2C_Driver.spin from:

Code: Select all
       if cnt - start_time > clkfreq / 10     


To:
Code: Select all
       if (cnt - start_time) > (80_000_000 / 10)    ' Note: longest expected delay is 10msec. This will wait 100msec before timing out. 


I'm still chasing down why the change from "clkfreq" to "80_000_000" makes a difference; the values should be equivalent (the parenthization doesn't matter; I just added it to be clear). Something about executing the tube distortion patch appears to modify the value of clkfreq (which should not happen). I'll get to the bottom of it, but in the meantime the patch above will correct the problem until I can solve it properly.

NOTE: Both lines of code are equivalent, but the former is more portable. There's very little downside to adopting the latter permanently, but the fix masks the underlying problem which is that clkfreq should be 80000000 at boot and never change, so I need to go figure out how and why it is being altered.

steve_b said:
I thought you hadn't turned on the I2C yet.


There is no release code which talks to external devices on the expansion port yet, but the EEPROMs both sit on I2C. The Propeller uses I2C to boot from the primary EEPROM on reset/cold boot, and the Coyote-1 uses the upper regions of the primary EEPROM to store Dynamic Modules, Patches, and configuration data.
User avatar
eric_admin
Site Admin
 
Posts: 121
Joined: Wed Aug 13, 2008 6:10 pm


Return to Coyote-1 O/S Programming

Who is online

Users browsing this forum: No registered users and 1 guest

cron