Re: [riot-devel] Easy ping
Then setup a task that runs ping. Marc Sissom Krypton Solutions -Original Message- From: devel [mailto:devel-boun...@riot-os.org] On Behalf Of Baptiste Clenet Sent: Friday, September 23, 2016 11:36 AM To: RIOT OS kernel developers <devel@riot-os.org> Subject: Re: [riot-devel] Easy ping Yes it would work, but I prefer a simple ping, two gnrc_networking running and one wants to ping the other one, that's all what I want. ICMPV6 is great because I don't need to deal with the request on the second board. 2016-09-23 18:30 GMT+02:00 Marc Sissom <msis...@krypton-solutions.com>: > I assume the device you are trying to reach has some purpose. If so send it a > purposeful packet. For example, you are running a web server on the device in > question, open a connection to port 80 with your telnet utility and talk to > it. > > > Marc Sissom > Krypton Solutions > > -Original Message- > From: devel [mailto:devel-boun...@riot-os.org] On Behalf Of Baptiste > Clenet > Sent: Friday, September 23, 2016 11:21 AM > To: RIOT OS kernel developers <devel@riot-os.org> > Subject: Re: [riot-devel] Easy ping > > Yes but it's not as easy as I want (shell command) Tell me the easiest > possible function to know if an address is reachable or not :-) > > 2016-09-23 17:56 GMT+02:00 Martine Lenders <m...@martine-lenders.eu>: >> Hi Baptiste, >> have you had a look at the implementation of the ping shell command? >> Another way would be to (re-)implement ping using conn_ip (or sock if >> merged). In that case, if you want it relly easy you don't even >> have to implement ICMPv6 ping but can do whatever you want ;-). >> >> Cheers, >> Martine >> >> 2016-09-23 17:18 GMT+02:00 Baptiste Clenet <bapcle...@gmail.com>: >>> Hi, >>> >>> How can I easily ping a board by software (without using shell) so I >>> ping( IPV6_address) and I get -1 for error (not reachable) or 0 for >>> success? >>> >>> Cheers, >>> >>> -- >>> Baptiste >>> ___ >>> 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 > ___ > 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 ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Easy ping
I assume the device you are trying to reach has some purpose. If so send it a purposeful packet. For example, you are running a web server on the device in question, open a connection to port 80 with your telnet utility and talk to it. Marc Sissom Krypton Solutions -Original Message- From: devel [mailto:devel-boun...@riot-os.org] On Behalf Of Baptiste Clenet Sent: Friday, September 23, 2016 11:21 AM To: RIOT OS kernel developers <devel@riot-os.org> Subject: Re: [riot-devel] Easy ping Yes but it's not as easy as I want (shell command) Tell me the easiest possible function to know if an address is reachable or not :-) 2016-09-23 17:56 GMT+02:00 Martine Lenders <m...@martine-lenders.eu>: > Hi Baptiste, > have you had a look at the implementation of the ping shell command? > Another way would be to (re-)implement ping using conn_ip (or sock if > merged). In that case, if you want it relly easy you don't even > have to implement ICMPv6 ping but can do whatever you want ;-). > > Cheers, > Martine > > 2016-09-23 17:18 GMT+02:00 Baptiste Clenet <bapcle...@gmail.com>: >> Hi, >> >> How can I easily ping a board by software (without using shell) so I >> ping( IPV6_address) and I get -1 for error (not reachable) or 0 for >> success? >> >> Cheers, >> >> -- >> Baptiste >> ___ >> 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 ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] qemu-i386 port
[ek-lm4f120-xl board can't be bought anymore, only its replacement TivaC can (and it is not supported by RIOT, at least at the moment)] It is actively maintained... sort of. I have the feeling that no RIOT developer has time for it. It is not listed on the RIOT wiki and it is hard to find someone with time and hw. If that's considered normal, then so be it and I'll happily continue to ping my PRs from time to time. I may even contribute a wiki page for it :) Sorry if this subject is considered OT, Cheers, Marc August 9 2016 2:30 PM, "Ludwig Knüpfer" <ludwig.knuep...@fu-berlin.de> wrote: > Hi, > > Without any further insights I would say your case is different because the > board is actively > maintained, used, and can be bought. > In the case of the FU boards I had in mind (msb430*) none of these points is > true. > > Cheers, > Ludwig > > Am 9. August 2016 14:21:44 MESZ, schrieb Marc <dkm+rio...@kataplop.net>: > >> Hey, >> >> This discussion is also related to >> https://github.com/RIOT-OS/RIOT/pull/5412#issuecomment-237688208 >> I'm trying to enhance support for ek-lm4fxl-120 board, which is not as >> popular as stm boards... >> It's a bit complicated to find reviewers with some extra time for >> reviewing, and even more for hardware testing... >> >> Would it be possible to have an in-between set of boards (between "well >> supported/tested" and "in >> the trash") ? Where reviewers could omit the hardware tests for example >> and rely on the "community" >> to do such tests ? >> >> I must admit that having to spend several weeks for each small PR is a >> bit frustrating, but I fully >> understand that nobody really cares about this board. If this is not >> possible, then maybe you're >> right and boards that can't be maintained should be ditched. People can >> still maintain their own >> fork (what I'll probably do for TivaC board). >> >> Marc >> >> August 9 2016 2:06 PM, "Ludwig Knüpfer" <ludwig.knuep...@fu-berlin.de> >> wrote: >> >>> Hi, >>> >>> I'm all for cleaning up stale boards, especially I'd they are as hard >> >> to obtain as for example the >>> FU boards. >>> If I'm not mistaken this would also enable the removal of at least >> >> one legacy driver interface (I >>> have some GPIO API in mind). >>> >>> Cheers, >>> Ludwig >>> >>> Am 9. August 2016 13:52:56 MESZ, schrieb "Joakim Nohlgård" >> >> <joakim.nohlg...@eistec.se>: >>>> I agree with dropping qemu-i386 >>>> >>>> On the same subject, would it make sense to clean up some other >> >> boards >>>> with less than ideal support? >>>> chronos is one board which I frequently run into trouble with >> >> because >>>> it is never up to date with the other platform implementations, >>>> especially the stdio is very hacky on that board. >>>> >>>> /Joakim >>>> >>>> On Aug 9, 2016 12:51, "Martine Lenders" <m.lend...@fu-berlin.de> >> >> wrote: >>>>> Hi, >>>>> we now have the third person wondering about the qemu-i386 port. >> >> Fact >>>>> is, it doesn't work (we do not even have the unittests activated >>>>> anymore). Is there a reason why we did not drop it yet (except >> >> making >>>>> all the good work by René void)? Or are we planning to provide >> >> better >>>>> support for it in the future? >>>>> >>>>> Cheers, >>>>> Martine >>>>> ___ >>>>> 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 >> >> ___ >> 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] qemu-i386 port
Hey, This discussion is also related to https://github.com/RIOT-OS/RIOT/pull/5412#issuecomment-237688208 I'm trying to enhance support for ek-lm4fxl-120 board, which is not as popular as stm boards... It's a bit complicated to find reviewers with some extra time for reviewing, and even more for hardware testing... Would it be possible to have an in-between set of boards (between "well supported/tested" and "in the trash") ? Where reviewers could omit the hardware tests for example and rely on the "community" to do such tests ? I must admit that having to spend several weeks for each small PR is a bit frustrating, but I fully understand that nobody really cares about this board. If this is not possible, then maybe you're right and boards that can't be maintained should be ditched. People can still maintain their own fork (what I'll probably do for TivaC board). Marc August 9 2016 2:06 PM, "Ludwig Knüpfer" <ludwig.knuep...@fu-berlin.de> wrote: > Hi, > > I'm all for cleaning up stale boards, especially I'd they are as hard to > obtain as for example the > FU boards. > If I'm not mistaken this would also enable the removal of at least one legacy > driver interface (I > have some GPIO API in mind). > > Cheers, > Ludwig > > Am 9. August 2016 13:52:56 MESZ, schrieb "Joakim Nohlgård" > <joakim.nohlg...@eistec.se>: > >> I agree with dropping qemu-i386 >> >> On the same subject, would it make sense to clean up some other boards >> with less than ideal support? >> chronos is one board which I frequently run into trouble with because >> it is never up to date with the other platform implementations, >> especially the stdio is very hacky on that board. >> >> /Joakim >> >> On Aug 9, 2016 12:51, "Martine Lenders" <m.lend...@fu-berlin.de> wrote: >>> Hi, >>> we now have the third person wondering about the qemu-i386 port. Fact >>> is, it doesn't work (we do not even have the unittests activated >>> anymore). Is there a reason why we did not drop it yet (except making >>> all the good work by René void)? Or are we planning to provide better >>> support for it in the future? >>> >>> Cheers, >>> Martine >>> ___ >>> 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 ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Encoder Drivers
Here it is. https://github.com/RIOT-OS/RIOT/pull/5168 I've tested it locally and it seems to be ok. Keep in mind that's a first draft, so there are most probably lots of bugs... Marc On 2016-03-23 13:50, Marc wrote: Sorry again for the delay. I've started to extract the code from my prototype and I should be able to push it tomorrow for WIP/review. Marc On 2016-03-18 18:33, Marc wrote: 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 <dkm+rio...@kataplop.net>: 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" <dkm+rio...@kataplop.net> 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 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 ___ 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 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] 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" <dkm+rio...@kataplop.net> 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 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] PWM API change
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
Re: [riot-devel] PWM API change
On 2016-03-18 12:01, Hauke Petersen wrote: Hej, I think my datasheet was from the TM4C123GH6PZ, I thought this is just the re-branded lm4f120xl... While the base timer clock speed is not configurable, the timer does have a pre-scale register, right? Can't we use that to change the timers freq? If not, I would say just adapt the freq to the wanted value and basically ignore the resolution parameter. This should suffice when implementing the PWM interface... Yes, there is a "prescaler" register, which is in fact a simple extension of the timer by 4 bits. It's a pitty these bits are the high bits and that the register is counting down... So, if it's ok, I'll workaround the API doc and do some scaling on the resolution... Thanks for your help ! Marc ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Overriding SPI speeds + gadgets drivers
On 29-01-2016 14:03, Kaspar Schleiser wrote: Hey, On 01/29/2016 01:56 PM, Marc wrote: I would like to drive the SPI at speeds currently not in the enum types. What would be the best approach (ie. what would be accepted in a pull request) : - adding extra speeds to the global enum Sounds the most sensible. Also, I'm wondering if RIOT has any rule for accepting new drivers. I have been playing with small LCD, ws2812, mm5450, 7segments displays and I'm wondering if I should try to make something clean for creating a PRs ? I see that's devs are already flooded by more important PR, so maybe you simply don't want these extra "gadgets". Sure, keep 'em coming! One problem with drivers will always be that it's not possible to test them if the hardware is not around. But if the PR looks OK (adheres to RIOT's conventions and style), we'll merge it anyways. Hey :) I was really willing to create new PRs, but I'm still stuck with a PR that's few months old now (#4392) because I guess there's no time for this (and I 100% understand that). I was asked to create separate PR for each periphs (GPIO PR has been started en of nov, I still have pwm and spi waiting in my queue). What is expected for not-so-common boards (like the ek-lm4f120-xl ?) ? Should I wait for someone to ping the PR and tell me what's missing/expected ? Should I continue to rebase it even if no-one has time for this ? I could also group everything together (GPIO, SPI, PWM) so that when someone has few minutes to review it, everything can be done at once ? The smaller divers (lcd, ws2912, mm5450) need a big cleaning before a PR can be pushed, so I don't really want to spend time on this if there is technically no time for reviewing... And I guess that having PR created then going to "unmaintained" state is not wanted by RIOT. Thanks ! Marc ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
[riot-devel] Overriding SPI speeds + gadgets drivers
Hi ! I would like to drive the SPI at speeds currently not in the enum types. What would be the best approach (ie. what would be accepted in a pull request) : - adding extra speeds to the global enum - using a macro HAVE_SPI_SPEED_FOO (as done in gpio driver) and let specific cpu override it as needed ? Let me know what's best and I'll create a PR (provided that you are ok with the request of adding extra speeds...) Also, I'm wondering if RIOT has any rule for accepting new drivers. I have been playing with small LCD, ws2812, mm5450, 7segments displays and I'm wondering if I should try to make something clean for creating a PRs ? I see that's devs are already flooded by more important PR, so maybe you simply don't want these extra "gadgets". Marc ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
