Libavr32 i2c update

bpcmusic · 2016-07-01T13:45:53.638Z

thanks @tehn - i’ll merge the repo and integrate over the weekend.

scanner_darkly:

i had problems passing negative values

me too; in my implementation for bipolar voltage output i simply moved the values positive on send and moved them back down on receive. i had inconsistent results casting, so ultimately i did it the old fashioned way.

–

still trying to figure out why the master rx function is locking the teletype when implemented without a tx before it on the metro script. anyone know of anything fundamental going on when running a script from a timer vs a trigger that would lock a rx command (vs an rx command that follows a tx command)?

b

tehn · 2016-07-01T16:30:13.093Z

i think a simple pull should update the trilogy modules. it’ll resolve the correct checkout.

bpcmusic:

still trying to figure out why the master rx function is locking the teletype when implemented without a tx before it on the metro script. anyone know of anything fundamental going on when running a script from a timer vs a trigger that would lock a rx command (vs an rx command that follows a tx command)?

i can’t think of anything that would cause problems off the top of my head, so i’ll need to look more closely at the code. have you dug into the TT source as to how the scripts are getting executed? check if things are happening in an event vs. interrupt etc.

tehn · 2016-07-01T18:35:50.586Z

heads up @bpcmusic that i also updated the master_rx functions for arbitrary buffer length.

scanner_darkly · 2016-07-01T18:38:19.479Z

tried updating my whitewhale fork:

git merge upstream/master```

at which point it showed that libavr32 was changed, i assumed it was the submodule revision update and just pushed it to my master branch. but looking at it now the change in libavr32 was to change it back to the older revision... so now i'm confused - should i have just reset this change instead of pushing? and do i just revert this latest checkin now?

edit: just reverted the libavr32 change and pushed the revert as this seemed like the safest option. hopefully this won't break things down the road!

tehn · 2016-07-01T19:00:51.857Z

it shouldn’t. i changed more things in the i2c lib but they are cosmetic or debugging strings. everything compiles.

scanner_darkly · 2016-07-01T19:04:43.340Z

yeah, i didn’t mean the code, just the git history. looks like it should be okay, now i just need to rebase my dev branch from my master. still learning my way around git!

…looks like it worked. still not sure why it would pull/merge the revision change for libavr32 from upstream master but then report that i had a local change, as if i manually changed it back to the old revision #.

sam · 2016-07-02T06:41:34.934Z

Submodules don’t update their code automatically with fetch / merge / rebase / pull. You need to git submodule update.

A wrote a post up about it a few months back before we split the repos up.

http://samdoshi.com/post/2016/03/git-submodules/

scanner_darkly · 2016-07-02T18:10:35.755Z

yeah, i should re-read it to refresh my memory - i guess what happened was i didn’t update the submodule, so then from the git’s point of view it was like i had a local change.

tehn · 2016-07-02T18:17:18.196Z

you can also just pull from the libavr32 folder

ie

cd whitewhale/libavr32
git pull

sam · 2016-07-02T18:22:52.849Z

Yep, though I think that will fetch the current HEAD rather than the commit pointed to by the parent repo.

tehn · 2016-07-02T18:28:04.230Z

sam:

Yep, though I think that will fetch the current HEAD rather than the commit pointed to by the parent repo.

ah, you’re correct. good clarification.

scanner_darkly · 2016-07-02T18:35:13.864Z

so that would be the workflow if i want to switch to the latest submodule revision, correct? so just pull from the submodule directory which updates it to the HEAD revision, and if i push it it will basically update the revision number my repo is using for the submodule?

sam · 2016-07-03T14:04:22.128Z

You need to commit the change to the parent repo too, e.g.

cd orca       # or wherever your git repo is

git status    # the following assumes this comes back as clean

cd libavr32   # go into the submodule directory
git remote -v # make sure you know where the pull is coming from!
git pull      # update to the latest HEAD from 'origin'

cd ..         # back to parent repo
git status    # should now indicate that the submodule commit has changed

# add, commit and push
git add libavr32
git commit -m "updating libavr32"
git push

If for some reason your submodules’s origin is not monome/libavr32 (and you don’t know why that is), then ask and I’ll try and help out as much as I can.

scanner_darkly · 2016-07-03T17:45:24.903Z

yeah, that’s what i meant - when i pull the latest submodule this updates both the submodule and the revision number my repo is using for the submodule, so it’s the latter that i will need to push to my repo.

the submodule origin would be different if i, say, needed to make some changes in the submodule, so i just fork it / temporarily point to that, and then change it back to monome/libavr32 once my submodule change is merged, correct?

sam · 2016-07-03T18:15:51.459Z

scanner_darkly:

this updates both the submodule and the revision number my repo is using for the submodule

Correct (but you do need to commit the change of commit hash to the parent repo).

scanner_darkly:

the submodule origin would be different if i, say, needed to make some changes in the submodule, so i just fork it / temporarily point to that, and then change it back to monome/libavr32 once my submodule change is merged, correct?

Yes, just never change the url in the .gitmodules file. Although I usually find that I leave the libavr32 submodule origin permanently pointing at my fork and just sync up the changes from upstream.

The main thing to remember with submodules is that it’s the commit hash that’s stored in the history, git doesn’t really care which fork it’s from (that’s not how git works). The url from .gitmodules is only used for the initial checkout.

bpcmusic · 2016-07-05T17:28:46.960Z

@tehn - pulled the update in no problem; thanks. i had already made a very similar mod to your rx command to have a variable length buffer. i am, however, using the addr functionality to send a parameter to the slave that identifies the input # that the teletype wants to poll. i went ahead and integrated your changes into my branch and restored the original function under a new name as follows:

void i2c_master_tx_rx(uint8_t addr, uint8_t idx, uint8_t *data, uint8_t l) {
  int status;

  packet.chip = addr;
  // this allows the index of the input to be sent to the slave transmitter
  packet.addr[0] = idx;
  packet.addr_length = 1;
  // buffer and size of the return data
  packet.buffer = data;
  packet.length = l;

  status = twi_master_read(TWI, &packet);
}

it is pretty nifty how it works. the input module gets a quick command with the address that is about to be polled and then gets a request for a few bytes. this allows the i2c to be kept pretty lean as only the value that is needed is transmitted. i squeaked with it just worked out of the box.

My fork is here in case you are curious: https://github.com/bpcmusic/libavr32/tree/to_operator/src

still need to explore why this command is causing the unit to lock when called from the metro interrupt. had too much fun playing with quantization this weekend.

@scanner_darkly @sam - i have a list of the commands that i use to maintain my forked linked project if that would be helpful.

cheers!

b

bpcmusic · 2016-07-07T02:37:33.372Z

quick update @scanner_darkly -

i revisited my “negative values over i2c” code and validated that i can indeed send negative integers by first casting to unsigned, doing the shifting and sending they bytes, unshifting the bytes on receive into an unsigned int, and then casting to signed. values transfer properly.

b

tehn · 2016-07-07T02:46:17.744Z

the tx_rx command does seem useful. how does the slave code look for this transaction? i was separating the two out to explicitly queue up packet responses.

bpcmusic · 2016-07-07T04:26:22.893Z

Slave code is very simple. Essentially, the slave first gets an event with the payload of the TX (up to three bytes - though I only send one). For the TXi, this sets the desired output that the Teletype wants to poll. Immediately after that the slave gets a request for a certain number of bytes (in this case, two) and returns the value for that input.

I was worried that there might be timing issues - but I’ve been able to pound the i2c bus requesting data from 8 different inputs and get really fast response rates (and the proper data) passing it through the Teletype and back out. Longer term it might make sense to cache the response for at least the length of a script to reduce redundant polling, but for now it seems to be working.

For most flexibility, the function would take an array for the the three packet.addr bytes and set the length based on how many the calling function was passing. I left it as-is for now.

Cheers!

b

scanner_darkly · 2016-07-07T16:14:23.879Z

without changing the TT code i have no control over how it’s sent but yeah, i think i should be able to just restore to a properly signed int on my end by casting to unsigned, unshifting and then casting to signed.

should probably just go ahead and fix it, but don’t want to be making changes in that area while you and @tehn are working on the new i2c protocol. if it doesn’t get fixed in the process i can take a look later!