Re: [riot-devel] Ceedling

[Attilio Dona]

Some time ago I managed to write some tests with Unity.

It is not difficult to integrate into RIOT build system.

As prerequisite you need ruby (sudo apt install ruby) and Unity installed
somewhere (/opt/Unity-master)


My opinionated recipe was to create the module libunity (and libcmock):

sys
├── libunity
│   ├── Makefile
│   └── unity.c
 |── libcmock
│   ├── cmock.c
│   ├── cmock.h
│   ├── cmock_internals.h
│   └── Makefile

and to use a tests/Makefile.include like this for auto generating the main
test file:

APPLICATION = unity

BOARD ?= cc3200-launchxl
BURBA ?= $(CURDIR)/../..
RIOTBASE ?= $(BURBA)/RIOT

UNITY_ROOT ?= /opt/Unity-master

QUIET ?= 1

INCLUDES += -I$(CURDIR)/../../sys/mqtt -I$(BURBA)/sys/protobuf-c


USEMODULE += libunity
USEMODULE += libcmock

...


all: auto_main.c

full-clean: clean
@rm -rf main.c

auto_main.c: test_cases.c
ruby $(UNITY_ROOT)/auto/generate_test_runner.rb $? $@


include $(BURBA)/Makefile.include


I have adjusted my old code to the current Unity version (NOTE: libcmock
module is not updated!), see:

https://github.com/attdona/NAIS/tree/master/burba/tests/xtimer


Greetings
Attilio



On Wed, Jan 10, 2018 at 9:17 PM, Martine Lenders 
wrote:

> Hi Francisco,
>
> as far as I know Cenk looked into that a few months back. I don't know
> however what came out of that?
>
> Cheers,
> Martine
>
> 2018-01-10 21:10 GMT+01:00 Francisco Molina :
>
>> Following up with Baptiste question. Has anyone integrated other testing
>> tools into RIOT like Unity?. And how easily (or not) could this integration
>> be achieved, how much tinkering with the actual build system would have to
>> be done for this? Cheers!
>>
>> Francisco
>>
>> ___
>> 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] OpenOCD threads support

[Attilio Dona]

Hi Vincent,

just a quick "black box" test ...
openocd master branch with patch 4256 works on my board (cc3200-launchxl)

Waiting to see this patch merged!
Greetings
Attilio


Open On-Chip Debugger 0.10.0+dev-00199-g667cf951 (2017-10-17-19:45)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
main () at /home/adona/ZAKKE/NAIS/burba/apps/hello-world/main.c:27
27 puts("Hello World!");
Loading section .text, size 0x38f8 lma 0x20004000
Loading section .data, size 0x88 lma 0x200078f8
Start address 0x20004000, load size 14720
Transfer rate: 7 KB/sec, 7360 bytes/write.
Breakpoint 1 at 0x200056aa: file
/home/adona/ZAKKE/NAIS/burba/apps/hello-world/main.c, line 27.
[New Thread 1]
[Switching to Thread 2]

Thread 1 hit Breakpoint 1, main () at
/home/adona/ZAKKE/NAIS/burba/apps/hello-world/main.c:27
27 puts("Hello World!");
(gdb) info threads
  Id   Target Id Frame
* 1Thread 2 (Name: main, Running) main () at
/home/adona/ZAKKE/NAIS/burba/apps/hello-world/main.c:27
  2Thread 1 (Name: idle, Pending) idle_thread (arg=0x0) at
/home/adona/ZAKKE/NAIS/burba/RIOT/core/kernel_init.c:64
(gdb)





On Tue, Oct 17, 2017 at 10:42 AM, Vincent Dupont 
wrote:

> Hi all,
>
> A few months ago @daniel-k worked on RIOT support in OpenOCD ([1], [2]).
> The patch on OpenOCD side has never been merged and was quite outdated. So
> I took the freedom (after checking with Daniel ;) to update it and reopen a
> PR on OpenOCD [3].
> It would be great if some of you could help testing and reviewing to have
> this merged!
>
> Cheers,
>
> Vincent
>
> [1] https://github.com/RIOT-OS/RIOT/pull/4058
> [2] http://openocd.zylin.com/#/c/3000/
> [3] http://openocd.zylin.com/#/c/4256/
>
> --
> *Vincent Dupont*
>
> ___
> 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] About CC3200 RF support in RIOT OS

[Attilio Dona]

Hi Ameya and Adarsh,

I've just published the NAIS project:

https://github.com/attdona/NAIS

Look the burba dir for the cc3200 launchpad support for RIOT:

inside burba/apps/tcp-simple-client there is a minimal demo example.

A lot of work has to be done, but I hope this is enough to get started.

Greetings
Attilio


On Tue, Jun 6, 2017 at 1:10 PM, Ameya Joshi <jo...@smartron.com> wrote:

