Re: [riot-devel] ReSupport for Microchip MRF24J40 Radio Module
Hi Adika, here is the currently pretty much WIP pull request for the MRF24J40 transceiver: https://github.com/RIOT-OS/RIOT/pull/5099 Any help in reviewing and testing is welcome ;-)! It will take me some days to start the review. Best Peter Am 15.03.2016 um 08:55 schrieb Peter Kietzmann: Hi Adika, it is as usual: took longer than expected. A WIP pull request should be opened soon. I'll force @TobiasFredersdorf ;-) to open it. If you have some experience with that device you can speed up development by (reviewing and) testing then. Best Peter Am 14.03.2016 um 20:59 schrieb Adika Bintang Sulaeman: Hallo Bernhard, I'm trying to use STM32F4 Discovery with MRF24J40 transceiver, but I didn't find the driver for this transceiver. It's a relief to see in this mailing list that you and Tobias are working on this driver and I hope the code will be merged soon. By the way, can I see the code you are working on? Maybe if it is possible I can fork the code through Github. Thank you Hello Malo, thanks a lot for your hint about the atzb-a-233-xpro module. I guess RIOT should support this module out of the box (as a reference for debugging). Best regards, Bernhard --- Hello Peter, shure - you are right - Tobias is working on it and I stay in contact with him. Thanks also a lot for your help! Best regards Bernhard ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel -- Peter Kietzmann Hamburg University of Applied Sciences Dept. Informatik, Internet Technologies Group Berliner Tor 7, 20099 Hamburg, Germany Fon: +49-40-42875-8426 Web: http://www.haw-hamburg.de/inet ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] PWM API change
Hi Yes, that would be great. Should I implement it in a PR, or has someone something against this ? Marc On 2016-03-17 00:47, DipSwitch wrote: Welcome! It might also be an idea to create something like: #ifndef HAS_PWM_RES_T typedef uint16_t pwm_res_t #endif Which can be overridden by the CPU implementation. This way 8bit timers can use 8bit values and 32bit timers 32bit. Cheers, Nick ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] [riot-users] Certificates on RIOT pages
Thanks Oleg! Now we're super legit ;)
On Fri, Mar 18, 2016 at 4:16 PM, Oleg Hahm wrote:
> Dear requesting IOTlers,
>
> good things come to those who wait: we finally got our letsencrypt [1]
> sponsored certificates for the self-hosted RIOT related pages.
> For https://lists.riot-os.org you should get the following fingerprints:
>
> SHA256
> Fingerprint=4B:90:0F:E4:A8:2A:CE:29:F5:11:17:32:20:63:86:CF:4A:FD:07:7F:84:F6:79:06:9D:AB:24:06:86:81:2D:C8
> MD5 Fingerprint=E2:02:35:D4:92:7F:9A:77:DC:EE:83:AA:23:0B:52:7B
>
> For https://riot-os.org or https://summit.riot-os.org you should get:
>
> SHA256
> Fingerprint=CB:B8:E0:CC:48:4A:D5:54:77:E9:A9:DA:78:58:6B:8C:66:46:66:A8:6C:7A:49:6B:43:F7:88:92:50:A4:3D:E9
> MD5 Fingerprint=E3:8A:41:F5:88:B6:3F:A2:05:5A:DC:59:F1:62:27:23
>
> Cheers,
> Oleg
>
> [1] https://letsencrypt.org/
> --
> DPRINTK("FAILURE, CAPUT\n");
> linux-2.6.6/drivers/net/tokenring/ibmtr.c
>
> ___
> users mailing list
> us...@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/users
>
>
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] PWM API change
Welcome! It might also be an idea to create something like: #ifndef HAS_PWM_RES_T typedef uint16_t pwm_res_t #endif Which can be overridden by the CPU implementation. This way 8bit timers can use 8bit values and 32bit timers 32bit. Cheers, Nick ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Encoder Drivers
On 2016-03-17 10:51, Loïc Dauphin wrote: Hello, I am quite new to RIOT, and, as a robot developper, I searched for hardware-managed quadratic encoders. Didn't found. I think is would be great to add this kind of API to "periph". I have experience in STM32F4 encoders, and I can help to implement at least for this microcontroller family. Hi ! I'm not sure, but is this quadratic encoder the same thing as "rotary encoder" ? If so, I have a simple driver working. If not, then sorry for the noise. Marc ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Encoder Drivers
Hi, sure, I'll try to push that in few days. Marc On 2016-03-17 12:54, Emmanuel Baccelli wrote: Hi Marc, Could you PR this (as WIP, if needed)? Would be great. Cheers, Emmanuel On Mar 17, 2016 12:30 PM, "Marc" wrote: On 2016-03-17 11:54, Loïc Dauphin wrote: Le 17/03/2016 11:12, Marc a écrit : No, it's not in the repository, but I can make it available for you to test. It is still in a Q&D state. Yes, it can be interesting. For stm32f4 ? I've been using it on lm4f120, but it's not specific to any hw... It only uses 2 gpio with interrupt. Marc ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel [1] Links: -- [1] https://lists.riot-os.org/mailman/listinfo/devel ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Call for conn Task Force
Goodevening, Always interesting to talk networking :) On 17 Mar 2016 10:58, "Jose Alamos" wrote: > Hi! > > I'd like to join too. > Cheers! > > ___ > devel mailing list > devel@riot-os.org > https://lists.riot-os.org/mailman/listinfo/devel > > ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Call for conn Task Force
Hi! On Wed, Mar 16, 2016 at 01:39:31PM +0100, Martine Lenders wrote: > Anyone willing to join? I would be interested in discussing a new API in a meeting. Cheers, Oleg -- /* Fuck me gently with a chainsaw... */ linux-2.0.38/arch/sparc/kernel/ptrace.c signature.asc Description: PGP signature ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Encoder Drivers
On 2016-03-17 11:54, Loïc Dauphin wrote: Le 17/03/2016 11:12, Marc a écrit : No, it's not in the repository, but I can make it available for you to test. It is still in a Q&D state. Yes, it can be interesting. For stm32f4 ? I've been using it on lm4f120, but it's not specific to any hw... It only uses 2 gpio with interrupt. Marc ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
[riot-devel] Question regarding MBED-LPC1768 netwok drivers support.
Hi, I tried executing an example of gnrc_networking (gnrc_networking) on Mbed-lpc1768 and it runs fine. But, the network was not configured correctly (e.g. ifconfig doesn't show anything). My question is: What is the status of network drivers for LPC1768? Fernando Alberione Software Engineer Taller Technologies - Argentina San Lorenzo 47, 3rd Floor, Office 5 Córdoba, Argentina *Mobile:* [+54 358 4827823 (ARG)] *Skype:* falberione ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] PWM API change
Hey, Thank you for taking the time to try to help me solve my problem :) The thing is that on the ek-lm4f120xl board, it's a lm4f120... The DS you are referring to seems to be lm4f232 (or similar). I'm using the lm4f120h5qr-124014.pdf as a reference. The main reason I can see this is that there is no PWM generator on my board. I guess it was broken so they simply "removed" it from the datasheet. There is only the timers that can be used in PWM mode: that's what I was describing previously. I could not find how to change their clock speed (and by reading the docs and all the examples I could find, it seems that's not only me). You can easily configure a PWN by setting a freq and duty cycle, but not by settings a freq and resolution. Marc On 2016-03-17 17:48, Hauke Petersen wrote: Hej Marc, this seems like a pretty broken design to me, who knows what TI was thinking... Anyway, by looking at the datasheet, I think that the solution to this problem in this case is to map the values given via the RIOT PWM interface to internal values that make the PWM behave as expected. See section 20.4 how they configure a 25KHz PWM on top of a 20MHz CPU clock. The only thing that probably won't be as exact is the resolution (number of steps), as this must be rounded for this implementation. But just put a comment in the implementation about this. Or as an alternative: implement the PWM interface by using a GPT timer, those can be adjusted to the desired clock speed... Cheers, Hauke On 17.03.2016 12:59, Marc wrote: Hi, Maybe you're right... PWM on lm4f120 is done by configuring a timer for which there's no real prescaler and a match value that gives the duty cycle. The timer is 16bits, but can be extended to 20bits if needed. The timer is clocked by the system, so there's no way to fix a resolution and then pick a frequency (even within a given range): the resolution is the value loaded in the timer, and that corresponds to a frequency. Getting a 50Hz PWM with a 16Mhz clock requires the loading of 0x4E200 in the timer. As the API states that the PWM must preserve the resolution given in the _init(), I need to be able to pass this value. Of course, I could tweak the implementation and do some scaling on the values asked by the user (ie. compute the timer value needed for the required freq and scale all input from other function to match the real resolution), but that would not be ok with "In this case the PWM driver will always keep the resolution and decrease the frequency if needed.". In my case, this would mean the resolution is the real freq, which is not expected by the user. Cheers, Marc On 2016-03-17 12:33, Hauke Petersen wrote: Hi, I have to say that I don't quite understand the problem with the 16-bit max here. Is the timer on the lm4f120 limited to it's prescalers? For applications like controller servo motors 16-bit is normally still more than sufficient... So I think the key here lies in the PWM implementation, and not in changing the API... 'int' was actually not a very smart idea -> when moving an application that uses PWM from a 32-bit platform to a 16-bit platform it will break, without giving any hints to why. When using fixed values for low-level APIs, you always now exactly what you can work with, independent of the hardware you are using. Cheers, Hauke On 07.03.2016 13:33, dkm_riotos wrote: Hi! I'm cleaning a local port for lm4f120 and making new PR. I see that a recent commit changed/cleaned the PWM API. One of the changes includes limiting the resolution to 16bits (it was an int before, so 32bits in my case). Is there a motivation for limiting the value to 16bits ? In my case, the underlying timer can't be scaled but simply extended by a 8 bits . When I need some low frequency (eg. something suitable for driving a servo), I need to set the timer to something > 16bits. I see at least 2 possible fixes : - increase resolution to 32bits in the PWM API so that I can expose the real resolution. Having an 'int' here was not really bad in my opinion, as it was not forcing a size. Forcing 16bits param on a 32bits hw or 32bits param on a 16bits may cost more than simply using 'int'... - do some scaling on the resolution to be able to use the full range of the pwm while limiting the resolution to 16bits What should I do ? Thanks, Marc ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel [1] Links: -- [1] https://lists.riot-os.org/mailman/listinfo/devel ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Encoder Drivers
Sorry, busy days. My code is at work so it will have to wait until monday. Current code is really not in a state that can be merged as it's integrated in a prototype application (no API, everything still working with globals...). But I'll push a WIP PR on monday ! Sorry for the delay Marc On 2016-03-18 18:00, Baptiste Clenet wrote: Hi, Could you link the PR please? Thanks Baptiste 2016-03-17 13:16 GMT+01:00 Marc : Hi, sure, I'll try to push that in few days. Marc On 2016-03-17 12:54, Emmanuel Baccelli wrote: Hi Marc, Could you PR this (as WIP, if needed)? Would be great. Cheers, Emmanuel On Mar 17, 2016 12:30 PM, "Marc" wrote: On 2016-03-17 11:54, Loïc Dauphin wrote: Le 17/03/2016 11:12, Marc a écrit : No, it's not in the repository, but I can make it available for you to test. It is still in a Q&D state. Yes, it can be interesting. For stm32f4 ? I've been using it on lm4f120, but it's not specific to any hw... It only uses 2 gpio with interrupt. Marc ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel [1] Links: -- [1] https://lists.riot-os.org/mailman/listinfo/devel ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
[riot-devel] Encoder Drivers
Hello, I am quite new to RIOT, and, as a robot developper, I searched for hardware-managed quadratic encoders. Didn't found. I think is would be great to add this kind of API to "periph". I have experience in STM32F4 encoders, and I can help to implement at least for this microcontroller family. Cheers, Loïc ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Encoder Drivers
On 2016-03-17 11:08, Loïc Dauphin wrote: Le 17/03/2016 10:56, Marc a écrit : On 2016-03-17 10:51, Loïc Dauphin wrote: Hello, I am quite new to RIOT, and, as a robot developper, I searched for hardware-managed quadratic encoders. Didn't found. I think is would be great to add this kind of API to "periph". I have experience in STM32F4 encoders, and I can help to implement at least for this microcontroller family. Hi ! I'm not sure, but is this quadratic encoder the same thing as "rotary encoder" ? If so, I have a simple driver working. If not, then sorry for the noise. Marc I think it is the same. And I made a mistake, it is not called "quadratic encoder", but "quadrature encoder", or "rotary encoder", as you said. Is your driver in the repository ? No, it's not in the repository, but I can make it available for you to test. It is still in a Q&D state. Marc ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Question regarding MBED-LPC1768 netwok drivers support.
Hi Fernando, the mbed-lpc1768 according to [1] doesn't have any network interfaces as far as I see. Because of this there are no network drivers implemented and ifconfig doesn't have anything to show. Do you use it with any kind of extension board? Best, Thomas [1] https://developer.mbed.org/platforms/mbed-LPC1768/ On 16 Mar 2016, at 15:48 CET(+0100), Fernando Alberione wrote: Hi, I tried executing an example of gnrc_networking (gnrc_networking) on Mbed-lpc1768 and it runs fine. But, the network was not configured correctly (e.g. ifconfig doesn't show anything). My question is: What is the status of network drivers for LPC1768? Fernando Alberione Software Engineer Taller Technologies - Argentina San Lorenzo 47, 3rd Floor, Office 5 Córdoba, Argentina *Mobile:* [+54 358 4827823 (ARG)] *Skype:* falberione ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Encoder Drivers
Hi, Could you link the PR please? Thanks Baptiste 2016-03-17 13:16 GMT+01:00 Marc : > Hi, > > sure, I'll try to push that in few days. > > Marc > > > On 2016-03-17 12:54, Emmanuel Baccelli wrote: >> >> Hi Marc, >> Could you PR this (as WIP, if needed)? >> Would be great. >> Cheers, >> Emmanuel >> >> On Mar 17, 2016 12:30 PM, "Marc" wrote: >> >>> On 2016-03-17 11:54, Loïc Dauphin wrote: >>> Le 17/03/2016 11:12, Marc a écrit : >>> No, it's not in the repository, but I can make it available for you >>> to >>> test. It is still in a Q&D state. >>> >>> Yes, it can be interesting. For stm32f4 ? >> >> >> I've been using it on lm4f120, but it's not specific to any hw... It >> only uses 2 gpio with interrupt. >> >> Marc >> ___ >> devel mailing list >> devel@riot-os.org >> https://lists.riot-os.org/mailman/listinfo/devel [1] >> >> >> Links: >> -- >> [1] https://lists.riot-os.org/mailman/listinfo/devel >> >> ___ >> devel mailing list >> devel@riot-os.org >> https://lists.riot-os.org/mailman/listinfo/devel > > ___ > devel mailing list > devel@riot-os.org > https://lists.riot-os.org/mailman/listinfo/devel -- Baptiste ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] PWM API change
Hej Marc, this seems like a pretty broken design to me, who knows what TI was thinking... Anyway, by looking at the datasheet, I think that the solution to this problem in this case is to map the values given via the RIOT PWM interface to internal values that make the PWM behave as expected. See section 20.4 how they configure a 25KHz PWM on top of a 20MHz CPU clock. The only thing that probably won't be as exact is the resolution (number of steps), as this must be rounded for this implementation. But just put a comment in the implementation about this. Or as an alternative: implement the PWM interface by using a GPT timer, those can be adjusted to the desired clock speed... Cheers, Hauke On 17.03.2016 12:59, Marc wrote: Hi, Maybe you're right... PWM on lm4f120 is done by configuring a timer for which there's no real prescaler and a match value that gives the duty cycle. The timer is 16bits, but can be extended to 20bits if needed. The timer is clocked by the system, so there's no way to fix a resolution and then pick a frequency (even within a given range): the resolution is the value loaded in the timer, and that corresponds to a frequency. Getting a 50Hz PWM with a 16Mhz clock requires the loading of 0x4E200 in the timer. As the API states that the PWM must preserve the resolution given in the _init(), I need to be able to pass this value. Of course, I could tweak the implementation and do some scaling on the values asked by the user (ie. compute the timer value needed for the required freq and scale all input from other function to match the real resolution), but that would not be ok with "In this case the PWM driver will always keep the resolution and decrease the frequency if needed.". In my case, this would mean the resolution is the real freq, which is not expected by the user. Cheers, Marc On 2016-03-17 12:33, Hauke Petersen wrote: Hi, I have to say that I don't quite understand the problem with the 16-bit max here. Is the timer on the lm4f120 limited to it's prescalers? For applications like controller servo motors 16-bit is normally still more than sufficient... So I think the key here lies in the PWM implementation, and not in changing the API... 'int' was actually not a very smart idea -> when moving an application that uses PWM from a 32-bit platform to a 16-bit platform it will break, without giving any hints to why. When using fixed values for low-level APIs, you always now exactly what you can work with, independent of the hardware you are using. Cheers, Hauke On 07.03.2016 13:33, dkm_riotos wrote: Hi! I'm cleaning a local port for lm4f120 and making new PR. I see that a recent commit changed/cleaned the PWM API. One of the changes includes limiting the resolution to 16bits (it was an int before, so 32bits in my case). Is there a motivation for limiting the value to 16bits ? In my case, the underlying timer can't be scaled but simply extended by a 8 bits . When I need some low frequency (eg. something suitable for driving a servo), I need to set the timer to something > 16bits. I see at least 2 possible fixes : - increase resolution to 32bits in the PWM API so that I can expose the real resolution. Having an 'int' here was not really bad in my opinion, as it was not forcing a size. Forcing 16bits param on a 32bits hw or 32bits param on a 16bits may cost more than simply using 'int'... - do some scaling on the resolution to be able to use the full range of the pwm while limiting the resolution to 16bits What should I do ? Thanks, Marc ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel [1] Links: -- [1] https://lists.riot-os.org/mailman/listinfo/devel ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Call for conn Task Force
Hey, On 03/16/2016 01:39 PM, Martine Lenders wrote: > our current conn API is not very beta at best. This is why I think we > need to re-discuss it. > > Anyone willing to join? I'd like to join. Kaspar ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Question regarding MBED-LPC1768 network drivers support.
> On 2016-03-18 13:05, Thomas Eichinger wrote: > Hi Fernando, > >the mbed-lpc1768 according to [1] doesn't have any network interfaces > as far as I see. Because of this there are no network drivers > implemented and ifconfig doesn't have anything to show. Do you use it > with any kind of extension board? Hi Thomas, Thanks for answering. I wanted to run the example using the mbed-lpc1768 ethernet device. It already has an integrated phy, so we just connected an rj-45 jack. Do you have support for ethernet devices in your stack? Regards, ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Call for conn Task Force
Hi, I'm not sure I'll be actually able to contribute, but I'd like to join the discussion and meetings. []'s, Bruno Melo. On Wed, Mar 16, 2016 at 9:44 AM, Kaspar Schleiser wrote: > Hey, > > On 03/16/2016 01:39 PM, Martine Lenders wrote: > > our current conn API is not very beta at best. This is why I think we > > need to re-discuss it. > > > > Anyone willing to join? > > I'd like to join. > > Kaspar > ___ > devel mailing list > devel@riot-os.org > https://lists.riot-os.org/mailman/listinfo/devel > ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] PWM API change
Hi, I have to say that I don't quite understand the problem with the 16-bit max here. Is the timer on the lm4f120 limited to it's prescalers? For applications like controller servo motors 16-bit is normally still more than sufficient... So I think the key here lies in the PWM implementation, and not in changing the API... 'int' was actually not a very smart idea -> when moving an application that uses PWM from a 32-bit platform to a 16-bit platform it will break, without giving any hints to why. When using fixed values for low-level APIs, you always now exactly what you can work with, independent of the hardware you are using. Cheers, Hauke On 07.03.2016 13:33, dkm_riotos wrote: Hi! I'm cleaning a local port for lm4f120 and making new PR. I see that a recent commit changed/cleaned the PWM API. One of the changes includes limiting the resolution to 16bits (it was an int before, so 32bits in my case). Is there a motivation for limiting the value to 16bits ? In my case, the underlying timer can't be scaled but simply extended by a 8 bits . When I need some low frequency (eg. something suitable for driving a servo), I need to set the timer to something > 16bits. I see at least 2 possible fixes : - increase resolution to 32bits in the PWM API so that I can expose the real resolution. Having an 'int' here was not really bad in my opinion, as it was not forcing a size. Forcing 16bits param on a 32bits hw or 32bits param on a 16bits may cost more than simply using 'int'... - do some scaling on the resolution to be able to use the full range of the pwm while limiting the resolution to 16bits What should I do ? Thanks, Marc ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
[riot-devel] Call for conn Task Force
Hi, our current conn API is not very beta at best. This is why I think we need to re-discuss it. I propose the foundation of a new Task Force for that matter, to get the best input from anyone involved. I already opened an issue to discuss the change [1], but I also would propose a F2F meeting (with the option for remote participation of course), since we made good experiences with the GNRC development by this. The details for this meeting are of course up to discussion as well for now. Anyone willing to join? Kind regards, Martine [1] https://github.com/RIOT-OS/RIOT/issues/5091 ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Encoder Drivers
Hi Marc, Could you PR this (as WIP, if needed)? Would be great. Cheers, Emmanuel On Mar 17, 2016 12:30 PM, "Marc" wrote: > On 2016-03-17 11:54, Loïc Dauphin wrote: > >> Le 17/03/2016 11:12, Marc a écrit : >> >>> No, it's not in the repository, but I can make it available for you to >>> test. It is still in a Q&D state. >>> >> >> Yes, it can be interesting. For stm32f4 ? >> > > I've been using it on lm4f120, but it's not specific to any hw... It only > uses 2 gpio with interrupt. > > Marc > ___ > devel mailing list > devel@riot-os.org > https://lists.riot-os.org/mailman/listinfo/devel > ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
