We wanted to share that Bela recently added a getting started guide for connecting Daisy Seed to their Trill Touch Sensors!
We are excited to see the kinds of implementations individuals will create with this great pairing, and are honored to be recognized by a great open-source platform.
You can check out the Trill Sensors here!
That’s pretty cool. I assume this is using existing Trill Arduino library and you don’t plan to add support to libDaisy for it in the near future?
Yes, it uses the Trill Arduino library.
We do have plans to add Trill support to libDaisy, but do not have a timeline for that yet.
Using Trill sensors with libDaisy came up on the Discord today and then I found this topic.
Is there any indication if it’s on the roadmap yet?
I personally would love to see Trill support being added to libDaisy too. It works well with DaisyDuino and it’s a lot of fun to use.
As far as I know, there isn’t a timeline yet right now.
This diagram is incorrect btw! It shows connections to pins 13 and 14, but the text correctly says we need to use 11 and 12!
Hi there,
just came across this thread so I gave it a try: Added support for Trill sensors · giuliomoro/libDaisy@030da4b · GitHub
This runs the mostly unmodified Trill Linux library. The only relevant changes are in the I2c.h file, where I interface with dasiy::I2CHandle. This is very similar to what I did for Gliss on the STM23G4A1KEU6, although in that case I was using the STM32 HAL directly.
Instead of hardcoding bus and pins like other I2C-based libraries in src/dev/, I am providing a minimum of flexibility, so the user can pick one of I2C busses 1 or 4, and I am guessing the default pins here. I would be happy to add more busses but I am not sure what (if any) default pins you recommned there. Btw, this (automatically mapping default pins to busses) seems like a feature that should be provided by I2CHandle.
Anyhow, all of this builds but is untested as I don’t have a Daisy. It would be great if you could test it and let me know the outcome.
We’ll get the diagram fixed on our site, thanks.
Hello, it’s great to hear from you!
Thank you so much for doing this. My Trill Bars are currently in one of my moving boxes, so I can’t test it immediately, but I will certainly do so after the move.
The libDaisy support will certainly open up more possibilities.
ok thanks, maybe @dreamer can give it a try in the meantime? Also, where’s the best place to get at least a formal review of the code? Is it too early to open a PR?
Maybe I can have a look this weekend, but strapped on time these days.
Would need to make a pure libDaisy patch as adding a PD integration on top would be a bit much right now. (especially if implementations might change)
It would probably be good to cross-reference how current I2C peripherals are handled to make sure that the same conventions are used (I quickly glanced over the diff, but don’t know enough about things to comment).
I’d say after a quick test of the functionality opening a PR would be good. The sooner you can get some review/feedback the better you can keep momentum.
I’m not sure what that means, but just in case you didn’t notice I added an example here, so for now I think it’s just a matter of running that example and see if it works!
I’ll give it a try over the weekend!
I gave your example a try, and added some additional print statements to be sure.
Everything compiles alright, but as soon as trill.setup() is run the Daisy becomes unresponsive.
Did you pass valid arguments to trill.setup()?
I think I’ll order some Trill stuff, looks like fun.
I have a Hex, so that’s what I put in the config.
Otherwise it should just not find a device and continue, no?
yes
the fact that it just hangs is suspicious. Can you add some print statements in the Trill::setup() method in src/dev/trill/Trill.cpp and in the various initI2C_RW(), readBytes(), writeBytes() of src/dev/trill/I2c.h to try and pinpoint the issue?
I’m not sure how to do this with libDaisy other than through the logger and Print/Printline methods.
What I do see in Trill.cpp is a lot of usage of fprintf() and printf() which I assume do not work on this platform.
This has been fixed! Thanks for finding the issue @dreamer
Ooh, do you mean this PR? → fixed i2c initialization by virvel · Pull Request #1 · giuliomoro/libDaisy · GitHub
Totally missed that! Will try to test this later.
I’ve actually meant the wrong illustration in the documentation… Get started with Trill - The Bela Knowledge Base
But this PR could be true too.