> Hi Attilio,
>
> That's Great..!!
>
> An OS adaptation layer for CC3200 simple link driver which you have
> written, is it working properly?
>
> If you have created a github project with the same, can you share me the
> link?
>
> Thanks,
> Ameya Joshi
>
>
> On Tue, Jun 6, 2017 at 2:19 PM, Attilio Dona <attilio.d...@gmail.com>
> wrote:
>
>> Hy Ameya,
>>
>> nice to meet you
>>
>> You need to write an OS adaptation layer for cc3200 simple link driver if
>> you want use wifi.
>>
>> Some time ago I wrote a preliminary adaptation layer but I did not share
>> publicly.
>>
>> Please let me understand if I can share something useful, I'm thinking
>> about creating a github project with the sw for cc3200.
>>
>> greetings
>> Attilio
>>
>>
>>
>>
>>
>>
>> On Thu, Jun 1, 2017 at 3:57 PM, Ameya Joshi <jo...@smartron.com> wrote:
>>
>>> Hi,
>>>
>>> I am Ameya.
>>>
>>> I want to use CC3200 with RIOT OS but not only for Flashing purpose.
>>>
>>> I want CC3200 to connect to the Access Point using RIOT OS & I don't want 
>>> to use any IDE like Code Composer Studio.
>>>
>>> Is there support for CC3200 RF drivers in RIOT ? If not, how to port RF 
>>> drivers for CC3200 in RIOT so that it Should Connect to the Access point.?
>>>
>>>
>>> --
>>> Ameya Joshi,
>>> Hyderabad, Telangana, India.
>>>
>>>
>>> ___
>>> 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] About CC3200 RF support in RIOT OS

[Attilio Dona]

Hy Ameya,

nice to meet you

You need to write an OS adaptation layer for cc3200 simple link driver if
you want use wifi.

Some time ago I wrote a preliminary adaptation layer but I did not share
publicly.

Please let me understand if I can share something useful, I'm thinking
about creating a github project with the sw for cc3200.

greetings
Attilio






On Thu, Jun 1, 2017 at 3:57 PM, Ameya Joshi  wrote:

> Hi,
>
> I am Ameya.
>
> I want to use CC3200 with RIOT OS but not only for Flashing purpose.
>
> I want CC3200 to connect to the Access Point using RIOT OS & I don't want to 
> use any IDE like Code Composer Studio.
>
> Is there support for CC3200 RF drivers in RIOT ? If not, how to port RF 
> drivers for CC3200 in RIOT so that it Should Connect to the Access point.?
>
>
> --
> Ameya Joshi,
> Hyderabad, Telangana, India.
>
>
> ___
> 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] Support for cc3200

[Attilio Dona]

Just few considerations, I hope they are useful

I implemented the WLAN support using the Texas Instrument simplelink driver.

It is something I never shared because it worked fine for me but it was not
a state of the art piece of software, it lacks review and clean up ...

My approach was to implements a RIOT module that manages the communication
with the cc3200 network wifi processor.

Just to render the idea, this is the .h interface module:

https://gist.github.com/attdona/b9f2169b4adf5e71e03406b91d4c78e6

Greetings
Attilio


On Fri, May 19, 2017 at 8:00 AM, Härtinger Markus 
wrote:

> Hi
>
> We are currently developing an WIFI support in RIOT-OS for the CPU cc3200.
>
> Our implementation is based on the code of Attilio Donà and the vendor
> libraries of Texas Instruments.
>
>
>
> After the first hardware support for this CPU currently we try to
> implement the WLAN support.
>
> For this goal we have some questions:
>
> -  Is there already an implementation for any WLAN  IEEE-802.11
> CPU in RIOT-OS
>
> -  Is there an IPv4 support or only IPv6
>
> -  Is it correct that it is only necessary to wirte the
> cc3200_netdev.c-File.
>
>
>
> Thanks for your help and tips.
>
>
>
>
>
> Best Regards
>
>
>
> Markus Härtinger
>
>
>
> ___
> 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, Windows, and Code Composer Studio

[Attilio Dona]

Hi Clark,

I attach an image that gives some more details, basically you have to
import RIOT as a ccs project (choose GNU compiler version), then configure
the CCS build page with the build command:

make BOARD= QUIET=0

see the screenshot for some other details.

I don't know the details of your project, the compiler you use, ecc ecc,
but I hope this may help you to go in the right direction.

Attilio



On Thu, Jun 23, 2016 at 3:34 PM, Clark Leach <clark.le...@gmail.com> wrote:

