Re: [riot-devel] Flashing the Samr21 xpro
Hi again, so it seems that the slowness was caused by virtualization after all. My previous VM was an Ubuntu 13.10 running inside an older version of VMware Fusion, which resulted in the ~0.5KiB/s speed. After installing an Ubuntu 14.10 that went up to ~1.5KiB/s and running OpenOCD directly on the host gets me close to 2KiB/s when flashing. On OS X 10.9: wrote 32768 bytes from file hello-world.hex in 16.164614s (1.980 KiB/s) verified 16892 bytes in 1.463347s (11.273 KiB/s) On Ubuntu 14.10: wrote 32768 bytes from file /home/lucas/RIOT/examples/hello-world/bin/samr21-xpro/hello-world.hex in 22.042933s (1.452 KiB/s) verified 16892 bytes in 1.505869s (10.955 KiB/s) Cheers, Lucas On 13 Jan 2015, at 11:18, Martin wrote: > Hi, > > my flashing speed is roughly equal to Thomas' for the Samr21-xpro: > > ``` > wrote 65536 bytes from file RIOT/tests/pnet/bin/samr21-xpro/pnet.hex in > 32.083557s (1.995 KiB/s) > verified 49688 bytes in 4.114729s (11.793 KiB/s) > ``` > > My openocd version: > `Open On-Chip Debugger 0.9.0-dev-00186-g30203b3 (2014-11-12-11:49)` > > Best regards, > Martin > On 12.01.2015 21:07, Baptiste Clenet wrote: >> Flashing is slow for us too, how do you get the speed? >> >> 2015-01-12 11:13 GMT+01:00 Lucas Jenß : >> Hi Thomas, >> >> verification was much faster as 0.4KiB/s, I think around 10 or so for me. >> I checked out OpenOCD on the 9th. I’m also running Linux inside VMware >> though, so maybe it’s just caused by the virtualization. I’ll see how fast >> it is on the host. >> >> Cheers, >> Lucas >> >> A couple of days ago. >> >> On 12 Jan 2015, at 11:00, Thomas Eichinger >> wrote: >> >> > Hi Lucas, >> > >> > I was playing with the openocd configuration a bit, mainly >> > `adapter_speed`, back when support for this was added without >> > any significant outcome. >> > Problem is, the EDBG chip, on the bottom of the board, handling >> > communication with the MCU is specified to run on 1MHz and the >> > openocd docs mention, for CMSIS-DAP, it is not advised to let >> > signal frequency exceed half of the operating frequency. >> > (I’d guess Nyquist-Shannon applies) >> > >> > That said, 0.481KiB/s still seems slow for this. I’m at least >> > reaching 1.787KiB/s for flashing and 11.190KiB/s for verification. >> > When did you check out the OpenOCD code? >> > >> > Best, Thomas >> > >> >> On 10 Jan 2015, at 14:25, Lucas Jenß wrote: >> >> >> >> Hey everyone, >> >> >> >> I’ve been playing around with the Samr21 xpro and flashing >> >> the device is _really_ slow, i.e. 0.481 KiB/s. Is this expected >> >> or is there a way to improve it? I’m using the current OpenOCD >> >> Git HEAD because the 0.8.0 release does not seem to contain the >> >> configs for the board yet. I tried to flash the hello-world >> >> example. >> >> >> >> Cheers, >> >> Lucas >> >> ___ >> >> 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 >> >> >> >> -- >> Clenet Baptiste >> FR: +33 6 29 73 05 39 >> Élève-Ingénieur ESEO Angers, dernière année, spécialisation: Architecte >> système temps réél embarqué >> Bidiplôme Master Robotics à l'Université de Plymouth en 2013-2014 >> >> >> >> ___ >> 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
[riot-devel] JTAG adapter for Arduino Due
Hello everyone, Does anybody use a JTAG adapter to perform in-circuit debugging on the Arduino Due board? Does your setup work? If yes, could you tell me what JTAG adapter you are using, and how? I'm currently trying to use Olimex ARM-USB-TINY-H to debug a RIOT driver on Arduino Due, but I cannot make this thing work, and thus I'm currently stuck... Thanks, -- Kévin Roussel Doctorant, projet LAR Équipe MADYNES, INRIA Nancy Grand-Est / LORIA Tél. : +33 3 54 95 86 27 kevin.rous...@inria.fr ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] thread is not working
You can look at the startup files for other CPUs for a proper way of
doing initialization e.g. cpu/stm32f1/startup.c
Note that you must also make sure that your linker script provides the
correct symbols at the beginning and end of .data and .bss.
Best regards,
Joakim Gebart
Eistec AB
www.eistec.se
On 01/13/2015 10:45 PM, Ryan Kurte wrote:
> Hi Shishir,
>
> I seem to recall having the same issue when starting the EFM32 port.
> The issue in my case was that without the startup files, the .bss
> section was not getting cleared.
> When the threads came to launch, the value in one of the kernel
> functions was not correct. Which is pretty easy to check with a debugger.
>
> The fix was to clear the .bss section in the _init routine, my
> implementation (using symbols from the linker) is:
>
> //Clear bss
> for (uint32_t i = (uint32_t)&__bss_start__; i <
> (uint32_t)&__bss_end__; i++) {
> addr = (int*)i;
> *addr = (int)NULL;
> }
>
> I am not sure this is the /correct/ way to do it, but the .bss
> definitely needs to be initialised to zeros.
>
> Hope that helps,
>
> Ryan
>
> On 14 January 2015 at 07:56, Hauke Petersen
> mailto:hauke.peter...@fu-berlin.de>> wrote:
>
> Hi,
>
> On 13.01.2015 19:04, shishir tiwari wrote:
>
> Hi petersen,
>
> Thanks for your information.
>
> we are trying to put your method but still is it not working.
> we are
> studying and doing some experiments.
>
> one more question : In hwtimer_init()--> hwtimer_arch_init()
> this need
> to be implemented in harsware is compulsory?? for scheduling
> to work?
>
> nope, the timer is generally not needed for scheduling.
>
> Cheers,
> Hauke
>
>
>
>
>
> thanks
> shishir tiwari
>
> On Mon, Jan 12, 2015 at 10:01 PM, Hauke Petersen
> > wrote:
>
> Hi Shishir,
>
> when RIOT initially starts up, the CPU is normally running
> in interrupt mode
> (using the interrupt mode stack). After creating the
> stacks for the main and
> the idle threads, the CPU must be put into thread-mode.
> This means the main
> threads initial context needs to put into the CPUs
> registers and the stack
> pointer must put to the main-threads stack. After this is
> done the CPU can
> just do 'normal' task switching for switching between threads.
>
> So to put it short: in cpu_switch_context_exit() you
> simply must load the
> main threads context into the CPUs register and point the
> stack pointer to
> the main threads stack.
>
> Let me know if you need further information!
>
> Cheers,
> Hauke
>
>
>
> On 12.01.2015 15:35, shishir tiwari wrote:
>
> Hey Everyone,
>
> I have been porting RIOT OS to new processor(ARC) and
> i had compilied
> hello world program successfully.
> When i debug the helloworld.elf in kernel_init
> function the
> thread_create() function has execute successfully.But
> the thread
> "idle_thread" "and main_trampoline" function is not
> been called. why?
>
> What is thing need to be done on this
> cpu_switch_context_exit()
> function. please explain me.
>
>
> Thanks
> Shishir Tiwari
> ___
> 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
Re: [riot-devel] Virtual Meeting tomorrow
Hi! > please recall that the next bi-weekly meeting will happen tomorrow at 10:30 am Sorry, that was a mistake: meeting starts at 10:00 am (aka NOW) as usual. Cheers, Oleg -- /* Thanks to Rob `CmdrTaco' Malda for not influencing this code in any * way. */ linux-2.4.3/net/core/netfilter.c pgp58GQDyXxMe.pgp Description: PGP signature ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Virtual Meeting tomorrow
Hi! > The PlaceCam link will follow tomorrow. And here it goes: http://placecam.de/call.php?c=VBYEpXi43MZ2MOrV~pegsMm6Z7woUbw.VRY0Qxal2pE- Cheers, Oleg -- /* Am I fucking pedantic or what? */ linux-2.2.16/drivers/scsi/qlogicpti.h pgpfxFJLdIfn_.pgp Description: PGP signature ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Virtual Meeting tomorrow
Hi! > "Guests are not allowed to join that pad. Please sign in." Made public now. Cheers, Oleg -- printk(KERN_ERR "happy meal: Transceiver and a coke please."); linux-2.6.6/drivers/net/sunhme.c pgpA59hEu5Ogz.pgp Description: PGP signature ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Virtual Meeting tomorrow
Hi, On Tue, Jan 13, 2015 at 09:03:20PM +0100, Oleg Hahm wrote: > I've set up a pad with a tentative agenda here: > http://riot.pad.spline.de/6 "Guests are not allowed to join that pad. Please sign in." Cheers, Ludwig ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