> I don't suppose you want to share details?
>
>
> On Wed, Jun 22, 2016 at 5:28 AM, Attilio Dona <attilio.d...@gmail.com>
> wrote:
>
>> Hi Clark,
>>
>> What CCS version are you using?
>> In the past there was problems integrating the RIOT build system with CCS.
>>
>> I have just successfully tested a RIOT environment on windows with the
>> latest (6.1.3).
>>
>> It is not difficult to setup a build configuration pointing to the RIOT
>> makefile.
>>
>> Good tweakings
>> Attilio
>>
>> On Mon, Jun 20, 2016 at 4:55 PM, Emmanuel Baccelli <
>> emmanuel.bacce...@inria.fr> wrote:
>>
>>> Caeveat: coma at the end url may mess up your automatic URL detection
>>> thingie:
>>> https://github.com/RIOT-OS/RIOT/wiki/Using-the-Eclipse-IDE-for-C-and-CPP-Developers,-
>>> Howto
>>> On Jun 20, 2016 4:49 PM, "Emmanuel Baccelli" <emmanuel.bacce...@inria.fr>
>>> wrote:
>>>
>>>> Hi there
>>>>
>>>> I don't know how complete and up to date that is but there is also:
>>>>
>>>> https://github.com/RIOT-OS/RIOT/wiki/Using-the-Eclipse-IDE-for-C-and-CPP-Developers,-
>>>> Howto
>>>>
>>>> Cheers
>>>> Emmanuel
>>>> On Jun 20, 2016 4:39 PM, "Francisco Javier Acosta Padilla" <
>>>> francisco.aco...@inria.fr> wrote:
>>>>
>>>>> Hi Clark!
>>>>>
>>>>> I’m not using CCS but Eclipse, although I use it only for editing
>>>>> code, it is possible to use it for compiling, flashing and debugging (in
>>>>> experimental phase).
>>>>>
>>>>> As for today, we don’t have a very complete guide on how to do it in
>>>>> RIOT, but there is a guide[1] for Contiki, which can be extended to RIOT.
>>>>> The guide assumes the use of GCC for compiling…
>>>>>
>>>>> Anyone knows if we can support other compilers? IMO it’s a matter of
>>>>> changing the prefixes of the compiler in the Makefile, but maybe some 
>>>>> flags
>>>>> can differ...
>>>>>
>>>>> I hope it helps.
>>>>>
>>>>> Cheers,
>>>>>
>>>>>
>>>>> [1] https://github.com/Zolertia/Resources/wiki/Eclipse
>>>>>
>>>>>
>>>>> --
>>>>> Francisco Javier Acosta Padilla
>>>>> Research Engineer at INRIA Saclay
>>>>> INFINE Team
>>>>>
>>>>> On 20 June 2016 at 16:22:03, Ludwig Knüpfer (
>>>>> ludwig.knuep...@fu-berlin.de) wrote:
>>>>>
>>>>> Hi Clark,
>>>>>
>>>>> I am not aware of anyone using CCS.
>>>>> In my perception most of us are Linux based and don't even use Eclipse.
>>>>>
>>>>> Cheers,
>>>>> Ludwig
>>>>>
>>>>> Am 20. Juni 2016 15:59:29 MESZ, schrieb Clark Leach <
>>>>> clark.le...@gmail.com>:
>>>>> >Nothing? Really?
>>>>> >
>>>>> >On Tue, Jun 14, 2016 at 2:43 PM, Clark Leach <clark.le...@gmail.com>
>>>>> >wrote:
>>>>> >
>>>>> >> I am intersted in developing with RIOT for a few different TI
>>>>> targets
>>>>> >and
>>>>> >> have Code Composer Studio installed on Windoze 8.1 which I have used
>>>>> >for
>>>>> >> several projects. Since CCS already has all the tool chains and
>>>>> >debugger
>>>>> >> interfaces, it seems like it would make sense to use it for these
>>>>> >projects
>>>>> >> as well.
>>>>> >>
>>>>> >> Is there any hope of making such a configuration work? Is there any
>>>>> >> guidance available? I have read the howto on using Eclipse and found
>>>>> >the
>>>>> >> info

Re: [riot-devel] Question about RIOT/tests/thread_msg

[Attilio Dona]

Hi Jianwen,

thread_msg does a context switch between p3 and p1 because p1 does not have
a message queue.
The second message from p3 causes p3 to go into a blocked state and give up
control otherwise the previous message will be lost.

if in p1 a msg_queue is defined:


void *thread1(void *arg)
{
(void) arg;

msg_t msg_queue[8];
msg_init_queue(msg_queue, 8);


puts("THREAD 1 start\n");
...

then thread_msg example will run as documented until the message queue is
full.

I hope this little explanation may help ...

ciao
Attilio




On Thu, Mar 31, 2016 at 10:35 AM, OuyangJianwen 
wrote:

> Hello,
>
> I am a new beginner to learn RIOT. I got some question when I run the
> "thread_msg" on board "SAMR21-xpro".
>
> For the thread1, thread2 and thread3, they have the same priority. so when
> the thread3 is running, how can scheduler switch to the thread1.
>
> I saw these in the API:
> "In case of equal priorities, the threads are scheduled in a
> semi-cooperative fashion. That means that unless an interrupt happens,
> threads with the same priority will only switch due to voluntary or
> implicit context switches."
> and
> "Some functions that unblock another thread, e.g. msg_send()
> 
> or mutex_unlock()
> ,
> can cause a thread switch, if the target had a higher priority."
>
> but here, all the three threads have the same priority, so according the
> rule, even there is msg_send()
> ,
> the thread3 should not be blocked and run forever, but it doesn't.
>
> Thanks for your time!
>
> Regards,
> Jianwen OUYANG
>
>
>
> ___
> 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] Low-power WAN

[Attilio Dona]

Hi All, Hi Dinh [ thanks for the citation :) ]

To be precise I'm not yet porting RIOT to cc1310 ... nevertheless I'm very
interested into the cc13xx new chips family and I'm trying to evaluate this
first part in detail.

ciao
Attilio




On Fri, Dec 11, 2015 at 2:55 PM, Nguyễn Quốc Đính 
wrote:

> Hello,
>
> I used to play around with subghz soc ADUCRF101 from Analog device, which
> gives much longer range compare to 2.4Ghz. For me, this SoC shows value in
> some area, say, farm. It actually does not belong to some protocols listed
> in article cited by Prof Emmanuel, it can run conventional 6lowpan.
> ADUCRF101 powered with cortex m3, then not so hard to run with RIOT.
>
> Attilio Donà mentioned that he is porting the recent CC1310 from TI. Lets
> invite him to declare here :).
>
> Dinh.
>
>
> On 11/12/2015 20:08, Jon Pattison wrote:
>
> Emmanuel,
>
> Thanks for sharing the article.
>
> We are always looking for lower power and longer range. I'm sure we'll be
> doing something in this area soon.
>
> Jon Pattison
> Kubos Corporation
>
> On 12/11/2015 03:57 AM, Emmanuel Baccelli wrote:
>
> Hi everyone,
>
> while so far most of us here are interested in shorter range radios (as
> far as I know), there is this recent push towards low-power long-range
> technologies of various types. I stumbled over this blunt, high-level
> survey [1] of the current state of affairs in that domain, I thought it
> might be relevant to share here.
>
> One question: is anyone working with some such wireless technology with
> RIOT, or planning to in the near future?
>
> cheers,
>
> Emmanuel
>
> [1] http://www.eejournal.com/archives/articles/20150907-lpwa/
>
>
>
>
> ___
> devel mailing 
> listdevel@riot-os.orghttps://lists.riot-os.org/mailman/listinfo/devel
>
>
>
>
> ___
> devel mailing 
> listdevel@riot-os.orghttps://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] RIOT os and CC430

[Attilio Dona]

Hi Viktor,

first a disclaimer:

It is a lot of time that I don't work with msp430 silicon, so my knowledge
it is not up to date,
so please take this a a starting point: I think a RIOT msp430 maintainer
could make a more clean and polite job than me,
and I think it would be a GREAT thing.

Now some info and a recipe to try get a working RIOT port to "the new"
msp-elf-gcc.

I have arranged a build for chronos board with the fork:

https://github.com/attdona/RIOT (some minor patches about removing
duplicated types definition and the new msp430 gcc ISR syntax)

and with the following compiler version (not mandatory, just for
reference):

msp430-elf-gcc -v
Using built-in specs.
COLLECT_GCC=msp430-elf-gcc
COLLECT_LTO_WRAPPER=/usr/local/gcc-msp430-elf-dev-20141215/libexec/gcc/msp430-elf/5.0.0/lto-wrapper
Target: msp430-elf
Configured with: /home/attilio/MIOT/gcc_repo/gcc/configure
--prefix=/usr/local/gcc-msp430-elf-dev-20141215 --target=msp430-elf
--with-newlib --enable-languages=c
Thread model: single
gcc version 5.0.0 20141105 (experimental) (GCC)

The ugly part it is that I needed to patch the compiler !!!

You will find the instructions into cpu/msp430-common/gcc-patch/README.md

I've just verified that the platform build successfully but I have not
tested the fw.

Let me know if it works for you.

ciao
Attilio



On Thu, Oct 29, 2015 at 7:35 PM, Viktor Váczi 
wrote:

> Hi!
> I try to port riot to CC430F5137 using a panstamp board (
> http://www.panstamp.com/product/197/ ). I didn't have any luck with the
> old msp430debug package which i've found in the latest ubuntu. The first
> thing I've tried to do is to get a simple UART example working, but when
> I've tried to enable the interrupts with:
>  __bis_SR_register(LPM0_bits + GIE);   // Enter LPM0, interrupts
> enabled
> the whole thing freezed. I guess that some other kind of interrupt happens
> all the time, but I haven't been able to debug it ( yet ).
> So I've started using TI's / redhat's gcc compiler, and it worked just ok
> ( under windows ). So I've moved on to this compiler, which I've installed
> by this tutorial:
> http://www.simplyembedded.org/tutorials/compile-install-msp430-gcc/
> I've tried to use chronos version for the first time, I've deleted all the
> LCD headers, and modified stdio.h a little bit, so it doesn't looks for
> these kind of files. The compilation worked previously with the obsolete
> mspgcc, so that worked somewhat.
> Now when I do BOARD=chronos make then it doesn't finds msp430-gcc. So I've
> moved everything from opt/msp430-toolchain/bin ( the place where I've
> installed the new TI mspgcc ) to bin, so it found the new mspgcc compiler.
> Now it was missing the header file, I've modified the makefile.include so
> it found it now. There were some missing stuff , but I've solved these
> problems, but now I have this error:
> as: unrecognized option '-mP'
> I've did a verbose output with make -n, this came out:
> http://pastebin.com/BDQjdaJG
> I have found -mP but only with msp430-gcc, and there is no as program as
> far as I know, so I doesn't really understand this.
>
> My first question is: how to install this compiler properly, so that
> whenever I use msp430-gcc then this new compiler will be called? I've also
> tried to use the installersh file from ti, but it doesn't install it to
> /bin or anything in the $PATH so I can't use it with the current makefiles.
> The current solution is.hmm kind of ugly and doesn't works :)
>
> The second question: Should I use the obsolete ti compiler instead? What
> causes this bug?
>
> The third one is: What is this as / -mp thing?
>
> Thanks for any help, and sorry for my ugly English.
> Viktor
>
>
> ___
> 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] OpenOCD-RTOS support for RIOT

[Attilio Dona]

Great job Daniel

Just to report that I've tested OCD with this patch on TI cc3200 with a to
be merged RIOT port [1] into mainstream and it works.

[1] https://github.com/attdona/RIOT

Cheers
Attilio





On Thu, Oct 15, 2015 at 6:58 PM, Daniel Krebs  wrote:

> Dear fellow RIOTing developers,
>
> OpenOCD-RTOS support is coming to RIOT but needs your help. But first what
> am I talking about?
>
> When debugging a RIOT application via GDB you will be able to get an
> overview of all running threads and their states:
>
>> (gdb) info threads
>> [New Thread 2]
>> [New Thread 3]
>>   Id   Target Id Frame
>>   3Thread 3 (at86rfxx :  : Blocked receive) 0x4104 in
>> _msg_receive (m=m@entry=0x2f00 <_lwmac_stacks+860>, block=block@entry=1)
>> at .../RIOT/core/msg.c:329
>>   2Thread 2 (main :  : Blocked mutex) mutex_lock 
>> (mutex=mutex@entry=0x2a6c
>> ) at .../RIOT/core/mutex.c:53
>> * 1Thread 1 (idle :  : Running) lpm_arch_set 
>> (target=target@entry=LPM_IDLE)
>> at .../RIOT/cpu/samd21/lpm_arch.c:98
>>
>
> You can switch the current thread and investigate the stackframe:
>
>> (gdb) thr 2
>> [Switching to thread 2 (Thread 2)]
>> #0  mutex_lock (mutex=mutex@entry=0x2a6c ) at
>> .../RIOT/core/mutex.c:53
>> (gdb) bt
>> #0  mutex_lock (mutex=mutex@entry=0x2a6c ) at
>> .../RIOT/core/mutex.c:53
>> #1  0x2c96 in _xtimer_sleep (offset=396000,
>> long_offset=long_offset@entry=0) at .../RIOT/sys/xtimer/xtimer.c:53
>> #2  0x0fa4 in xtimer_usleep (offset=) at
>> .../RIOT/sys/include/xtimer.h:487
>> #3  main () at .../main.c:79
>>
>
> All you need to get this working is my yet unmerged PR [1] in RIOT and a
> modified version of OpenOCD. But the OpenOCD patches need reviewing at
> their code review tool and I was told to send some RIOT developers to
> actually do that reviewing because nobody @ OpenOCD is using RIOT. So to
> get this upstream please head over to their Gerrit [2] and do the reviewing
> if you want this feature.
> You can directly login with your Github account via OAuth here [3].
>
> To test this on your system you need to compile OpenOCD yourself:
>
> $ git clone https://github.com/daniel-k/openocd.git
> $ cd openocd
> $ git checkout riot_patched
> $ ./bootstrap
> $ ./configure
> $ sudo make install
>
> Then merge my PR to your code and try it out.
>
> Cheers,
> Daniel
>
> [1] https://github.com/RIOT-OS/RIOT/pull/4058
> [2] http://openocd.zylin.com/#/c/3000/
> [3]
> http://openocd.zylin.com/login/%23%2Fregister%2Fq%2Fstatus%3Aopen?id=gerrit-oauth-provider_-github-oauth
> ___
> 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 preview for TI cc3200

[Attilio Dona]

Dear RIOTers

I'm proud to announce that I have just completed a working version for
cc3200 chip on launchpad board.

There are a mqtt client and an httpserver demo, ported from TI SDK original
examples, under RIOT/examples directory (for sure not the right place but I
don't know a better place for the cc3200 specific examples app)

Now I'm going to create the PR ...

Attilio









On Mon, Sep 28, 2015 at 8:22 AM, Peter Kietzmann <
peter.kietzm...@haw-hamburg.de> wrote:

> Hi Attilio,
>
> nice! Looking forward to see you PR ;-) .
>
> Best,
> Peter
>
>
> Am 25.09.2015 um 14:27 schrieb Attilio Dona:
>
> Ok,
>
> just for sharing a little roadmap I'm starting to work on the wifi module
> integration.
>
> I need a little bit of time for this task, I think some weeks.
>
> Could make sense create a PR after the completion of this task?
>
> Let me know!
>
> greetings
> Attilio
>
>
> ps. For shell echoing I needed to apply the following patch to
> shell/shell.c (I think this affect all systems that use newlib)
>
> @@ -256,6 +256,9 @@ static int readline(char *buf, size_t size)
>  else {
>  *line_buf_ptr++ = c;
>  _putchar(c);
> +#ifdef MODULE_NEWLIB
> +fflush(stdout);
> +#endif
>  }
>  }
>  }
>
>
>
>
>
>
>
> On Thu, Sep 24, 2015 at 1:29 PM, Hauke Petersen <
> hauke.peter...@fu-berlin.de> wrote:
>
>> Hej,
>>
>> On 03.09.2015 23:22, Attilio Dona wrote:
>>
>> Ciao Kaspar,
>>
>> I agree with RIOT philosophy, so a rewrite could be a nice thing, but I
>> also think that this is not a top priority now, at least for me ...
>>
>> If someone else wants to contribute it would be great!
>>
>> One more thing to consider is that cc3200 has:
>>
>>
>>- 256 Kb of RAM
>>- an external SD serial flash card memory where to flash the image
>>- an internal ROM memory burned into the chip that hosts the
>>bootloader and the driverlib "ROM version" (directly from factory)
>>
>> So from version ES1.33 it seems possible to link to the ROM version of
>> driverlib for resource optimizations (so could be a waste to throw away the
>> driverlib API?)
>>
>> IMHO that is exactly what we do!
>>
>> @kaspar: in this particular case (as for the LM4F120 launchpad board) it
>> makes very much sense to use the provided hardware abstraction to implement
>> RIOTs periph interfaces, as the code used by this HAL layer is burned into
>> read-only ROM directly on the CPU and thus does not use any additional
>> memory...
>>
>> Cheers,
>> Hauke
>>
>>
>>
>>
>> I have not tested this setup yet, but I think could be a trail to do.
>>
>> Attilio
>>
>>
>>
>> On Wed, Sep 2, 2015 at 9:36 AM, Kaspar Schleiser < <kas...@schleiser.de>
>> kas...@schleiser.de> wrote:
>>
>>> Hey Attilio,
>>>
>>> Thanks a lot for your effort on getting this board supported!
>>>
>>> On 09/01/15 21:32, Attilio Dona wrote:
>>> > I need just some confirmation, the most important is
>>> > that driverlib from TI is license compatible with RIOT
>>> > (cpu/cc32000/driverlib and cpu/cc3200/inc files used as HAL for the
>>> > drivers).
>>>
>>> I just took a quick look, but it seems like "driverlib" is TI's own
>>> hardware abstraction C code.
>>>
>>> Our philosphy here was always to not use vendor-supplied HAL code and
>>> instead rewrite hardware support from scratch.
>>>
>>> While that requires a little more effort for a new port in the
>>> beginning, we usually end up with a lot cleaner, smaller, more-to-the
>>> point code that can more easily be shared between platforms.
>>>
>>> (The license used by driverlib looks fine actually.)
>>>
>>> Kaspar
>>> ___
>>> devel mailing list
>>> devel@riot-os.org
>>> https://lists.riot-os.org/mailman/listinfo/devel
>>>
>>
>>
>>
>> ___
>> devel mailing 
>> listdevel@riot-os.orghttps://lists.riot-os.org/mailman/listinfo/devel
>>
>>
>>
>> ___
>> devel mailing list
>> devel@riot-os.org
>> https://lists.riot-os.org/mailman/listinfo/devel
>>
>>
>
>
> ___
> devel mailing 
> listdevel@riot-os.orghttps://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
>
>
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] RIOT preview for TI cc3200

[Attilio Dona]

Ok,

just for sharing a little roadmap I'm starting to work on the wifi module
integration.

I need a little bit of time for this task, I think some weeks.

Could make sense create a PR after the completion of this task?

Let me know!

greetings
Attilio


ps. For shell echoing I needed to apply the following patch to
shell/shell.c (I think this affect all systems that use newlib)

@@ -256,6 +256,9 @@ static int readline(char *buf, size_t size)
 else {
 *line_buf_ptr++ = c;
 _putchar(c);
+#ifdef MODULE_NEWLIB
+fflush(stdout);
+#endif
 }
 }
 }







On Thu, Sep 24, 2015 at 1:29 PM, Hauke Petersen <hauke.peter...@fu-berlin.de
> wrote:

> Hej,
>
> On 03.09.2015 23:22, Attilio Dona wrote:
>
> Ciao Kaspar,
>
> I agree with RIOT philosophy, so a rewrite could be a nice thing, but I
> also think that this is not a top priority now, at least for me ...
>
> If someone else wants to contribute it would be great!
>
> One more thing to consider is that cc3200 has:
>
>
>- 256 Kb of RAM
>- an external SD serial flash card memory where to flash the image
>- an internal ROM memory burned into the chip that hosts the
>bootloader and the driverlib "ROM version" (directly from factory)
>
> So from version ES1.33 it seems possible to link to the ROM version of
> driverlib for resource optimizations (so could be a waste to throw away the
> driverlib API?)
>
> IMHO that is exactly what we do!
>
> @kaspar: in this particular case (as for the LM4F120 launchpad board) it
> makes very much sense to use the provided hardware abstraction to implement
> RIOTs periph interfaces, as the code used by this HAL layer is burned into
> read-only ROM directly on the CPU and thus does not use any additional
> memory...
>
> Cheers,
> Hauke
>
>
>
>
> I have not tested this setup yet, but I think could be a trail to do.
>
> Attilio
>
>
>
> On Wed, Sep 2, 2015 at 9:36 AM, Kaspar Schleiser <kas...@schleiser.de>
> wrote:
>
>> Hey Attilio,
>>
>> Thanks a lot for your effort on getting this board supported!
>>
>> On 09/01/15 21:32, Attilio Dona wrote:
>> > I need just some confirmation, the most important is
>> > that driverlib from TI is license compatible with RIOT
>> > (cpu/cc32000/driverlib and cpu/cc3200/inc files used as HAL for the
>> > drivers).
>>
>> I just took a quick look, but it seems like "driverlib" is TI's own
>> hardware abstraction C code.
>>
>> Our philosphy here was always to not use vendor-supplied HAL code and
>> instead rewrite hardware support from scratch.
>>
>> While that requires a little more effort for a new port in the
>> beginning, we usually end up with a lot cleaner, smaller, more-to-the
>> point code that can more easily be shared between platforms.
>>
>> (The license used by driverlib looks fine actually.)
>>
>> Kaspar
>> ___
>> devel mailing list
>> devel@riot-os.org
>> https://lists.riot-os.org/mailman/listinfo/devel
>>
>
>
>
> ___
> devel mailing 
> listdevel@riot-os.orghttps://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] RIOT preview for TI cc3200

[Attilio Dona]

Hi Rakendra,

Before creating a PR I need just some confirmation, the most important is
that driverlib from TI is license compatible with RIOT
(cpu/cc32000/driverlib and cpu/cc3200/inc files used as HAL for the
drivers).

I suppose there is no problem but it is better to have a confirmation from
RIOT community leaders.

Under cc3200-launchxl/dist there is already a debug.sh using openocd that
should work as a debugging tools:

  > make BOARD=cc3200-launchxl debug

For flashing I don't know how to flash the external SD card with openocd,
do you or someone else know how to flash with openocd or in some other ways?

Greetings
Attilio


ps. for Arvind: if cc3200 TI driverlib is RIOT license compatible, the
equivalent driverlib for msp320 could be a good starting point for your
chip?

On Tue, Sep 1, 2015 at 8:07 PM, rakendra thapa <rakendrath...@gmail.com>
wrote:

> Nice work Attilio. I was just starting to explore into this board from TI
> and this is going to be helpful.
>
> Did you create a pull request for this port ?
>
> Meanwhile, a point that points you can look into.
>
> For flashing/debugging CC3200, you can use openocd as well as cc3200.cfg
> configuration file is already available.
> You can put that in the board/dist. I am not sure but I think cc3200prog
> binary may be license limited.
> More over it will be helpful even for debugging :)
>
> Thanks and Regards,
> Rakendra
>
>
> On Tue, Sep 1, 2015 at 8:25 PM, Attilio Dona <attilio.d...@gmail.com>
> wrote:
>
>> Hello dear RIOTers,
>>
>> I've pushed a cc3200 (http://www.ti.com/product/cc3200) RIOT basic port
>> here:
>>
>> https://github.com/attdona/RIOT
>>
>> SimpleLink Wi-Fi CC3200 LaunchPad is the working board (
>> http://www.ti.com/tool/cc3200-launchxl).
>> This is my first contribution to RIOT, so it would be great if you could
>> me feedback.
>>
>> greetings
>> Attilio
>>
>>
>> Quick start
>>
>> > make BOARD=cc3200-launchxl
>>
>> for flashing you have to use the cc3200prog binary from Energia (
>> http://energia.nu/):
>>
>> > export ENERGIA_ROOT=> /opt/energia-0101E0016>
>> > export PORT=
>>
>> > make BOARD=cc3200-launchxl flash
>>
>> For flashing use the jumper setting described here:
>> http://energia.nu/cc3200guide/
>>
>>
>> ___
>> 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] RIOT preview for TI cc3200

[Attilio Dona]

Hello dear RIOTers,

I've pushed a cc3200 (http://www.ti.com/product/cc3200) RIOT basic port
here:

https://github.com/attdona/RIOT

SimpleLink Wi-Fi CC3200 LaunchPad is the working board (
http://www.ti.com/tool/cc3200-launchxl).
This is my first contribution to RIOT, so it would be great if you could me
feedback.

greetings
Attilio


Quick start

> make BOARD=cc3200-launchxl

for flashing you have to use the cc3200prog binary from Energia (
http://energia.nu/):

> export ENERGIA_ROOT=
> export PORT=

> make BOARD=cc3200-launchxl flash

For flashing use the jumper setting described here:
http://energia.nu/cc3200guide/
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Changing the workflow.

[Attilio Dona]

Just for add a bit of documentation for helping discovering the best
workflow:

http://nvie.com/posts/a-successful-git-branching-model/

The post contains some good points in my opinion, for example the guideline
that a feature branch have to exists in developer repo and not in origin.

ciao
Attilio

On Sat, Feb 21, 2015 at 7:02 PM, Martine Lenders mlend...@inf.fu-berlin.de
wrote:

 Hello coding RIOTers,
 After I needed to rebase several PRs multiple times last week I'm really
 fed up with our current workflow. Furthermore, I discovered three things
 that show that we are in need of a more established workflow.

1. our community is growing
2. our master branch is changing constantly and has features in it
that are sometimes thrown out the window weeks after they where introduced
(e.g. radio_types.h or the older versions of netapi/netdev)
3. we introduced feature-centric task forces to our communities

 This is why I propose we change to a slightly adapted topic branch
 workflow (also known as feature branch) workflow [1]:

- the main RIOT-OS/RIOT repository will get the following branches
   - master: points to the stable version of our latest release
  - one stable branch for every major release (?)
   - devel: points to current development version (what is currently
   our master), hot fixes can be cherry-picked to the master from here.
   - branching from devel: feature branch for every task force that is
   currently in active development, current changes will be merged 
 regularly
   from devel by the branches maintainers
- Pull Requests will be made either to devel (default) or the
corresponding feature branch
- feature branches will be merged into devel if the feature reaches
sufficient stability.
- devel will be merged into master, when a new release is out and
master's new HEAD tagged with the release number.

 I observed two extra benefits from that:

- accidentally merged SQUASH ME commits can be squashed further
upstream, before we add the commits to master or devel
- we can make maintenance of features more granular (and maybe solve
our maintenance problem) by enacting the Dictator and Lieutenants
Workflow, where the Dictator(s) are responsible for master and devel,
and the feature branches can be maintained by the central persons of the
Task Force (the Lieutenants).

 What do you think?

 Cheers,
 Martine

 [1]
 http://git-scm.com/book/en/v2/Git-Branching-Branching-Workflows#Topic-Branches
 [2]
 http://git-scm.com/book/en/v2/Distributed-Git-Distributed-Workflows#Dictator-and-Lieutenants-Workflow

 ___
 devel mailing list
 devel@riot-os.org
 http://lists.riot-os.org/mailman/listinfo/devel


___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] replace printf, puts issue

[Attilio Dona]

Hi Ludwig,

In my simple tinking the macro approach does not exclude the API, just a
pseudo code example:


API log_api.h:

...

void log.info(const char* fmt, ...);

...

#ifdef ENABLE_INFO
#define LOG_INFO(...) log.info(__VA_ARGS__)
#else
#define LOG_INFO(...)
#endif



In RIOT framework and application code use exclusively the macro LOG_INFO,
LOG_DEBUG, ecc. ecc. so you have one more degree of freedom for easy
including/stripping the tracing code from the binary.

Another advantage with the macro usage is obviously the possibility to
change to another logging implementation in one place instead of modifying
all source lines where log is instrumented.

Attilio




On Mon, Feb 23, 2015 at 10:04 AM, Ludwig Ortmann 
ludwig.ortm...@fu-berlin.de wrote:

 Hi Attilio, Martine,

 are you suggesting macros are better than APIs + functions?
 If so, please explain why and what better means ;)

 Cheers, Ludwig

 On Mon, Feb 23, 2015 at 09:26:34AM +0100, Attilio Dona wrote:
  Also for me the MACRO approach has to be considered in a design review,
  eventually in addition to a tracing API layer.
 
  Just to add my bit of experience with RIOT about porting msp430 family on
  new TI/redhat gcc 4.9:
 
  the default nanolib bundled with the toolchain implies a big printf
 memory
  usage, not suitable for a lot of msp430 chips.
 
  At the moment my solution is to use tinyprintf:
 
  https://github.com/cjlano/tinyprintf
 
  It works as expected, with some minor modification to suit my port.
 
  Greetings
  Attilio
 
 
 
 
 
 
 
 
  On Mon, Feb 23, 2015 at 8:24 AM, Martine Lenders authmille...@gmail.com
 
  wrote:
 
   +1 thought about this for a long time, too. Though my approach would be
   with macros and more global (similar to how DEBUG is now).
  
   Am 23.02.2015 07:16 schrieb Ludwig Ortmann 
 ludwig.ortm...@fu-berlin.de
   :
  
   
Hi Jozef,
   
AFAIK there has been no work on a solution so far.
However, I thought about this the other day in the context of the
   function pointer discussion and would like to propose a logging API
   (maybe there is an issue for that as well somewhere) for `core`, which
   offers things like `log.info(...)` and `log.error(...)`.
Different logging modules can implement this API then, ranging from
   `printf` over file based logging to network messages.
And then there should also be a `(void) ...`  implementation which
 suits
   production and ultra low memory needs.
   
Opinions?
   
Cheers, Ludwig
   
Am 23. Februar 2015 03:16:33 MEZ, schrieb Jozef Maslik 
   ma...@binarylemon.com:

Hi,

Could you please give me information about actual state of replace
printf and puts issues? https://github.com/RIOT-OS/RIOT/issues/994
 ,
https://github.com/RIOT-OS/RIOT/issues/641

I’m working with MKL02Z32 which has 4kB RAM. Printf or puts which
 are
almost everywhere make a big problem. I removed them from my fork,
 but
it is not good or nice solution.

If I miss something important around “printing issue” please correct
me.
How others deal with this issue? (printf or puts usage like here, is
not nessesary in real applications).

Regards,
Jozef

___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel
   
___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel
  
  
   ___
   devel mailing list
   devel@riot-os.org
   http://lists.riot-os.org/mailman/listinfo/devel
  
  

  ___
  devel mailing list
  devel@riot-os.org
  http://lists.riot-os.org/mailman/listinfo/devel

 ___
 devel mailing list
 devel@riot-os.org
 http://lists.riot-os.org/mailman/listinfo/devel

___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel