From ulrich.prinz at googlemail.com Wed Feb 1 16:59:46 2012 From: ulrich.prinz at googlemail.com (Ulrich Prinz) Date: Wed, 1 Feb 2012 16:59:46 +0100 Subject: [En-Nut-Discussion] devnut_m3n branch linker severely broken? Message-ID: Hi all, in devnut_m3n the linker setup is severely broken. I t is impossible to link a system without big code overhead. It looks like both, stdlib and nutos wrappers, are linked into the system. I tried several approaches to compile a tiny bootloader that was only 6..8k in an older version of the branch and now is 14k or even bigger. It compiled without any problems if -lnutcrt is omitted. In the current branch state nutcrt library cannot be omitted an any way and whole libc.a is included too. Any trial by adding -nostdlib ended in either having nothing or having all. That means: Either you get arm-none-eabi-gcc canboot.o stm32/stm32_can.o stm32/stm32_appl.o stm32/stm32_adc.o paulus/bl_canopen.o paulus/bl_crc.o paulus/bl_user.o paulus/bl_flash.o cmc_led.o cmc_sid.o -mcpu=cortex-m3 -mthumb -mlittle-endian -D__CORTEX__ -g -nostartfiles -L./ -Tstm32f10x_boot.ld -Wl,-Map=canboot.map,--cref,--no-warn-mismatch -L../../nutbld-stm32-gcc/lib -nostdlib -Wl,- -start-group ../../nutbld-stm32-gcc/lib/nutinit.o -lnutos -lnutdev -lnutarch -Wl,--end-group -o canboot.elf paulus/bl_canopen.o: In function `doCANopen': bl_canopen.c:(.text.doCANopen+0x1b8): undefined reference to `memcpy' bl_canopen.c:(.text.doCANopen+0x1ea): undefined reference to `memcpy' paulus/bl_flash.o: In function `flashData': bl_flash.c:(.text.flashData+0x22): undefined reference to `memset' ../../nutbld-stm32-gcc/lib\libnutos.a(heap.o): In function `NutHeapRootAllocClear': heap.c:(.text.NutHeapRootAllocClear+0x10): undefined reference to `memset' ../../nutbld-stm32-gcc/lib\libnutos.a(heap.o): In function `NutHeapRootRealloc': heap.c:(.text.NutHeapRootRealloc+0xa0): undefined reference to `memcpy' ../../nutbld-stm32-gcc/lib\libnutos.a(heap.o): In function `NutHeapDump': heap.c:(.text.NutHeapDump+0x12): undefined reference to `fprintf' ../../nutbld-stm32-gcc/lib\libnutos.a(thread.o): In function `GetThreadByName': thread.c:(.text.GetThreadByName+0x12): undefined reference to `strcmp' ../../nutbld-stm32-gcc/lib\libnutos.a(timer.o): In function `NutClockSet': timer.c:(.text.NutClockSet+0x8): undefined reference to `memset' ../../nutbld-stm32-gcc/lib\libnutos.a(confos.o): In function `NutLoadConfig': confos.c:(.text.NutLoadConfig+0x1c): undefined reference to `memcmp' confos.c:(.text.NutLoadConfig+0x26): undefined reference to `strcpy' ../../nutbld-stm32-gcc/lib\libnutos.a(confos.o): In function `NutSaveConfig': confos.c:(.text.NutSaveConfig+0x10): undefined reference to `memcpy' ../../nutbld-stm32-gcc/lib\libnutarch.a(context.o): In function `NutThreadCreate': context.c:(.text.NutThreadCreate+0x46): undefined reference to `memcpy' ../../nutbld-stm32-gcc/lib\libnutarch.a(stm32_flash.o): In function `Stm32FlashRead': stm32_flash.c:(.text.Stm32FlashRead+0x2): undefined reference to `memcpy' ../../nutbld-stm32-gcc/lib\libnutarch.a(stm32_flash.o): In function `Stm32FlashWrite': stm32_flash.c:(.text.Stm32FlashWrite+0x7a): undefined reference to `memcpy' stm32_flash.c:(.text.Stm32FlashWrite+0x96): undefined reference to `memcpy' ../../nutbld-stm32-gcc/lib\libnutarch.a(stm32_flash.o):stm32_flash.c:(.text.Stm32FlashWrite+0xa0): more undefined references to `memcpy' follow ../../nutbld-stm32-gcc/lib\libnutarch.a(stm32_flash.o): In function `Stm32FlashParamWrite': stm32_flash.c:(.text.Stm32FlashParamWrite+0x2c): undefined reference to `memcmp' collect2: ld returned 1 exit status make: *** [canboot.elf] Error 1 Or you get LDFLAGS: -mcpu=cortex-m3 -mthumb -mlittle-endian -D__CORTEX__ -g -nostartfiles -L./ -Tstm32f10x_boot.ld -Wl,-Map=canboot.map,--cr ef,--no-warn-mismatch -L../../nutbld-stm32-gcc/lib ************************************************** arm-none-eabi-gcc canboot.o stm32/stm32_can.o stm32/stm32_appl.o stm32/stm32_adc.o paulus/bl_canopen.o paulus/bl_crc.o paulus/bl_user.o paulus/bl_flash.o cmc_led.o cmc_sid.o -mcpu=cortex-m3 -mthumb -mlittle-endian -D__CORTEX__ -g -nostartfiles -L./ -Tstm32f10x_boot.ld -Wl,-Map=canboot.map,--cref,--no-warn-mismatch -L../../nutbld-stm32-gcc/lib -Wl,--start-group ../../nutbld-stm32-gcc/lib/nutinit.o -lnutos -lnutdev -lnutarch -Wl,--end-group -o canboot.elf c:/programme/yagarto/bin/../lib/gcc/arm-none-eabi/4.6.0/../../../../arm-none-eabi/bin/ld.exe: canboot.elf section `.text' will not fit in region `FLASH0' c:/programme/yagarto/bin/../lib/gcc/arm-none-eabi/4.6.0/../../../../arm-none-eabi/bin/ld.exe: region `FLASH0' overflowed by 5616 bytes collect2: ld returned 1 exit status make: *** [canboot.elf] Error 1 Our you get lots of missing _fopen() _fwrite() _sbrk_r()... of the newlib. I actually have no idea of how to fix that... I tried comparision of the different versions but do not find the modification that is the cause for this. Best regards Ulrich From ole.reinhardt at embedded-it.de Wed Feb 1 17:10:39 2012 From: ole.reinhardt at embedded-it.de (Ole Reinhardt) Date: Wed, 01 Feb 2012 17:10:39 +0100 Subject: [En-Nut-Discussion] devnut_m3n branch linker severely broken? In-Reply-To: References: Message-ID: <1328112639.2090.32.camel@platon> Hi Ulrich, > in devnut_m3n the linker setup is severely broken. > I t is impossible to link a system without big code overhead. It looks > like both, stdlib and nutos wrappers, are linked into the system. Are you shure that this is a problem of the devnut_m3n in general or just a problem with the STM32 implementation / Linker scripts? With the LPC1788 implementation I compiled my little test program (some blinking LEDs) and it just has 3K of size, not more than a few weeks ago. On the other hand there are no references to the nutcrt right now. AFAIK Uwe modified the STM32 linker scripts not long ago. Have you just looked at the different segments (arm-none-eabi-objdump -h yourfile.elf) to see which segment growed that much? Are you sure you used the same toolchain than before? Bye, Ole -- Thermotemp GmbH, Embedded-IT Embedded Hard-/ Software and Open Source Development, Integration and Consulting http://www.embedded-it.de Gesch?ftsstelle Siegen - Steinstra?e 67 - D-57072 Siegen - tel +49 (0)271 5513597, +49 (0)271-73681 - fax +49 (0)271 736 97 Hauptsitz - Hademarscher Weg 7 - 13503 Berlin Tel +49 (0)30 4315205 - Fax +49 (0)30 43665002 Gesch?ftsf?hrer: J?rg Friedrichs, Ole Reinhardt Handelsregister Berlin Charlottenburg HRB 45978 UstID DE 156329280 From ole.reinhardt at embedded-it.de Wed Feb 1 17:14:39 2012 From: ole.reinhardt at embedded-it.de (Ole Reinhardt) Date: Wed, 01 Feb 2012 17:14:39 +0100 Subject: [En-Nut-Discussion] devnut_m3n branch linker severely broken? In-Reply-To: References: Message-ID: <1328112879.2090.35.camel@platon> Hi Ulrich, > in devnut_m3n the linker setup is severely broken. > I t is impossible to link a system without big code overhead. It looks > like both, stdlib and nutos wrappers, are linked into the system. I just did further testing and compiled the "simple.c" demo for the AT91 platform which results in 11K!!! Might that be a general Nut/OS problem? Any unused dependencies? bye, Ole -- Thermotemp GmbH, Embedded-IT Embedded Hard-/ Software and Open Source Development, Integration and Consulting http://www.embedded-it.de Gesch?ftsstelle Siegen - Steinstra?e 67 - D-57072 Siegen - tel +49 (0)271 5513597, +49 (0)271-73681 - fax +49 (0)271 736 97 Hauptsitz - Hademarscher Weg 7 - 13503 Berlin Tel +49 (0)30 4315205 - Fax +49 (0)30 43665002 Gesch?ftsf?hrer: J?rg Friedrichs, Ole Reinhardt Handelsregister Berlin Charlottenburg HRB 45978 UstID DE 156329280 From bon at elektron.ikp.physik.tu-darmstadt.de Wed Feb 1 17:43:49 2012 From: bon at elektron.ikp.physik.tu-darmstadt.de (Uwe Bonnes) Date: Wed, 1 Feb 2012 17:43:49 +0100 Subject: [En-Nut-Discussion] devnut_m3n branch linker severely broken? In-Reply-To: <1328112639.2090.32.camel@platon> References: <1328112639.2090.32.camel@platon> Message-ID: <20265.27589.342884.65068@elektron.ikp.physik.tu-darmstadt.de> >>>>> "Ole" == Ole Reinhardt writes: Ole> Hi Ulrich, >> in devnut_m3n the linker setup is severely broken. I t is impossible >> to link a system without big code overhead. It looks like both, >> stdlib and nutos wrappers, are linked into the system. Ole> Are you shure that this is a problem of the devnut_m3n in general Ole> or just a problem with the STM32 implementation / Linker scripts? Ole> With the LPC1788 implementation I compiled my little test program Ole> (some blinking LEDs) and it just has 3K of size, not more than a Ole> few weeks ago. Ole> On the other hand there are no references to the nutcrt right now. Ole> AFAIK Uwe modified the STM32 linker scripts not long ago. At least the SVN log says that I didn't touch stm32f10x_flash.ld. Last change was r3523 | astralix | 2011-07-20 23:01:23 +0200 (Mi, 20. Jul 2011) | 1 Zeile Ge?nderte Pfade: M /branches/devnut_m3n/nut/arch/cm3/ldscripts/stm32f10x_flash.ld Thx Uwe: fixed linking fail with gcc > 4.5.1 toolchains. Bye -- Uwe Bonnes bon at elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- From ole.reinhardt at embedded-it.de Thu Feb 2 10:17:17 2012 From: ole.reinhardt at embedded-it.de (Ole Reinhardt) Date: Thu, 02 Feb 2012 10:17:17 +0100 Subject: [En-Nut-Discussion] Anybody on Embedded World 2012? Message-ID: <1328174237.2086.12.camel@platon> Hi all, just to be the first, I'm curious if anybody (beside of Egnite :-) will be on the Embedded World this year. Perhaps we could meet again? Right now I plan to be there at 28.02 or 29.02.2012 Bye, Ole -- Thermotemp GmbH, Embedded-IT Embedded Hard-/ Software and Open Source Development, Integration and Consulting http://www.embedded-it.de Gesch?ftsstelle Siegen - Steinstra?e 67 - D-57072 Siegen - tel +49 (0)271 5513597, +49 (0)271-73681 - fax +49 (0)271 736 97 Hauptsitz - Hademarscher Weg 7 - 13503 Berlin Tel +49 (0)30 4315205 - Fax +49 (0)30 43665002 Gesch?ftsf?hrer: J?rg Friedrichs, Ole Reinhardt Handelsregister Berlin Charlottenburg HRB 45978 UstID DE 156329280 From bon at elektron.ikp.physik.tu-darmstadt.de Thu Feb 2 10:51:42 2012 From: bon at elektron.ikp.physik.tu-darmstadt.de (Uwe Bonnes) Date: Thu, 2 Feb 2012 10:51:42 +0100 Subject: [En-Nut-Discussion] Anybody on Embedded World 2012? In-Reply-To: <1328174237.2086.12.camel@platon> References: <1328174237.2086.12.camel@platon> Message-ID: <20266.23726.4377.606481@elektron.ikp.physik.tu-darmstadt.de> >>>>> "Ole" == Ole Reinhardt writes: Ole> Hi all, just to be the first, I'm curious if anybody (beside of Ole> Egnite :-) will be on the Embedded World this year. Ole> Perhaps we could meet again? Ole> Right now I plan to be there at 28.02 or 29.02.2012 I plan to go one of those both days too. Bye -- Uwe Bonnes bon at elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- From ulrich.prinz at googlemail.com Thu Feb 2 14:44:37 2012 From: ulrich.prinz at googlemail.com (Ulrich Prinz) Date: Thu, 2 Feb 2012 14:44:37 +0100 Subject: [En-Nut-Discussion] devnut_m3n branch linker severely broken? In-Reply-To: <1328112639.2090.32.camel@platon> References: <1328112639.2090.32.camel@platon> Message-ID: Hi Ole, yes I am on the same toolchain, just updated nutos to 3726. Looks like libnutc and libc got some unusual interconnections. If I exclude one, I get missing memcpy/memchr/... and if I exclude the other, I get missing _sbrk_r and others and additionally the code size grows again about 6k. So the thing insists on loading libnutc and libc... No idea why. I tested both toolchains, yagarto with gcc 4.6.0 on Windows and eCross on Linux. Same results. Ulrich From markus.dost at dr-clauss.de Mon Feb 6 11:12:22 2012 From: markus.dost at dr-clauss.de (Markus Dost) Date: Mon, 6 Feb 2012 11:12:22 +0100 Subject: [En-Nut-Discussion] Ethernut 2.1, httpd-app: size of the .hex-file Message-ID: <881197B3-A14F-4F7F-AD1D-990132B8A50A@dr-clauss.de> Hi, I have a problem with the Ethernut 2.1-board, which is maybe trivial: I configured the OS for the board with an ATmega128 and compiled the httpd-app. The building worked fine, but the size of the .hex-file is about 260 KB. This is too large for program memory of the controller, so I wonder whether this is a normal code size or something went wrong. Best regards, Markus From harald.kipp at egnite.de Mon Feb 6 12:06:56 2012 From: harald.kipp at egnite.de (Harald Kipp) Date: Mon, 06 Feb 2012 12:06:56 +0100 Subject: [En-Nut-Discussion] Ethernut 2.1, httpd-app: size of the .hex-file In-Reply-To: <881197B3-A14F-4F7F-AD1D-990132B8A50A@dr-clauss.de> References: <881197B3-A14F-4F7F-AD1D-990132B8A50A@dr-clauss.de> Message-ID: <4F2FB450.1040005@egnite.de> Hi Markus, On 06.02.2012 11:12, Markus Dost wrote: > I configured the OS for the board with an ATmega128 and compiled the > httpd-app. The building worked fine, but the size of the .hex-file is > about 260 KB. This is too large for program memory of the controller, > so I wonder whether this is a normal code size or something went wrong. The hex file contains ASCII format, each byte is coded in two ASCII characters. http://en.wikipedia.org/wiki/Intel_hex Therefore, it is at least twice as large as the binary code. In addition, the hex file contains addresses, checksums, CR/LF and more. How large is httpserv.bin? This file contains the pure flash image. Regards, Harald From markus.dost at dr-clauss.de Mon Feb 6 12:22:42 2012 From: markus.dost at dr-clauss.de (Markus Dost) Date: Mon, 6 Feb 2012 12:22:42 +0100 Subject: [En-Nut-Discussion] Ethernut 2.1, httpd-app: size of the .hex-file In-Reply-To: <4F2FB450.1040005@egnite.de> References: <881197B3-A14F-4F7F-AD1D-990132B8A50A@dr-clauss.de> <4F2FB450.1040005@egnite.de> Message-ID: Hi Harald, thanks for your answer. Until now, I had develop AVR-projects only in the AVR-Studio which told me the memory usage after compiling. So I didn't care about the hex-file :-) The size of my .bin-File is 93 KB and the last memory adress in the .hex-file ist 10730. So everything should be fine ^^. Best regards, Markus Am 06.02.2012 um 12:06 schrieb Harald Kipp: > Hi Markus, > > On 06.02.2012 11:12, Markus Dost wrote: >> I configured the OS for the board with an ATmega128 and compiled the >> httpd-app. The building worked fine, but the size of the .hex-file is >> about 260 KB. This is too large for program memory of the controller, >> so I wonder whether this is a normal code size or something went >> wrong. > > The hex file contains ASCII format, each byte is coded in two ASCII > characters. > > http://en.wikipedia.org/wiki/Intel_hex > > Therefore, it is at least twice as large as the binary code. In > addition, the hex file contains addresses, checksums, CR/LF and more. > > How large is httpserv.bin? This file contains the pure flash image. > > Regards, > > Harald > _______________________________________________ > http://lists.egnite.de/mailman/listinfo/en-nut-discussion From bon at elektron.ikp.physik.tu-darmstadt.de Mon Feb 6 12:52:06 2012 From: bon at elektron.ikp.physik.tu-darmstadt.de (Uwe Bonnes) Date: Mon, 6 Feb 2012 12:52:06 +0100 Subject: [En-Nut-Discussion] Ethernut 2.1, httpd-app: size of the .hex-file In-Reply-To: References: <881197B3-A14F-4F7F-AD1D-990132B8A50A@dr-clauss.de> <4F2FB450.1040005@egnite.de> Message-ID: <20271.48870.255532.166297@elektron.ikp.physik.tu-darmstadt.de> >>>>> "Markus" == Markus Dost writes: Markus> Hi Harald, thanks for your answer. Until now, I had develop Markus> AVR-projects only in the AVR-Studio which told me the memory Markus> usage after compiling. So I didn't care about the hex-file :-) For e.g. AVR, use avr-size for that purpose. -- Uwe Bonnes bon at elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- From ole.reinhardt at embedded-it.de Mon Feb 6 23:19:26 2012 From: ole.reinhardt at embedded-it.de (Ole Reinhardt) Date: Mon, 06 Feb 2012 23:19:26 +0100 Subject: [En-Nut-Discussion] Strange newlib syscall dependencies / linker problems when using 64bit integers Message-ID: <1328566767.2181.11.camel@platon> Hi all, in one special situation I need to use a 64bit devision on a Cortex M3. Compiling works fine, but the linker trows the following problems: arm-eCross-eabi-gcc test.o -mcpu=cortex-m3 -mthumb -mlittle-endian -D__CORTEX__ -nostartfiles -L/home/ole/work/Streamit/NutOS_M3N/nut/arch/cm3/ldscripts -Tlpc1778_flash.ld -Wl,-Map=uart.map,--cref,--gc-sections -L/home/ole/work/Streamit/nut-build-lpc177x_8x/lib -Wl,--start-group /home/ole/work/Streamit/nut-build-lpc177x_8x/lib/nutinit.o -lnutcrt -lnutarch -lnutdev -lnutos -lnutdev -lnutarch -Wl,--end-group -o uart.elf /opt/arm-eCross-eabi/bin/../lib/gcc/arm-eCross-eabi/4.5.2/../../../../arm-eCross-eabi/lib/thumb/v7m/libc.a(lib_a-abort.o): In function `abort': /home/ole/work/eCross/newlib-build/arm-eCross-eabi/thumb/v7m/newlib/libc/stdlib/../../../../../../../src/newlib-1.19.0/newlib/libc/stdlib/abort.c:63: undefined reference to `_exit' /opt/arm-eCross-eabi/bin/../lib/gcc/arm-eCross-eabi/4.5.2/../../../../arm-eCross-eabi/lib/thumb/v7m/libc.a(lib_a-signalr.o): In function `_kill_r': /home/ole/work/eCross/newlib-build/arm-eCross-eabi/thumb/v7m/newlib/libc/reent/../../../../../../../src/newlib-1.19.0/newlib/libc/reent/signalr.c:61: undefined reference to `_kill' /opt/arm-eCross-eabi/bin/../lib/gcc/arm-eCross-eabi/4.5.2/../../../../arm-eCross-eabi/lib/thumb/v7m/libc.a(lib_a-signalr.o): In function `_getpid_r': /home/ole/work/eCross/newlib-build/arm-eCross-eabi/thumb/v7m/newlib/libc/reent/../../../../../../../src/newlib-1.19.0/newlib/libc/reent/signalr.c:96: undefined reference to `_getpid' /opt/arm-eCross-eabi/bin/../lib/gcc/arm-eCross-eabi/4.5.2/../../../../arm-eCross-eabi/lib/thumb/v7m/libc.a(lib_a-sbrkr.o): In function `_sbrk_r': /home/ole/work/eCross/newlib-build/arm-eCross-eabi/thumb/v7m/newlib/libc/reent/../../../../../../../src/newlib-1.19.0/newlib/libc/reent/sbrkr.c:60: undefined reference to `_sbrk' collect2: ld returned 1 exit status The program itself looks like this: #include int main() { uint64_t *a,b; volatile uint64_t c; a = 0xaa000aa00; b= 0xaa00aa0000550055; c = b/(*a); if (c < 100) return 1; while(1); return 0; } Btw: defining a as pointer is just a trick to trick the optimizer (which eliminates constant calculations) Beside the above problem the linker complained about overlapping sections .data with (implicit?) segments ARM.extab ad ARN.exidx I fixed this by adding the requested segments (see part of the lpc17xx_flash.ld linker script below): .text : { . = ALIGN(4); _svect = .; KEEP(*(.isr_vector)) _evect = .; *(.text .text.* .gnu.linkonce.t.*) *(.rodata .rodata* .gnu.linkonce.r.*) *(.glue_7t) *(.glue_7) *(.gcc_except_table) . = ALIGN(4); /* _etext = .;*/ } > FLASH0 /* for exception handling/unwind - some Newlib functions (in common with C++ and STDC++) use this. */ .ARM.extab : { *(.ARM.extab* .gnu.linkonce.armextab.*) } > FLASH0 __exidx_start = .; .ARM.exidx : { *(.ARM.exidx* .gnu.linkonce.armexidx.*) } > FLASH0 __exidx_end = .; _etext = .; .vtable (NOLOAD): { . = ALIGN(4); _vtable = .; *(.vtable*) . = ALIGN(4); _evtable = .; } > SRAM0 Does anybody has an idea of what is going wrong here? Best regards, Ole Reinhardt -- Thermotemp GmbH, Embedded-IT Embedded Hard-/ Software and Open Source Development, Integration and Consulting http://www.embedded-it.de Gesch?ftsstelle Siegen - Steinstra?e 67 - D-57072 Siegen - tel +49 (0)271 5513597, +49 (0)271-73681 - fax +49 (0)271 736 97 Hauptsitz - Hademarscher Weg 7 - 13503 Berlin Tel +49 (0)30 4315205 - Fax +49 (0)30 43665002 Gesch?ftsf?hrer: J?rg Friedrichs, Ole Reinhardt Handelsregister Berlin Charlottenburg HRB 45978 UstID DE 156329280 From thiago.correa at gmail.com Tue Feb 7 00:11:42 2012 From: thiago.correa at gmail.com (=?ISO-8859-1?Q?Thiago_A=2E_Corr=EAa?=) Date: Mon, 6 Feb 2012 21:11:42 -0200 Subject: [En-Nut-Discussion] Anybody on Embedded World 2012? In-Reply-To: <1328174237.2086.12.camel@platon> References: <1328174237.2086.12.camel@platon> Message-ID: Hi, On Thu, Feb 2, 2012 at 7:17 AM, Ole Reinhardt wrote: > Hi all, > > just to be the first, I'm curious if anybody (beside of Egnite :-) will > be on the Embedded World this year. > > Perhaps we could meet again? > > Right now I plan to be there at 28.02 or 29.02.2012 > I wish I could keep up the trend I was going, visiting the Embedded World every 2 years, but this year I won't be able to. I hope Egnite will have a good return on the event this year so they can be there next year as well :) From ulrich.prinz at googlemail.com Tue Feb 7 16:41:48 2012 From: ulrich.prinz at googlemail.com (Ulrich Prinz) Date: Tue, 7 Feb 2012 16:41:48 +0100 Subject: [En-Nut-Discussion] Strange newlib syscall dependencies / linker problems when using 64bit integers In-Reply-To: <1328566767.2181.11.camel@platon> References: <1328566767.2181.11.camel@platon> Message-ID: Hi Ole, I never had this kind of problem, but I never used 64 bit variables... But... I compared the local nut/os version for cortexM3 with the sourceforge one and the only bigger difference is the double -L parameter for the linker. You remember the problem I have that building a simple uart example results in 14k code instead of 6k or less in older versions? I guess (but didn't test, cause lack of time) that this might be the problem. Can you test again with LDFLAGS = ...-T'path/to/linker/ldscript.ld' ... -L'path_to_libs' instead of LDFLAGS = ... -L'path/to/linker/' -T'ldscript.ld' ... -L'path_to_libs' It's just a feeling... Linker might test the first search path only and include stdlibs on failing result even the nutos libs exist in the second one. If it is still needed to have the linker scripts in search path, we could reorder the parameters and test again: LDFLAGS = ... -L'path_to_libs' ... -L'path/to/linker/' -T'ldscript.ld' Ulrich Am 6. Februar 2012 23:19 schrieb Ole Reinhardt : > Hi all, > > in one special situation I need to use a 64bit devision on a Cortex M3. > Compiling works fine, but the linker trows the following problems: > > arm-eCross-eabi-gcc test.o -mcpu=cortex-m3 -mthumb -mlittle-endian > -D__CORTEX__ -nostartfiles > -L/home/ole/work/Streamit/NutOS_M3N/nut/arch/cm3/ldscripts > -Tlpc1778_flash.ld -Wl,-Map=uart.map,--cref,--gc-sections > -L/home/ole/work/Streamit/nut-build-lpc177x_8x/lib > -Wl,--start-group /home/ole/work/Streamit/nut-build-lpc177x_8x/lib/nutinit.o -lnutcrt -lnutarch -lnutdev -lnutos -lnutdev -lnutarch ? -Wl,--end-group -o uart.elf > /opt/arm-eCross-eabi/bin/../lib/gcc/arm-eCross-eabi/4.5.2/../../../../arm-eCross-eabi/lib/thumb/v7m/libc.a(lib_a-abort.o): In function `abort': > /home/ole/work/eCross/newlib-build/arm-eCross-eabi/thumb/v7m/newlib/libc/stdlib/../../../../../../../src/newlib-1.19.0/newlib/libc/stdlib/abort.c:63: undefined reference to `_exit' > /opt/arm-eCross-eabi/bin/../lib/gcc/arm-eCross-eabi/4.5.2/../../../../arm-eCross-eabi/lib/thumb/v7m/libc.a(lib_a-signalr.o): In function `_kill_r': > /home/ole/work/eCross/newlib-build/arm-eCross-eabi/thumb/v7m/newlib/libc/reent/../../../../../../../src/newlib-1.19.0/newlib/libc/reent/signalr.c:61: undefined reference to `_kill' > /opt/arm-eCross-eabi/bin/../lib/gcc/arm-eCross-eabi/4.5.2/../../../../arm-eCross-eabi/lib/thumb/v7m/libc.a(lib_a-signalr.o): In function `_getpid_r': > /home/ole/work/eCross/newlib-build/arm-eCross-eabi/thumb/v7m/newlib/libc/reent/../../../../../../../src/newlib-1.19.0/newlib/libc/reent/signalr.c:96: undefined reference to `_getpid' > /opt/arm-eCross-eabi/bin/../lib/gcc/arm-eCross-eabi/4.5.2/../../../../arm-eCross-eabi/lib/thumb/v7m/libc.a(lib_a-sbrkr.o): In function `_sbrk_r': > /home/ole/work/eCross/newlib-build/arm-eCross-eabi/thumb/v7m/newlib/libc/reent/../../../../../../../src/newlib-1.19.0/newlib/libc/reent/sbrkr.c:60: undefined reference to `_sbrk' > collect2: ld returned 1 exit status > > > The program itself looks like this: > > #include > int main() > { > ? ?uint64_t *a,b; > ? ?volatile uint64_t c; > ? ?a = 0xaa000aa00; > > ? ?b= 0xaa00aa0000550055; > > ? ?c = b/(*a); > > ? ?if (c < 100) return 1; > > ? ?while(1); > ? ?return 0; > } > > Btw: defining a as pointer is just a trick to trick the optimizer (which > eliminates constant calculations) > > > Beside the above problem the linker complained about overlapping > sections .data with (implicit?) segments ARM.extab ad ARN.exidx > > I fixed this by adding the requested segments (see part of the > lpc17xx_flash.ld linker script below): > > ? .text : > ? ?{ > ? ? ? ?. = ALIGN(4); > ? ? ? ?_svect = .; > ? ? ? ?KEEP(*(.isr_vector)) > ? ? ? ?_evect = .; > ? ? ? ?*(.text .text.* .gnu.linkonce.t.*) > ? ? ? ?*(.rodata .rodata* .gnu.linkonce.r.*) > ? ? ? ?*(.glue_7t) > ? ? ? ?*(.glue_7) > ? ? ? ?*(.gcc_except_table) > ? ? ? ? ? ?. = ALIGN(4); > /* ? ? ? ?_etext = .;*/ > ? ?} > FLASH0 > > ? ?/* for exception handling/unwind - some Newlib functions (in common > with C++ and STDC++) use this. */ > > ? ?.ARM.extab : > ? ?{ > ? ? ? ?*(.ARM.extab* .gnu.linkonce.armextab.*) > ? ?} > ?FLASH0 > > ? ?__exidx_start = .; > ? ?.ARM.exidx : > ? ?{ > ? ? ? ?*(.ARM.exidx* .gnu.linkonce.armexidx.*) > ? ?} > ?FLASH0 > ? ?__exidx_end = .; > > ? ?_etext = .; > > ? ?.vtable (NOLOAD): > ? ?{ > ? ? ? ?. = ALIGN(4); > ? ? ? ? ? ?_vtable = .; > ? ? ? ? ? ?*(.vtable*) > ? ? ? ?. = ALIGN(4); > ? ? ? ? ? ?_evtable = .; > ? ?} > SRAM0 > > > Does anybody has an idea of what is going wrong here? > > Best regards, > > Ole Reinhardt > > -- > > Thermotemp GmbH, Embedded-IT > > Embedded Hard-/ Software and Open Source Development, > Integration and Consulting > > http://www.embedded-it.de > > Gesch?ftsstelle Siegen - Steinstra?e 67 - D-57072 Siegen - > tel +49 (0)271 5513597, +49 (0)271-73681 - fax +49 (0)271 736 97 > > Hauptsitz - Hademarscher Weg 7 - 13503 Berlin > Tel +49 (0)30 4315205 - Fax +49 (0)30 43665002 > Gesch?ftsf?hrer: J?rg Friedrichs, Ole Reinhardt > Handelsregister Berlin Charlottenburg HRB 45978 UstID DE 156329280 > > _______________________________________________ > http://lists.egnite.de/mailman/listinfo/en-nut-discussion From bon at elektron.ikp.physik.tu-darmstadt.de Tue Feb 7 17:40:19 2012 From: bon at elektron.ikp.physik.tu-darmstadt.de (Uwe Bonnes) Date: Tue, 7 Feb 2012 17:40:19 +0100 Subject: [En-Nut-Discussion] Strange newlib syscall dependencies / linker problems when using 64bit integers In-Reply-To: References: <1328566767.2181.11.camel@platon> Message-ID: <20273.21491.975139.994432@elektron.ikp.physik.tu-darmstadt.de> >>>>> "Ulrich" == Ulrich Prinz writes: Ulrich> Hi Ole, I never had this kind of problem, but I never used 64 Ulrich> bit variables... Ulrich> But... I compared the local nut/os version for cortexM3 with the Ulrich> sourceforge one and the only bigger difference is the double -L Ulrich> parameter for the linker. You remember the problem I have that Ulrich> building a simple uart example results in 14k code instead of 6k Ulrich> or less in older versions? I guess (but didn't test, cause lack Ulrich> of time) that this might be the problem. Ulrich> Can you test again with LDFLAGS = Ulrich> ...-T'path/to/linker/ldscript.ld' ... -L'path_to_libs' instead Ulrich> of LDFLAGS = ... -L'path/to/linker/' -T'ldscript.ld' Ulrich> ... -L'path_to_libs' Ulrich> It's just a feeling... Linker might test the first search path Ulrich> only and include stdlibs on failing result even the nutos libs Ulrich> exist in the second one. The order doesn't seem to make a difference: * Order as produced by our tree: arm-none-eabi-gcc owi_test.o owi_timer.o -mcpu=cortex-m3 -mthumb -mlittle-endian -D__CORTEX__ -nostartfiles -L../../../devnut_m3n_git/nut/arch/cm3/ldscripts -Tstm32f107xC_flash.ld -Wl,-Map=owi_test.map,--cref,--gc-sections -L../.././lib -Wl,--start-group ../.././lib/nutinit.o -lnutcrt -lnutarch -lnutdev -lnutos -lnutdev -lnutarch -Wl,--end-group -o owi_test.elf > arm-none-eabi-size owi_test.elf text data bss dec hex filename 24296 320 1380 25996 658c owi_test.elf * All linker specific files at the end: > arm-none-eabi-gcc owi_test.o owi_timer.o -mcpu=cortex-m3 -mthumb -mlittle-endian -D__CORTEX__ -nostartfiles -L../.././lib ../.././lib/nutinit.o -lnutcrt -lnutarch -lnutdev -lnutos -lnutdev -lnutarch -nostartfiles -L../../../devnut_m3n_git/nut/arch/cm3/ldscripts -Tstm32f107xC_flash.ld -Wl,-Map=owi_test.map,--cref,--gc-sections -Wl,--start-group -Wl,--end-group -o owi_test.elf > arm-none-eabi-size owi_test.elf text data bss dec hex filename 24296 320 1380 25996 658c owi_test.elf -- Uwe Bonnes bon at elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- From markus.dost at dr-clauss.de Wed Feb 8 07:39:51 2012 From: markus.dost at dr-clauss.de (Markus Dost) Date: Wed, 8 Feb 2012 07:39:51 +0100 Subject: [En-Nut-Discussion] Ethernut 2 + MMC Message-ID: <09CEBDA4-62FB-4FCA-B254-1EF3A3DCFD64@dr-clauss.de> Hi, did somebody used the MMC-functions with an ATmega128? In the Wiki and the Configurator it is written that the device drivers have been tested only for the AT91. Best regards, Markus From ole.reinhardt at embedded-it.de Wed Feb 8 13:15:10 2012 From: ole.reinhardt at embedded-it.de (Ole Reinhardt) Date: Wed, 08 Feb 2012 13:15:10 +0100 Subject: [En-Nut-Discussion] Strange newlib syscall dependencies / linker problems when using 64bit integers In-Reply-To: <20273.21491.975139.994432@elektron.ikp.physik.tu-darmstadt.de> References: <1328566767.2181.11.camel@platon> <20273.21491.975139.994432@elektron.ikp.physik.tu-darmstadt.de> Message-ID: <1328703310.2167.5.camel@platon> Hi! > The order doesn't seem to make a difference: Right. And the described problem does not depend on the linked libs (i tried several combinations). The simple divide test program even did not need any lib linked at all, does it? What I found out so far is that gcc implements the division by using a function "idiv" or similar, which itself depends on these syscalls to be implemented. In fact this does not rely to your problem at all. So I think we have two disjunct problems here. I just found another thread on microcontroller.net describing the same problem (but on a different platform) but their solition (to implement the newlib syscall stubs) is not really satisfying in the Nut/OS environment... What do you think? Where would you implement these syscall stubs (most of these functions just return 0, only sbrk_r has to be correctly implemented) Bye, Ole -- Thermotemp GmbH, Embedded-IT Embedded Hard-/ Software and Open Source Development, Integration and Consulting http://www.embedded-it.de Gesch?ftsstelle Siegen - Steinstra?e 67 - D-57072 Siegen - tel +49 (0)271 5513597, +49 (0)271-73681 - fax +49 (0)271 736 97 Hauptsitz - Hademarscher Weg 7 - 13503 Berlin Tel +49 (0)30 4315205 - Fax +49 (0)30 43665002 Gesch?ftsf?hrer: J?rg Friedrichs, Ole Reinhardt Handelsregister Berlin Charlottenburg HRB 45978 UstID DE 156329280 From bon at elektron.ikp.physik.tu-darmstadt.de Wed Feb 8 13:20:55 2012 From: bon at elektron.ikp.physik.tu-darmstadt.de (Uwe Bonnes) Date: Wed, 8 Feb 2012 13:20:55 +0100 Subject: [En-Nut-Discussion] Strange newlib syscall dependencies / linker problems when using 64bit integers In-Reply-To: <1328703310.2167.5.camel@platon> References: <1328566767.2181.11.camel@platon> <20273.21491.975139.994432@elektron.ikp.physik.tu-darmstadt.de> <1328703310.2167.5.camel@platon> Message-ID: <20274.26791.136327.58886@elektron.ikp.physik.tu-darmstadt.de> >>>>> "Ole" == Ole Reinhardt writes: ... Ole> I just found another thread on microcontroller.net describing the Ole> same problem (but on a different platform) but their solition (to Ole> implement the newlib syscall stubs) is not really satisfying in the Ole> Nut/OS environment... Can you give a link to that thread? Thanks -- Uwe Bonnes bon at elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- From ulrich.prinz at googlemail.com Wed Feb 8 13:46:32 2012 From: ulrich.prinz at googlemail.com (Ulrich Prinz) Date: Wed, 8 Feb 2012 13:46:32 +0100 Subject: [En-Nut-Discussion] Strange newlib syscall dependencies / linker problems when using 64bit integers In-Reply-To: <20273.21491.975139.994432@elektron.ikp.physik.tu-darmstadt.de> References: <1328566767.2181.11.camel@platon> <20273.21491.975139.994432@elektron.ikp.physik.tu-darmstadt.de> Message-ID: Got a part of it: in app/Makevars.cm3-gcc the linker lines where disabled. If you add back the line LDFLAGS = $(MCFLAGS) -nostartfiles -T$(LDSCRIPT) -Wl,-Map=$(PROJ).map,--cref,--gc-sections -L$(LIBDIR) it works without the overhead. For latest version it must be modified to LDPATH and LDNAME. Might be that you have to run 'Create Sampledirectory' from qnutconf again to apply the modification to the nutconf.mk files. Creating a local project without this modification results in a binary image of 90k, with patch applied it is 85k. Bootloader without patch is 14850 bytes, with patch applied it is 8252 bytes. Ulrich Am 7. Februar 2012 17:40 schrieb Uwe Bonnes : >>>>>> "Ulrich" == Ulrich Prinz writes: > > ? ?Ulrich> Hi Ole, I never had this kind of problem, but I never used 64 > ? ?Ulrich> bit variables... > > ? ?Ulrich> But... I compared the local nut/os version for cortexM3 with the > ? ?Ulrich> sourceforge one and the only bigger difference is the double -L > ? ?Ulrich> parameter for the linker. ?You remember the problem I have that > ? ?Ulrich> building a simple uart example results in 14k code instead of 6k > ? ?Ulrich> or less in older versions? ?I guess (but didn't test, cause lack > ? ?Ulrich> of time) that this might be the problem. > > ? ?Ulrich> Can you test again with LDFLAGS = > ? ?Ulrich> ...-T'path/to/linker/ldscript.ld' ... -L'path_to_libs' instead > ? ?Ulrich> of LDFLAGS = ... -L'path/to/linker/' -T'ldscript.ld' > ? ?Ulrich> ... -L'path_to_libs' > > ? ?Ulrich> It's just a feeling... ?Linker might test the first search path > ? ?Ulrich> only and include stdlibs on failing result even the nutos libs > ? ?Ulrich> exist in the second one. > > > > The order doesn't seem to make a difference: > * Order as produced by our tree: > > arm-none-eabi-gcc owi_test.o owi_timer.o -mcpu=cortex-m3 -mthumb -mlittle-endian -D__CORTEX__ -nostartfiles -L../../../devnut_m3n_git/nut/arch/cm3/ldscripts -Tstm32f107xC_flash.ld -Wl,-Map=owi_test.map,--cref,--gc-sections -L../.././lib -Wl,--start-group ../.././lib/nutinit.o -lnutcrt -lnutarch -lnutdev -lnutos -lnutdev -lnutarch ? -Wl,--end-group -o owi_test.elf > ?> arm-none-eabi-size owi_test.elf > ? text ? ?data ? ? bss ? ? dec ? ? hex filename > ?24296 ? ? 320 ? ?1380 ? 25996 ? ?658c owi_test.elf > > * All linker specific files at the end: >> arm-none-eabi-gcc owi_test.o owi_timer.o -mcpu=cortex-m3 -mthumb -mlittle-endian -D__CORTEX__ -nostartfiles -L../.././lib ../.././lib/nutinit.o -lnutcrt -lnutarch -lnutdev -lnutos -lnutdev -lnutarch -nostartfiles -L../../../devnut_m3n_git/nut/arch/cm3/ldscripts -Tstm32f107xC_flash.ld -Wl,-Map=owi_test.map,--cref,--gc-sections -Wl,--start-group -Wl,--end-group -o owi_test.elf > >> arm-none-eabi-size owi_test.elf > ?text ? ?data ? ? bss ? ? dec ? ? hex filename > ?24296 ? ? 320 ? ?1380 ? 25996 ? ?658c owi_test.elf > > -- > Uwe Bonnes ? ? ? ? ? ? ? ?bon at elektron.ikp.physik.tu-darmstadt.de > > Institut fuer Kernphysik ?Schlossgartenstrasse 9 ?64289 Darmstadt > --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- > _______________________________________________ > http://lists.egnite.de/mailman/listinfo/en-nut-discussion From bon at elektron.ikp.physik.tu-darmstadt.de Wed Feb 8 14:49:19 2012 From: bon at elektron.ikp.physik.tu-darmstadt.de (Uwe Bonnes) Date: Wed, 8 Feb 2012 14:49:19 +0100 Subject: [En-Nut-Discussion] Strange newlib syscall dependencies / linker problems when using 64bit integers In-Reply-To: References: <1328566767.2181.11.camel@platon> <20273.21491.975139.994432@elektron.ikp.physik.tu-darmstadt.de> Message-ID: <20274.32095.606195.13954@elektron.ikp.physik.tu-darmstadt.de> >>>>> "Ulrich" == Ulrich Prinz writes: Ulrich> Got a part of it: in app/Makevars.cm3-gcc the linker lines where Ulrich> disabled. If you add back the line LDFLAGS = $(MCFLAGS) Ulrich> -nostartfiles -T$(LDSCRIPT) Ulrich> -Wl,-Map=$(PROJ).map,--cref,--gc-sections -L$(LIBDIR) it works Ulrich> without the overhead. Ulrich> For latest version it must be modified to LDPATH and LDNAME. Ulrich> Might be that you have to run 'Create Sampledirectory' from Ulrich> qnutconf again to apply the modification to the nutconf.mk Ulrich> files. Ulrich> Creating a local project without this modification results in a Ulrich> binary image of 90k, with patch applied it is 85k. Bootloader Ulrich> without patch is 14850 bytes, with patch applied it is 8252 Ulrich> bytes. Ulrich, what exactly is missing from the command arm-none-eabi-gcc owi_test.o owi_timer.o -mcpu=cortex-m4 -mthumb -mlittle-endian -D__CORTEX__ -nostartfiles -L../../../devnut_m3n_git/nut/arch/cm3/ldscripts -Tstm32f405xG_ram.ld -Wl,-Map=owi_test.map,--cref,--gc-sections -L../.././lib -Wl,--start-group ../.././lib/nutinit.o -lnutcrt -lnutarch -lnutdev -lnutos -lnutdev -lnutarch -Wl,--end-group -o owi_test.elf as produced by devnut_m3n-SVN? Bye -- Uwe Bonnes bon at elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- From ulrich.prinz at googlemail.com Wed Feb 8 14:59:48 2012 From: ulrich.prinz at googlemail.com (Ulrich Prinz) Date: Wed, 8 Feb 2012 14:59:48 +0100 Subject: [En-Nut-Discussion] Feature Request: Create Application Directory" for (q)nutconf Message-ID: Hi all! If you develop with nutos and use (q)nutconf you like to press the button 'Create Sample Directory' and have your build system set up in the given directory. But if you develop lots of your own projects you might not like to have all the examples installed. This gets even more disturbing if you implement new architectures and have to add and change nut/app/Make*.* files that are used to create the needed NutConf.mk and others in the top application directory. With every 'Create Sample Directory' call the examples are reinstalled. So I guess it could help to add and sort the Build->xxx menu like this: 1) Create/Update Application Directory 2) Copy Examples to Application Directory Option 1 only creates or updates the given application directory Option 2 calls optionn 1 and then additionally copies over all non existing files from the nut/app directory. 3) Copy Hardware Testing Code There could be an Option 3 after we moved out the hardware driver test examples like eeprom, PCF expander and others that are very hardware dependent to a different directory. Option 3 then calls Option 1 and additionally copies all non existing files from that driver test directory to the application dir. How about that? Ulrich From ole.reinhardt at embedded-it.de Wed Feb 8 15:22:32 2012 From: ole.reinhardt at embedded-it.de (Ole Reinhardt) Date: Wed, 08 Feb 2012 15:22:32 +0100 Subject: [En-Nut-Discussion] Strange newlib syscall dependencies / linker problems when using 64bit integers In-Reply-To: <20274.26791.136327.58886@elektron.ikp.physik.tu-darmstadt.de> References: <1328566767.2181.11.camel@platon> <20273.21491.975139.994432@elektron.ikp.physik.tu-darmstadt.de> <1328703310.2167.5.camel@platon> <20274.26791.136327.58886@elektron.ikp.physik.tu-darmstadt.de> Message-ID: <1328710952.2167.19.camel@platon> Hi Uwe, > Can you give a link to that thread? here it is: http://embdev.net/topic/129607 It's the english version of microcontroller.net Btw: It's no problem of cortex but also shows on other platforms as you read in the thread (they use a ARM7) bye, Ole -- Thermotemp GmbH, Embedded-IT Embedded Hard-/ Software and Open Source Development, Integration and Consulting http://www.embedded-it.de Gesch?ftsstelle Siegen - Steinstra?e 67 - D-57072 Siegen - tel +49 (0)271 5513597, +49 (0)271-73681 - fax +49 (0)271 736 97 Hauptsitz - Hademarscher Weg 7 - 13503 Berlin Tel +49 (0)30 4315205 - Fax +49 (0)30 43665002 Gesch?ftsf?hrer: J?rg Friedrichs, Ole Reinhardt Handelsregister Berlin Charlottenburg HRB 45978 UstID DE 156329280 From ole.reinhardt at embedded-it.de Wed Feb 8 15:25:01 2012 From: ole.reinhardt at embedded-it.de (Ole Reinhardt) Date: Wed, 08 Feb 2012 15:25:01 +0100 Subject: [En-Nut-Discussion] Ethernut 2 + MMC In-Reply-To: <09CEBDA4-62FB-4FCA-B254-1EF3A3DCFD64@dr-clauss.de> References: <09CEBDA4-62FB-4FCA-B254-1EF3A3DCFD64@dr-clauss.de> Message-ID: <1328711101.2167.21.camel@platon> Hi Markus, > did somebody used the MMC-functions with an ATmega128? In the Wiki and > the Configurator it is written that the device drivers have been > tested only for the AT91. Sure, it is available on every Ethernut 1.3 and 2.x board... Can you please give me a link, where it is written that it's only tested on the AT91 platform? There are several different MMC drivers available. Perhaps you looked at the AT91 driver? Bye, Ole -- Thermotemp GmbH, Embedded-IT Embedded Hard-/ Software and Open Source Development, Integration and Consulting http://www.embedded-it.de Gesch?ftsstelle Siegen - Steinstra?e 67 - D-57072 Siegen - tel +49 (0)271 5513597, +49 (0)271-73681 - fax +49 (0)271 736 97 Hauptsitz - Hademarscher Weg 7 - 13503 Berlin Tel +49 (0)30 4315205 - Fax +49 (0)30 43665002 Gesch?ftsf?hrer: J?rg Friedrichs, Ole Reinhardt Handelsregister Berlin Charlottenburg HRB 45978 UstID DE 156329280 From ole.reinhardt at embedded-it.de Wed Feb 8 15:52:40 2012 From: ole.reinhardt at embedded-it.de (Ole Reinhardt) Date: Wed, 08 Feb 2012 15:52:40 +0100 Subject: [En-Nut-Discussion] Feature Request: Create Application Directory" for (q)nutconf In-Reply-To: References: Message-ID: <1328712760.2167.51.camel@platon> Hi Ulrich, > But if you develop lots of your own projects you might not like to > have all the examples installed. Yes, I well know this problem. I personally prefer to have a pre-compiled Nut/OS and to use just a few simple makefiles with my application, not all this directory hirarchy. Especialy when deploying Nut/OS as development environment for a board your customers won't ever compile Nut/OS by their own but just use the ready build libraries. So what I would suggest is to add an "Install Nut/OS" which would build the libraries, install it into a folder and add the necessary makefiles (just the ones for your compiler setting) As an example see http://www.embedded-it.de/bsp-download/webserver_relais_demo.tar.gz (folder Nut/OS) I also modified the application standard makefiles to refer to the pre-installed ones. Another idea: This install button could also copy the header files so that one would not have to install the whole source tree too. Bye, Ole -- Thermotemp GmbH, Embedded-IT Embedded Hard-/ Software and Open Source Development, Integration and Consulting http://www.embedded-it.de Gesch?ftsstelle Siegen - Steinstra?e 67 - D-57072 Siegen - tel +49 (0)271 5513597, +49 (0)271-73681 - fax +49 (0)271 736 97 Hauptsitz - Hademarscher Weg 7 - 13503 Berlin Tel +49 (0)30 4315205 - Fax +49 (0)30 43665002 Gesch?ftsf?hrer: J?rg Friedrichs, Ole Reinhardt Handelsregister Berlin Charlottenburg HRB 45978 UstID DE 156329280 From info at pragmalab.nl Wed Feb 8 22:10:31 2012 From: info at pragmalab.nl (PragmaLab (Rob van Lieshout)) Date: Wed, 8 Feb 2012 22:10:31 +0100 Subject: [En-Nut-Discussion] Ethernut 2 + MMC In-Reply-To: References: Message-ID: <010b01cce6a6$173ff990$45bfecb0$@nl> >did somebody used the MMC-functions with an ATmega128? In the Wiki and >the Configurator it is written that the device drivers have been >tested only for the AT91. Hi Markus, Do you mean the MMCard module? That's used for SD-cards as well, and yes, we used it with ATmega128 and ATmega256. Works fine. Be aware that it depends on a low-level block device driver for the actual communication. Regards, Rob van Lieshout From markus.dost at dr-clauss.de Thu Feb 9 08:58:26 2012 From: markus.dost at dr-clauss.de (Markus Dost) Date: Thu, 9 Feb 2012 08:58:26 +0100 Subject: [En-Nut-Discussion] Ethernut 5 + Eclipse tutorial Message-ID: <70E051BE-4CD4-48C1-81D3-8AEC4A889653@dr-clauss.de> Hi, I have the next question/problem. I want to pass the tutorial to build and debug applications with the Ethernut 5 and the Eclipse IDE: http://www.ethernut.de/en/hardware/enut5/debugging.html But when I want to build the project, Eclipse puts out "Cannot run program "make" ". I have no idea, what I've made wrong. The path- variable for yargarto is set correctly. When I try to build the application with the cmd.exe and the command "make all", it works. Best regards, Markus From hmnews at proconx.com Fri Feb 10 06:39:44 2012 From: hmnews at proconx.com (Henrik Maier) Date: Fri, 10 Feb 2012 15:39:44 +1000 Subject: [En-Nut-Discussion] Possible race condition in DHCP and DHCPKick Message-ID: <4F34ADA0.3070002@proconx.com> Hi all, it appears that there is a race condition in DHCP, routine DhcpKick(): I observed cases where the following sequence would cause a system lock-up because the NutEventWait/dhcpDone condition is never fullfilled. Some debugging and analysis of the order of events sent and received between the caller and DHCP thread shows, that there are cases where NutEventPost does a context switch and the dhcpDone event is sent before(!) NutEventWait(&dhcpDone) is called resulting the subsequent call of NutEventWait(&dhcpDone) to never return. ... NutEventPost(&dhcpWake); NutEventWait(&dhcpDone, NUT_WAIT_INFINITE); ... The issue seems to be fixed once above NutEventPost is changed to a NutEventPostAsync which avoids the context switch before NutEventWait is called: ... NutEventPostAsync(&dhcpWake); NutEventWait(&dhcpDone, NUT_WAIT_INFINITE); ... If there are no objections or further insight into this topic, I would submit a bug report to tracker and a patch. I think in most applications DhcpKick is only called once during system start and the issue does not come up. But if a system changes from DHCP to statically allocated IP addresses or vice versa, DhcpKick is called on every change and the issue comes to surface. Regards Henrik Maier From bon at elektron.ikp.physik.tu-darmstadt.de Fri Feb 10 10:56:09 2012 From: bon at elektron.ikp.physik.tu-darmstadt.de (Uwe Bonnes) Date: Fri, 10 Feb 2012 10:56:09 +0100 Subject: [En-Nut-Discussion] branches\devnut_m3n and STM32F2 devices In-Reply-To: References: Message-ID: <20276.59833.948122.425414@elektron.ikp.physik.tu-darmstadt.de> >>>>> "Guillaume" == Guillaume Fortaine writes: Guillaume> Dear Mister Bonnes, Mister Prinz, and Mister Maier First of Guillaume> all, I would like to wish you and the people around you an Guillaume> happy new year. Guillaume> Let me introduce myself : Guillaume FORTAINE, Cloudpreneur : Guillaume> http://www.linkedin.com/in/gfortaine Guillaume> I have read with interest the discussion entitled Guillaume> "branches\devnut_m3n and STM32F2 devices" [0]. Given that Guillaume> there is an Ethernet design available around the STM32 F-2, I Guillaume> would greatly appreciate to know if you plan to port the Guillaume> Ethernut project to it, if possible, please : In my personal git tree, I have the basic devices somehow working with STM32L and STM32F1/2/4. I will commit my changes hopefully soon. Why a local git tree: It allows to edit older commits and so try and error will not result in a tons of commit. But no work on the yet unsupported/ partial supported devices has been done... Bye -- Uwe Bonnes bon at elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- From harald.kipp at egnite.de Sat Feb 11 12:12:09 2012 From: harald.kipp at egnite.de (Harald Kipp) Date: Sat, 11 Feb 2012 12:12:09 +0100 Subject: [En-Nut-Discussion] Ethernut 5 + Eclipse tutorial In-Reply-To: <70E051BE-4CD4-48C1-81D3-8AEC4A889653@dr-clauss.de> References: <70E051BE-4CD4-48C1-81D3-8AEC4A889653@dr-clauss.de> Message-ID: <4F364D09.9020602@egnite.de> Hi Markus, On 09.02.2012 08:58, Markus Dost wrote: > I have the next question/problem. I want to pass the tutorial to build > and debug applications with the Ethernut 5 and the Eclipse IDE: > http://www.ethernut.de/en/hardware/enut5/debugging.html Please note, that I recently added an updated, more general guide http://www.ethernut.de/en/tools/eclipse/ > But when I want to build the project, Eclipse puts out "Cannot run > program "make" ". I have no idea, what I've made wrong. The path- > variable for yargarto is set correctly. Guess, your PC is running Windows. You need to add the path to x:\ethernut-x.y\nut\tools\win32 http://www.ethernut.de/img/indigo-project-prop-build-env.png Hope, this helps, Harald From ole.reinhardt at embedded-it.de Sat Feb 11 17:20:50 2012 From: ole.reinhardt at embedded-it.de (Ole Reinhardt) Date: Sat, 11 Feb 2012 17:20:50 +0100 Subject: [En-Nut-Discussion] Possible race condition in DHCP and DHCPKick In-Reply-To: <4F34ADA0.3070002@proconx.com> References: <4F34ADA0.3070002@proconx.com> Message-ID: <1328977250.2984.17.camel@platon> Hi Henrik, I just looked into the code and for me it seems very likely that this race condition can occur. The problem can occur, as the dhcp code often first signals dhcpDone and waits then for a wake which might result in a race condition. But shouldn't we change the other places as well: multiple times in NutDhcpClient() ... NutEventBroadcast(&dhcpDone); NutEventWait(&dhcpWake, NUT_WAIT_INFINITE); ... To ... mutiple time: NutEventBroadcastAsync(&dhcpDone); NutEventWait(&dhcpWake, NUT_WAIT_INFINITE); ... And another more complex situation: else if (dhcpState == DHCPST_BOUND) { retries = 0; NutEventBroadcast(&dhcpDone); if (dhcpConfig->dyn_renewalTime <= NutGetSeconds() - leaseTime) { dhcpState = DHCPST_RENEWING; } else { /* Calculate the remaining lease time and take a nap. */ napTime = dhcpConfig->dyn_renewalTime - (NutGetSeconds() - leaseTime); if (napTime > MAX_DHCP_NAPTIME) { napTime = MAX_DHCP_NAPTIME; } NutEventWait(&dhcpWake, napTime * 1000UL); } } to else if (dhcpState == DHCPST_BOUND) { uint32_t now = NutGetSeconds(); retries = 0; NutEventBroadcastAsync(&dhcpDone); if (dhcpConfig->dyn_renewalTime <= now - leaseTime) { dhcpState = DHCPST_RENEWING; } else { /* Calculate the remaining lease time and take a nap. */ napTime = dhcpConfig->dyn_renewalTime - (now - leaseTime); if (napTime > MAX_DHCP_NAPTIME) { napTime = MAX_DHCP_NAPTIME; } NutEventWait(&dhcpWake, napTime * 1000UL); } } The above is more complex as NutGetSeconds also could result in a context switch. Regards, Ole -- Thermotemp GmbH, Embedded-IT Embedded Hard-/ Software and Open Source Development, Integration and Consulting http://www.embedded-it.de Gesch?ftsstelle Siegen - Steinstra?e 67 - D-57072 Siegen - tel +49 (0)271 5513597, +49 (0)271-73681 - fax +49 (0)271 736 97 Hauptsitz - Hademarscher Weg 7 - 13503 Berlin Tel +49 (0)30 4315205 - Fax +49 (0)30 43665002 Gesch?ftsf?hrer: J?rg Friedrichs, Ole Reinhardt Handelsregister Berlin Charlottenburg HRB 45978 UstID DE 156329280 From ulrich.prinz at googlemail.com Sun Feb 12 12:30:57 2012 From: ulrich.prinz at googlemail.com (Ulrich Prinz) Date: Sun, 12 Feb 2012 12:30:57 +0100 Subject: [En-Nut-Discussion] Feature Request: Create Application Directory" for (q)nutconf In-Reply-To: <1328712760.2167.51.camel@platon> References: <1328712760.2167.51.camel@platon> Message-ID: <4F37A2F1.1060302@googlemail.com> Hi! At first the separation of directory and makefile generation from creation of all examples would be very helpfull. To add an option that enables to export all libraries and headers and creates a set of working application makefiles is very fine. We often need to keep nut/os libraries synced with the application source code to be able to reproduce avery single software release. So if we could export the libraries and headers in parallel with the applications it would be very handy for checking them in to SVN or GIT. Ulrich Am 08.02.2012 15:52, schrieb Ole Reinhardt: > Hi Ulrich, > >> But if you develop lots of your own projects you might not like to >> have all the examples installed. > > Yes, I well know this problem. I personally prefer to have a > pre-compiled Nut/OS and to use just a few simple makefiles with my > application, not all this directory hirarchy. > > Especialy when deploying Nut/OS as development environment for a board > your customers won't ever compile Nut/OS by their own but just use the > ready build libraries. > > So what I would suggest is to add an "Install Nut/OS" which would build > the libraries, install it into a folder and add the necessary makefiles > (just the ones for your compiler setting) > > As an example see > > http://www.embedded-it.de/bsp-download/webserver_relais_demo.tar.gz > > (folder Nut/OS) > > I also modified the application standard makefiles to refer to the > pre-installed ones. > > Another idea: > > This install button could also copy the header files so that one would > not have to install the whole source tree too. > > Bye, > > Ole > > From ulrich.prinz at googlemail.com Sun Feb 12 12:47:54 2012 From: ulrich.prinz at googlemail.com (Ulrich Prinz) Date: Sun, 12 Feb 2012 12:47:54 +0100 Subject: [En-Nut-Discussion] Possible race condition in DHCP and DHCPKick In-Reply-To: <1328977250.2984.17.camel@platon> References: <4F34ADA0.3070002@proconx.com> <1328977250.2984.17.camel@platon> Message-ID: <4F37A6EA.20003@googlemail.com> Hi! I will forward this to Daniel, a colleague of me who implements STM32F107 EMAC actually. He did a lot testing/designing from bottom up through the OSI model and fixed some other places too. He also implemented my idea of phy.c. Am 11.02.2012 17:20, schrieb Ole Reinhardt: > Hi Henrik, > > > > And another more complex situation: > > > else if (dhcpState == DHCPST_BOUND) { > retries = 0; > NutEventBroadcast(&dhcpDone); > if (dhcpConfig->dyn_renewalTime <= NutGetSeconds() - > leaseTime) { > dhcpState = DHCPST_RENEWING; > } else { > /* Calculate the remaining lease time and take a nap. */ > napTime = dhcpConfig->dyn_renewalTime - (NutGetSeconds() > - leaseTime); > if (napTime > MAX_DHCP_NAPTIME) { > napTime = MAX_DHCP_NAPTIME; > } > NutEventWait(&dhcpWake, napTime * 1000UL); > } > } > > to > > else if (dhcpState == DHCPST_BOUND) { > uint32_t now = NutGetSeconds(); > retries = 0; > NutEventBroadcastAsync(&dhcpDone); > if (dhcpConfig->dyn_renewalTime <= now - leaseTime) { > dhcpState = DHCPST_RENEWING; > } else { > /* Calculate the remaining lease time and take a nap. */ > napTime = dhcpConfig->dyn_renewalTime - (now - > leaseTime); > if (napTime > MAX_DHCP_NAPTIME) { > napTime = MAX_DHCP_NAPTIME; > } > NutEventWait(&dhcpWake, napTime * 1000UL); > } > } > > The above is more complex as NutGetSeconds also could result in a > context switch. Isn't it more reliably to redesign dhcp into an active and a passive part. The active part can work with post/wait and simply offers a current_state variable like dhcpState. If DHCP_BOUND or DHCP_TOUT is reached it goes to sleep and wait for a restart-event. The passive part only uses nutsleep(1000) and polls dhcpState for spreading needed actions onto the stack and, if needed, wakes the active thread above. In that case only one thread is receiver and one is sender of an event. If in that situation an event of the active part is missed by the passive part, the next revolution of the passive part will get it. With that no race conditions can occur anymore. Ulrich From ole.reinhardt at embedded-it.de Sun Feb 12 19:00:01 2012 From: ole.reinhardt at embedded-it.de (Ole Reinhardt) Date: Sun, 12 Feb 2012 19:00:01 +0100 Subject: [En-Nut-Discussion] Possible race condition in DHCP and DHCPKick In-Reply-To: <4F37A6EA.20003@googlemail.com> References: <4F34ADA0.3070002@proconx.com> <1328977250.2984.17.camel@platon> <4F37A6EA.20003@googlemail.com> Message-ID: <1329069601.2501.16.camel@platon> Hi! > Isn't it more reliably to redesign dhcp into an active and a passive > part. The active part can work with post/wait and simply offers a > current_state variable like dhcpState. > If DHCP_BOUND or DHCP_TOUT is reached it goes to sleep and wait for a > restart-event. Good Idea! Please go ahead! (Or your college :) I just looked over the code without taking a redesign into account. As the DHCP part made several problems in the past a redesign might be the better choice. bye, Ole -- Thermotemp GmbH, Embedded-IT Embedded Hard-/ Software and Open Source Development, Integration and Consulting http://www.embedded-it.de Gesch?ftsstelle Siegen - Steinstra?e 67 - D-57072 Siegen - tel +49 (0)271 5513597, +49 (0)271-73681 - fax +49 (0)271 736 97 Hauptsitz - Hademarscher Weg 7 - 13503 Berlin Tel +49 (0)30 4315205 - Fax +49 (0)30 43665002 Gesch?ftsf?hrer: J?rg Friedrichs, Ole Reinhardt Handelsregister Berlin Charlottenburg HRB 45978 UstID DE 156329280 From ulrich.prinz at googlemail.com Sun Feb 12 18:55:15 2012 From: ulrich.prinz at googlemail.com (Ulrich Prinz) Date: Sun, 12 Feb 2012 18:55:15 +0100 Subject: [En-Nut-Discussion] Anybody on Embedded World 2012? In-Reply-To: <1328174237.2086.12.camel@platon> References: <1328174237.2086.12.camel@platon> Message-ID: <4F37FD03.7080309@googlemail.com> Hi! Some of my colleagues and I plan to go there, but a date has not been fixed. CeBit is right after that and we need to be prepared to show up there shortly on request. So I will write a date when the car is ordered :) Ulrich Am 02.02.2012 10:17, schrieb Ole Reinhardt: > Hi all, > > just to be the first, I'm curious if anybody (beside of Egnite :-) will > be on the Embedded World this year. > > Perhaps we could meet again? > > Right now I plan to be there at 28.02 or 29.02.2012 > > Bye, > > Ole > From markus.dost at dr-clauss.de Mon Feb 13 09:02:11 2012 From: markus.dost at dr-clauss.de (Markus Dost) Date: Mon, 13 Feb 2012 09:02:11 +0100 Subject: [En-Nut-Discussion] Ethernut 5 + Eclipse tutorial In-Reply-To: <4F364D09.9020602@egnite.de> References: <70E051BE-4CD4-48C1-81D3-8AEC4A889653@dr-clauss.de> <4F364D09.9020602@egnite.de> Message-ID: Hi Harald Am 11.02.2012 um 12:12 schrieb Harald Kipp: >> But when I want to build the project, Eclipse puts out "Cannot run >> program "make" ". I have no idea, what I've made wrong. The path- >> variable for yargarto is set correctly. > > Guess, your PC is running Windows. You need to add the path to > > x:\ethernut-x.y\nut\tools\win32 > > http://www.ethernut.de/img/indigo-project-prop-build-env.png I did that. Additional the WinAVR-package is installed and added to the path-variable, too. So eclipse should find the make.exe twice. Best regards, Markus From joerg.wiegelmann at gmx.de Mon Feb 13 21:20:37 2012 From: joerg.wiegelmann at gmx.de (Joerg Wiegelmann) Date: Mon, 13 Feb 2012 21:20:37 +0100 Subject: [En-Nut-Discussion] Atmega 2561with more than 128k code and Winavr Message-ID: <4F397095.3020708@gmx.de> Hey folks, I would like to use the atmega2561 with more than 128kByte code. When I compile my application I got a bunch of linking errors like: D:/nut/nutbld/lib\libnutarch.a(usart0avr.o):(.data+0x6c): warning: internal error: out of range error D:/nut/nutbld/lib\libnutarch.a(usart0avr.o):(.data+0x6e): warning: internal error: out of range error Does anyone has an idea? Does anyone work with more than 128kByte code and Winavr? Compiler gcc version 4.3.3 (WinAVR 20100110), NutOS Version 4.10, Windows system. Thanks Joerg From bon at elektron.ikp.physik.tu-darmstadt.de Mon Feb 13 23:32:55 2012 From: bon at elektron.ikp.physik.tu-darmstadt.de (Uwe Bonnes) Date: Mon, 13 Feb 2012 23:32:55 +0100 Subject: [En-Nut-Discussion] Atmega 2561with more than 128k code and Winavr In-Reply-To: <4F397095.3020708@gmx.de> References: <4F397095.3020708@gmx.de> Message-ID: <20281.36759.32008.174174@elektron.ikp.physik.tu-darmstadt.de> >>>>> "Joerg" == Joerg Wiegelmann writes: Joerg> Hey folks, I would like to use the atmega2561 with more than Joerg> 128kByte code. When I compile my application I got a bunch of Joerg> linking errors like: Joerg> D:/nut/nutbld/lib\libnutarch.a(usart0avr.o):(.data+0x6c): Joerg> warning: internal error: out of range error Joerg> D:/nut/nutbld/lib\libnutarch.a(usart0avr.o):(.data+0x6e): Joerg> warning: internal error: out of range error Does anyone has an Joerg> idea? Does anyone work with more than 128kByte code and Winavr? Joerg> Compiler gcc version 4.3.3 (WinAVR 20100110), NutOS Version 4.10, Joerg> Windows system. I think, gcc has problems with AVR and CODE bigger than 128 k. -- Uwe Bonnes bon at elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- From guillaume.fortaine at devopspace.com Tue Feb 14 04:14:16 2012 From: guillaume.fortaine at devopspace.com (Guillaume Fortaine) Date: Tue, 14 Feb 2012 04:14:16 +0100 Subject: [En-Nut-Discussion] Fwd: Thermotemp : eNet sam3X In-Reply-To: References: Message-ID: ---------- Forwarded message ---------- From: Guillaume Fortaine Date: Sat, Feb 11, 2012 at 9:16 PM Subject: Thermotemp : eNet sam3X To: ole.reinhardt at embedded-it.de Cc: Henrik Maier , Ulrich Prinz , bon at elektron.ikp.physik.tu-darmstadt.de Dear Mister Reinhardt, First of all, I would like to wish you and the people around you an happy new year. Let me introduce myself : Guillaume FORTAINE, Cloudpreneur : http://www.linkedin.com/in/gfortaine Having seen with interest the news about your eNet sam3X ?project, I would greatly appreciate to have more informations about it, if possible, please. To quote [0] : "01.03.2011 Cortex M3 version of the module sam7X eNet-planned! from Q3/Q4 2011 is a version of the Cortex M3-sam7X eNet module will be available. The eNet sam3X-module course is pin compatible and is based on the Atmel CPU Sam3X! First engineering samples will be available shortly" Especially, ?I would greatly appreciate to know how it compares against : -ST Cortex M3 STM32F207 Development Board Ethernet USB Device/Host CAN [1] -etherarm [2] : "This hardware is similar in concept to the Maple hardware from leaf labs. The reason for diverging from their approach is to use the LM3S series of Cortex-M3 processors from TI; the particular processor selected features an integrated Ethernet MAC and PHY providing Ethernet without requiring an additional external PHY." By the way, do you plan a devnut_m3n Ethernut branch port for it [3] ? "devnut_m3n branch of the SVN ethernut tree, used for housekeeping." I look forward to your answer, Best Regards, [0] http://embedded-it.de/ [1] http://www.ebay.com/itm/ws/eBayISAPI.dll?ViewItem&item=190638488534 [2] http://code.google.com/p/etherarm/ [3] https://github.com/UweBonnes/devnut_m3n -- Guillaume FORTAINE guillaume.fortaine at devopspace.com DevOpSpace http://www.devopspace.com +33(0)631.092.519 From guillaume.fortaine at devopspace.com Tue Feb 14 04:15:11 2012 From: guillaume.fortaine at devopspace.com (Guillaume Fortaine) Date: Tue, 14 Feb 2012 04:15:11 +0100 Subject: [En-Nut-Discussion] Fwd: Nut/Net (was Re: branches\devnut_m3n and STM32F2 devices) In-Reply-To: References: Message-ID: ---------- Forwarded message ---------- From: Guillaume Fortaine Date: Sat, Feb 11, 2012 at 9:36 PM Subject: Nut/Net (was Re: branches\devnut_m3n and STM32F2 devices) To: Henrik Maier Cc: Ulrich Prinz , bon at elektron.ikp.physik.tu-darmstadt.de, ole.reinhardt at embedded-it.de Dear Mister Maier, Thank you for your comprehensive reply. > I would suggest to shift this discussion into the Nut/Os mailing list rather > continuing it as private mail. The topic raised by Guillaume should be > discussed more broadly in the Nut/Os community. I am fine with this statement and I have just subscribed to the "En-Nut-Discussion" mailing-list : http://lists.egnite.de/mailman/listinfo/en-nut-discussion > Guillaume, you also mention ChibiOS in your mail. But we are talking about > Nut/OS here, a very different OS which for example does not require lwIP and > offers a far superior TCP/IP stack than lwIP. I would greatly appreciate that you develop your comment, if possible, please. Especially, could you provide any benchmark ? http://lists.gnu.org/archive/html/lwip-users/2011-11/msg00071.html "In fact, I have developed ftp server with lwIP, it works well enough ..and support FlashFXP and FileZilla utility. The download speed is 200KB/s and upload speed is 40KB/s in my Cortex M3 with spi flash AT45DB321D." By the way, from my point of view, Nut/Net has two main critical drawbacks : -No IPv6 support : http://www.ethernut.de/nutwiki/Nut/OS_Roadmap#IPv6 "I recently looked into Adam Dunkels' uIP again, which supports IPv6. To me it doesn't look complicated. Quite the contrary, as it is limited to single layer only and a few variables. As a first action, I'd suggest to add it to the feature request list at SourceForge." *lwIP supports IPv6 : http://git.savannah.gnu.org/cgit/lwip.git/tree/CHANGELOG "2011-05-17: Patch by Ivan Delamer (only checked in by Simon Goldschmidt) ?* nearly the whole stack: Finally, we got decent IPv6 support, big thanks to ? Ivan! (this is work in progress: we're just post release anyway :-)" -Nut/Net is not easily portable : http://embedded-source.blogspot.com/2010/01/nutos.html "Nut/Net is designed for Nut/OS and not easy to port to other OS because it uses many Nut/OS specific calls." *lwIP has been ported to many RTOS : http://lwip.wikia.com/wiki/Projects_that_use_lwIP -FreeRTOS : http://www.freertos.org/portsam7xlwIP.html "lwIP Embedded Web Server Demo" -RT-Thread : http://code.google.com/p/rt-thread/wiki/Lwip_140_MigrationGuide "lwip1.4 Migration Guide" -ChibiOS/RT : http://www.chibios.org/dokuwiki/doku.php "Support for external components uIP, lwIP, FatFs." -tmos : http://code.google.com/p/tmos/source/browse/trunk/tmos/services/#services%2Flwip-1.4.0.rc1 "lwip-1.4.0.rc1" I look forward to your answer, Best Regards, -- Guillaume FORTAINE guillaume.fortaine at devopspace.com DevOpSpace http://www.devopspace.com +33(0)631.092.519 On Sat, Feb 11, 2012 at 12:42 AM, Henrik Maier wrote: > Hi all, > > I would suggest to shift this discussion into the Nut/Os mailing list rather > continuing it as private mail. The topic raised by Guillaume should be > discussed more broadly in the Nut/Os community. > > So please post questions and replies to the NutOS mailing list: > > ? ? ? ?en-nut-discussion at egnite.de > > Guillaume, you also mention ChibiOS in your mail. But we are talking about > Nut/OS here, a very different OS which for example does not require lwIP and > offers a far superior TCP/IP stack than lwIP. > > Regards > > Henrik Maier > > > On 11/02/2012 12:29 AM, Guillaume Fortaine wrote: >> >> Dear Mister Prinz, >> >> Thank you for your comprehensive reply. >> >> >>> I hope you understand that this cannot be our intention. >> >> >> I am fine with this statement. So do you plan to leverage the CMSIS >> RTOS API instead ? >> >> http://forum.chibios.org/phpbb/viewtopic.php?f=3&t=272 >> >> "Starting from version 3.0, CMSIS will define a specific RTOS API, the >> preview is already available here: >> >> http://www.onarm.com/cmsis/download/19/version-3-0-preview-of-the-cortex-microcontroller-software-interface-standard-cmsis/ >> >> This API will allow to design RTOS-independent components. My idea is >> to focus the kernel development after version 2.4.0 on providing a >> compliant API, the new API would wrap/supplement the normal ChibiOS >> API not replace it, I still think it is particularly efficient and >> elegant. >> >> This development is interesting because it will possible to design >> complex components (file systems, networking stacks) without have to >> use a vendor specific interface. For example a stack like lwIP could >> simply assume that API instead of defining its own RTOS wrapper." >> >> >> I look forward to your answer, >> >> Best Regards, >> >> -- >> Guillaume FORTAINE >> guillaume.fortaine at devopspace.com >> DevOpSpace >> http://www.devopspace.com >> +33(0)631.092.519 >> >> >> On Fri, Feb 10, 2012 at 2:37 PM, Ulrich Prinz >> ?wrote: >>> >>> Hello Guillaume, >>> >>> >>> I need to agree with Uwe Bonnes statement. The whole team put a lot of >>> energy to get STM32 and later other CortexM based CPUs working in a >>> system that can be used free for any hobby and commercial development. >>> The work we did can only be done cause we can use the results >>> commecially. Unfortunately GPL license is (as Texas Instrument calles >>> it) a virulent license. That means that adding code that is GPL often >>> requires additional code directly connected also has to be converted >>> to GPL too. So GPL eats up part by part all code of the system and >>> therefore makes it impossible to generate a commercial code. >>> >>> You might say that linux is used commercialy too and I agree as I do >>> this myself too. But it generates a lot of development to keep your >>> core knowledge and your own inventions apart from the GPL linux code. >>> But it is possible to do it as Linux offers enough standarized >>> connections for your software that you then keep secret. >>> >>> Nut/OS is a system optimized for extremely small controllers, hardly >>> or impossible to run (uc-)linux. So your application software can and >>> must connect more tight to the system to work fast and efficient. With >>> GPL applied you will be forced to open lots of your application code >>> to everyone. >>> >>> I hope you understand that this cannot be our intention. >>> >>> Best regards >>> Ulrich >>> >>> Am 10. Februar 2012 05:27 schrieb Henrik Maier: >>>> >>>> Hello Guillaume Fortaine, >>>> >>>> The libopencm3 is GPL and because of this not license compatible with >>>> Nut/OS >>>> and therefore cannot be used. I remember seeing discussions to change >>>> the >>>> license of libopencm3 to LGPL but this was rejected. >>>> >>>> See >>>> >>>> http://www.hermann-uwe.de/blog/libopenstm32-a-free-software-firmware-library-for-stm32-arm-cortex-m3-microcontrollers >>>> >>>> Best Regards >>>> >>>> Henrik Maier >>>> >>>> >>>> >>>> On 10/02/2012 12:58 PM, Guillaume Fortaine wrote: >>>>> >>>>> >>>>> Dear Mister Bonnes, Mister Prinz, and Mister Maier >>>>> >>>>> First of all, I would like to wish you and the people around you an >>>>> happy new year. >>>>> >>>>> Let me introduce myself : Guillaume FORTAINE, Cloudpreneur : >>>>> >>>>> http://www.linkedin.com/in/gfortaine >>>>> >>>>> I have read with interest the discussion entitled "branches\devnut_m3n >>>>> and STM32F2 devices" [0]. Given that there is an Ethernet design >>>>> available around the STM32 F-2, >>>>> I would greatly appreciate to know if you plan to port the Ethernut >>>>> project to it, if possible, please ?: >>>>> >>>>> http://cgi.ebay.fr/ws/eBayISAPI.dll?ViewItem&item=190638488534 >>>>> >>>>> "ST Cortex M3 STM32F207 Development Board Ethernet USB Device/Host CAN" >>>>> >>>>> >>>>> By the way, to quote [0] : >>>>> >>>>> "What I thought I do for now is to create an new subdir under >>>>> branches\devnut_m3n\arch\cm3\dev called stm32f2 which temporarily >>>>> holds the drivers I ported across from the stm directory. Once that >>>>> becomes all stable and working I can work with the other STM32F1 >>>>> developers to maybe merge those files into one driver set suitable for >>>>> F1, F2 and maybe even F4 devices. I like to avoid as much code >>>>> duplication as possible." >>>>> >>>>> >>>>> Wouldn't it be better to leverage the libopencm3 project ? >>>>> >>>>> http://libopencm3.org/ >>>>> >>>>> "The libopencm3 project (previously known as libopenstm32) aims to >>>>> create a free/libre/open-source (GPL v3, or later) firmware library >>>>> for various ARM Cortex-M3 microcontrollers, including ST STM32, >>>>> Toshiba TX03, Atmel SAM3U, NXP LPC1000 and others." >>>>> >>>>> >>>>> I look forward to your answer, >>>>> >>>>> Best Regards, >>>>> >>>>> [0] >>>>> >>>>> http://lists.egnite.de/pipermail/en-nut-discussion/2011-December/013183.html >>>>> >>>>> -- >>>>> Guillaume FORTAINE >>>>> guillaume.fortaine at devopspace.com >>>>> DevOpSpace >>>>> http://www.devopspace.com >>>>> +33(0)631.092.519 >>>>> >>>> >> > From guillaume.fortaine at devopspace.com Tue Feb 14 04:15:45 2012 From: guillaume.fortaine at devopspace.com (Guillaume Fortaine) Date: Tue, 14 Feb 2012 04:15:45 +0100 Subject: [En-Nut-Discussion] Fwd: Nut/OS BSD License (was Re: branches\devnut_m3n and STM32F2 devices) In-Reply-To: References: Message-ID: ---------- Forwarded message ---------- From: Guillaume Fortaine Date: Sat, Feb 11, 2012 at 9:41 PM Subject: Nut/OS BSD License (was Re: branches\devnut_m3n and STM32F2 devices) To: Ulrich Prinz Cc: Henrik Maier , bon at elektron.ikp.physik.tu-darmstadt.de, ole.reinhardt at embedded-it.de, Gareth McMullin , uwe at hermann-uwe.de, Piotr Esden-Tempski Dear Mister Prinz, Thank you for your comprehensive reply. > Unfortunately GPL license is (as Texas Instrument calles > it) a virulent license. That means that adding code that is GPL often > requires additional code directly connected also has to be converted > to GPL too. So GPL eats up part by part all code of the system and > therefore makes it impossible to generate a commercial code. I would greatly appreciate to invite you to a further reading of the article entitled "Opinion: License to FUD (comparing GPL and BSD)" : http://www.linuxfordevices.com/c/a/Linux-For-Devices-Articles/Opinion-License-to-FUD-comparing-GPL-and-BSD/ Best Regards, -- Guillaume FORTAINE guillaume.fortaine at devopspace.com DevOpSpace http://www.devopspace.com +33(0)631.092.519 On Fri, Feb 10, 2012 at 2:37 PM, Ulrich Prinz wrote: > Hello Guillaume, > > I need to agree with Uwe Bonnes statement. The whole team put a lot of > energy to get STM32 and later other CortexM based CPUs working in a > system that can be used free for any hobby and commercial development. > The work we did can only be done cause we can use the results > commecially. Unfortunately GPL license is (as Texas Instrument calles > it) a virulent license. That means that adding code that is GPL often > requires additional code directly connected also has to be converted > to GPL too. So GPL eats up part by part all code of the system and > therefore makes it impossible to generate a commercial code. > > You might say that linux is used commercialy too and I agree as I do > this myself too. But it generates a lot of development to keep your > core knowledge and your own inventions apart from the GPL linux code. > But it is possible to do it as Linux offers enough standarized > connections for your software that you then keep secret. > > Nut/OS is a system optimized for extremely small controllers, hardly > or impossible to run (uc-)linux. So your application software can and > must connect more tight to the system to work fast and efficient. With > GPL applied you will be forced to open lots of your application code > to everyone. > > I hope you understand that this cannot be our intention. > > Best regards > Ulrich > > Am 10. Februar 2012 05:27 schrieb Henrik Maier : >> Hello Guillaume Fortaine, >> >> The libopencm3 is GPL and because of this not license compatible with Nut/OS >> and therefore cannot be used. I remember seeing discussions to change the >> license of libopencm3 to LGPL but this was rejected. >> >> See >> http://www.hermann-uwe.de/blog/libopenstm32-a-free-software-firmware-library-for-stm32-arm-cortex-m3-microcontrollers >> >> Best Regards >> >> Henrik Maier >> >> >> >> On 10/02/2012 12:58 PM, Guillaume Fortaine wrote: >>> >>> Dear Mister Bonnes, Mister Prinz, and Mister Maier >>> >>> First of all, I would like to wish you and the people around you an >>> happy new year. >>> >>> Let me introduce myself : Guillaume FORTAINE, Cloudpreneur : >>> >>> http://www.linkedin.com/in/gfortaine >>> >>> I have read with interest the discussion entitled "branches\devnut_m3n >>> and STM32F2 devices" [0]. Given that there is an Ethernet design >>> available around the STM32 F-2, >>> I would greatly appreciate to know if you plan to port the Ethernut >>> project to it, if possible, please ?: >>> >>> http://cgi.ebay.fr/ws/eBayISAPI.dll?ViewItem&item=190638488534 >>> >>> "ST Cortex M3 STM32F207 Development Board Ethernet USB Device/Host CAN" >>> >>> >>> By the way, to quote [0] : >>> >>> "What I thought I do for now is to create an new subdir under >>> branches\devnut_m3n\arch\cm3\dev called stm32f2 which temporarily >>> holds the drivers I ported across from the stm directory. Once that >>> becomes all stable and working I can work with the other STM32F1 >>> developers to maybe merge those files into one driver set suitable for >>> F1, F2 and maybe even F4 devices. I like to avoid as much code >>> duplication as possible." >>> >>> >>> Wouldn't it be better to leverage the libopencm3 project ? >>> >>> http://libopencm3.org/ >>> >>> "The libopencm3 project (previously known as libopenstm32) aims to >>> create a free/libre/open-source (GPL v3, or later) firmware library >>> for various ARM Cortex-M3 microcontrollers, including ST STM32, >>> Toshiba TX03, Atmel SAM3U, NXP LPC1000 and others." >>> >>> >>> I look forward to your answer, >>> >>> Best Regards, >>> >>> [0] >>> http://lists.egnite.de/pipermail/en-nut-discussion/2011-December/013183.html >>> >>> -- >>> Guillaume FORTAINE >>> guillaume.fortaine at devopspace.com >>> DevOpSpace >>> http://www.devopspace.com >>> +33(0)631.092.519 >>> >> From nategoose at gmail.com Tue Feb 14 05:08:04 2012 From: nategoose at gmail.com (Nathan Moore) Date: Mon, 13 Feb 2012 23:08:04 -0500 Subject: [En-Nut-Discussion] Fwd: Nut/OS BSD License (was Re: branches\devnut_m3n and STM32F2 devices) In-Reply-To: References: Message-ID: Nut/OS links against the applications that run under it, while Linux loads applications at runtime and those applications use an API that the Linux developers/copyright holders have expressly stated that using this API (as well as some source code which is really just the system call numbers) will not cause the rest of the application to be required to be GPL. This amounts to an amendment to the GPL license that Linux uses. From hmnews at proconx.com Tue Feb 14 05:25:59 2012 From: hmnews at proconx.com (Henrik Maier) Date: Tue, 14 Feb 2012 14:25:59 +1000 Subject: [En-Nut-Discussion] Fwd: Nut/OS BSD License (was Re: branches\devnut_m3n and STM32F2 devices) In-Reply-To: References: Message-ID: <4F39E257.7000405@proconx.com> Hello Guillaume, In reference to the article you are referring to, the situation for an embedded OS which is linked is very different to an OS like Linux. It is possible to use GPLed Linux with closed source applications. But if Nut/OS would be GPL, it would not be possible to keep your application code closed source which some users may prefer for commercial reasons. I believe the reason that Nut/OS has a BSD license contributes to the fact that we have a large commercial user base. Henrik On 14/02/2012 1:15 PM, Guillaume Fortaine wrote: > I would greatly appreciate to invite you to a further reading of the > article entitled "Opinion: License to FUD (comparing GPL and BSD)" : > > http://www.linuxfordevices.com/c/a/Linux-For-Devices-Articles/Opinion-License-to-FUD-comparing-GPL-and-BSD/ > From hmnews at proconx.com Tue Feb 14 05:30:38 2012 From: hmnews at proconx.com (Henrik Maier) Date: Tue, 14 Feb 2012 14:30:38 +1000 Subject: [En-Nut-Discussion] Possible race condition in DHCP and DHCPKick In-Reply-To: <1329069601.2501.16.camel@platon> References: <4F34ADA0.3070002@proconx.com> <1328977250.2984.17.camel@platon> <4F37A6EA.20003@googlemail.com> <1329069601.2501.16.camel@platon> Message-ID: <4F39E36E.7070502@proconx.com> I thought about a redesign myself, but commercial pressure to get a project out of the door prohibits this at the moment. So I will apply only those fixes at the moment and see if more issues pop up. On 13/02/2012 4:00 AM, Ole Reinhardt wrote: > Hi! > >> Isn't it more reliably to redesign dhcp into an active and a passive >> part. The active part can work with post/wait and simply offers a >> current_state variable like dhcpState. >> If DHCP_BOUND or DHCP_TOUT is reached it goes to sleep and wait for a >> restart-event. > > Good Idea! Please go ahead! (Or your college :) > > I just looked over the code without taking a redesign into account. As > the DHCP part made several problems in the past a redesign might be the > better choice. > > bye, > > Ole > From hmnews at proconx.com Tue Feb 14 06:25:16 2012 From: hmnews at proconx.com (Henrik Maier) Date: Tue, 14 Feb 2012 15:25:16 +1000 Subject: [En-Nut-Discussion] Fwd: Nut/Net (was Re: branches\devnut_m3n and STM32F2 devices) In-Reply-To: References: Message-ID: <4F39F03C.6010600@proconx.com> Hello Guillaume, Sorry I cannot supply a benchmark and my comments were not related to speed but to the richness and elegance of the Nut/OS and Nut/NET API. Nut/OS offers more high level TCP protocols and more network drivers than lwIP. The fact that Nut/NET is tied to Nut/OS is not a disadvantage. Nut/NET was never meant to run on another OS. OS and TCP/IP stack have become one coherent system which is easier to learn and use than plugging two separate things together. As a result sockets can be used in a stream-like fashion for example to do fprintf on a TCP socket. The lack of IP6 may be a drawback for some users, but it is not critical for me at this stage. If you require IP6 support now, than Nut/OS may be not be suitable indeed and lwIP may be the better choice for you. Regards Henrik On 14/02/2012 1:15 PM, Guillaume Fortaine wrote: > ---------- Forwarded message ---------- > From: Guillaume Fortaine > > Dear Mister Maier, > > Thank you for your comprehensive reply. > > >> I would suggest to shift this discussion into the Nut/Os mailing list rather >> continuing it as private mail. The topic raised by Guillaume should be >> discussed more broadly in the Nut/Os community. > > I am fine with this statement and I have just subscribed to the > "En-Nut-Discussion" mailing-list : > > http://lists.egnite.de/mailman/listinfo/en-nut-discussion > > >> Guillaume, you also mention ChibiOS in your mail. But we are talking about >> Nut/OS here, a very different OS which for example does not require lwIP and >> offers a far superior TCP/IP stack than lwIP. > > I would greatly appreciate that you develop your comment, if possible, please. > > Especially, could you provide any benchmark ? > > http://lists.gnu.org/archive/html/lwip-users/2011-11/msg00071.html > > "In fact, I have developed ftp server with lwIP, it works well enough ..and > support FlashFXP and FileZilla utility. > The download speed is 200KB/s and upload speed is 40KB/s in my Cortex M3 with > spi flash AT45DB321D." > > > By the way, from my point of view, Nut/Net has two main critical drawbacks : > > -No IPv6 support : > > http://www.ethernut.de/nutwiki/Nut/OS_Roadmap#IPv6 > > "I recently looked into Adam Dunkels' uIP again, which supports IPv6. To > me it doesn't look complicated. Quite the contrary, as it is limited to > single layer only and a few variables. As a first action, I'd suggest to > add it to the feature request list at SourceForge." > > > *lwIP supports IPv6 : > > http://git.savannah.gnu.org/cgit/lwip.git/tree/CHANGELOG > > "2011-05-17: Patch by Ivan Delamer (only checked in by Simon Goldschmidt) > * nearly the whole stack: Finally, we got decent IPv6 support, big thanks to > Ivan! (this is work in progress: we're just post release anyway :-)" > > > -Nut/Net is not easily portable : > > http://embedded-source.blogspot.com/2010/01/nutos.html > > "Nut/Net is designed for Nut/OS and not easy to port to other OS > because it uses many Nut/OS specific calls." > > *lwIP has been ported to many RTOS : > > http://lwip.wikia.com/wiki/Projects_that_use_lwIP > > > -FreeRTOS : http://www.freertos.org/portsam7xlwIP.html > > "lwIP Embedded Web Server Demo" > > > -RT-Thread : http://code.google.com/p/rt-thread/wiki/Lwip_140_MigrationGuide > > "lwip1.4 Migration Guide" > > > -ChibiOS/RT : http://www.chibios.org/dokuwiki/doku.php > > "Support for external components uIP, lwIP, FatFs." > > > -tmos : http://code.google.com/p/tmos/source/browse/trunk/tmos/services/#services%2Flwip-1.4.0.rc1 > > "lwip-1.4.0.rc1" > > > I look forward to your answer, > > Best Regards, > > -- > Guillaume FORTAINE > guillaume.fortaine at devopspace.com > DevOpSpace > http://www.devopspace.com > +33(0)631.092.519 > > > On Sat, Feb 11, 2012 at 12:42 AM, Henrik Maier wrote: >> Hi all, >> >> I would suggest to shift this discussion into the Nut/Os mailing list rather >> continuing it as private mail. The topic raised by Guillaume should be >> discussed more broadly in the Nut/Os community. >> >> So please post questions and replies to the NutOS mailing list: >> >> en-nut-discussion at egnite.de >> >> Guillaume, you also mention ChibiOS in your mail. But we are talking about >> Nut/OS here, a very different OS which for example does not require lwIP and >> offers a far superior TCP/IP stack than lwIP. >> >> Regards >> >> Henrik Maier >> >> >> On 11/02/2012 12:29 AM, Guillaume Fortaine wrote: >>> >>> Dear Mister Prinz, >>> >>> Thank you for your comprehensive reply. >>> >>> >>>> I hope you understand that this cannot be our intention. >>> >>> >>> I am fine with this statement. So do you plan to leverage the CMSIS >>> RTOS API instead ? >>> >>> http://forum.chibios.org/phpbb/viewtopic.php?f=3&t=272 >>> >>> "Starting from version 3.0, CMSIS will define a specific RTOS API, the >>> preview is already available here: >>> >>> http://www.onarm.com/cmsis/download/19/version-3-0-preview-of-the-cortex-microcontroller-software-interface-standard-cmsis/ >>> >>> This API will allow to design RTOS-independent components. My idea is >>> to focus the kernel development after version 2.4.0 on providing a >>> compliant API, the new API would wrap/supplement the normal ChibiOS >>> API not replace it, I still think it is particularly efficient and >>> elegant. >>> >>> This development is interesting because it will possible to design >>> complex components (file systems, networking stacks) without have to >>> use a vendor specific interface. For example a stack like lwIP could >>> simply assume that API instead of defining its own RTOS wrapper." >>> >>> >>> I look forward to your answer, >>> >>> Best Regards, >>> >>> -- >>> Guillaume FORTAINE >>> guillaume.fortaine at devopspace.com >>> DevOpSpace >>> http://www.devopspace.com >>> +33(0)631.092.519 >>> >>> >>> On Fri, Feb 10, 2012 at 2:37 PM, Ulrich Prinz >>> wrote: >>>> >>>> Hello Guillaume, >>>> >>>> >>>> I need to agree with Uwe Bonnes statement. The whole team put a lot of >>>> energy to get STM32 and later other CortexM based CPUs working in a >>>> system that can be used free for any hobby and commercial development. >>>> The work we did can only be done cause we can use the results >>>> commecially. Unfortunately GPL license is (as Texas Instrument calles >>>> it) a virulent license. That means that adding code that is GPL often >>>> requires additional code directly connected also has to be converted >>>> to GPL too. So GPL eats up part by part all code of the system and >>>> therefore makes it impossible to generate a commercial code. >>>> >>>> You might say that linux is used commercialy too and I agree as I do >>>> this myself too. But it generates a lot of development to keep your >>>> core knowledge and your own inventions apart from the GPL linux code. >>>> But it is possible to do it as Linux offers enough standarized >>>> connections for your software that you then keep secret. >>>> >>>> Nut/OS is a system optimized for extremely small controllers, hardly >>>> or impossible to run (uc-)linux. So your application software can and >>>> must connect more tight to the system to work fast and efficient. With >>>> GPL applied you will be forced to open lots of your application code >>>> to everyone. >>>> >>>> I hope you understand that this cannot be our intention. >>>> >>>> Best regards >>>> Ulrich >>>> >>>> Am 10. Februar 2012 05:27 schrieb Henrik Maier: >>>>> >>>>> Hello Guillaume Fortaine, >>>>> >>>>> The libopencm3 is GPL and because of this not license compatible with >>>>> Nut/OS >>>>> and therefore cannot be used. I remember seeing discussions to change >>>>> the >>>>> license of libopencm3 to LGPL but this was rejected. >>>>> >>>>> See >>>>> >>>>> http://www.hermann-uwe.de/blog/libopenstm32-a-free-software-firmware-library-for-stm32-arm-cortex-m3-microcontrollers >>>>> >>>>> Best Regards >>>>> >>>>> Henrik Maier >>>>> >>>>> >>>>> >>>>> On 10/02/2012 12:58 PM, Guillaume Fortaine wrote: >>>>>> >>>>>> >>>>>> Dear Mister Bonnes, Mister Prinz, and Mister Maier >>>>>> >>>>>> First of all, I would like to wish you and the people around you an >>>>>> happy new year. >>>>>> >>>>>> Let me introduce myself : Guillaume FORTAINE, Cloudpreneur : >>>>>> >>>>>> http://www.linkedin.com/in/gfortaine >>>>>> >>>>>> I have read with interest the discussion entitled "branches\devnut_m3n >>>>>> and STM32F2 devices" [0]. Given that there is an Ethernet design >>>>>> available around the STM32 F-2, >>>>>> I would greatly appreciate to know if you plan to port the Ethernut >>>>>> project to it, if possible, please : >>>>>> >>>>>> http://cgi.ebay.fr/ws/eBayISAPI.dll?ViewItem&item=190638488534 >>>>>> >>>>>> "ST Cortex M3 STM32F207 Development Board Ethernet USB Device/Host CAN" >>>>>> >>>>>> >>>>>> By the way, to quote [0] : >>>>>> >>>>>> "What I thought I do for now is to create an new subdir under >>>>>> branches\devnut_m3n\arch\cm3\dev called stm32f2 which temporarily >>>>>> holds the drivers I ported across from the stm directory. Once that >>>>>> becomes all stable and working I can work with the other STM32F1 >>>>>> developers to maybe merge those files into one driver set suitable for >>>>>> F1, F2 and maybe even F4 devices. I like to avoid as much code >>>>>> duplication as possible." >>>>>> >>>>>> >>>>>> Wouldn't it be better to leverage the libopencm3 project ? >>>>>> >>>>>> http://libopencm3.org/ >>>>>> >>>>>> "The libopencm3 project (previously known as libopenstm32) aims to >>>>>> create a free/libre/open-source (GPL v3, or later) firmware library >>>>>> for various ARM Cortex-M3 microcontrollers, including ST STM32, >>>>>> Toshiba TX03, Atmel SAM3U, NXP LPC1000 and others." >>>>>> >>>>>> >>>>>> I look forward to your answer, >>>>>> >>>>>> Best Regards, >>>>>> >>>>>> [0] >>>>>> >>>>>> http://lists.egnite.de/pipermail/en-nut-discussion/2011-December/013183.html >>>>>> >>>>>> -- >>>>>> Guillaume FORTAINE >>>>>> guillaume.fortaine at devopspace.com >>>>>> DevOpSpace >>>>>> http://www.devopspace.com >>>>>> +33(0)631.092.519 >>>>>> >>>>> >>> >> > _______________________________________________ > http://lists.egnite.de/mailman/listinfo/en-nut-discussion > From thiago.correa at gmail.com Tue Feb 14 15:52:41 2012 From: thiago.correa at gmail.com (=?ISO-8859-1?Q?Thiago_A=2E_Corr=EAa?=) Date: Tue, 14 Feb 2012 12:52:41 -0200 Subject: [En-Nut-Discussion] Atmega 2561with more than 128k code and Winavr In-Reply-To: <20281.36759.32008.174174@elektron.ikp.physik.tu-darmstadt.de> References: <4F397095.3020708@gmx.de> <20281.36759.32008.174174@elektron.ikp.physik.tu-darmstadt.de> Message-ID: Hi, On Mon, Feb 13, 2012 at 8:32 PM, Uwe Bonnes wrote: > > I think, gcc has problems with AVR and CODE bigger than 128 k. > There was a very ancient bug report in gcc's bugzilla that was open for several months about that, can't say if it was fixed or if it remains open. I thought I had a link in one of our own bug reports but I couldn't find it. Sorry can't offer more help, but I would check out latest AVR Studio (comes with compiler now) and try to build against that compiler. Maybe it got fixed. Kind Regards, Thiago A. Correa From guillaume.fortaine at devopspace.com Tue Feb 14 23:08:02 2012 From: guillaume.fortaine at devopspace.com (Guillaume Fortaine) Date: Tue, 14 Feb 2012 23:08:02 +0100 Subject: [En-Nut-Discussion] Fwd: Fwd: Nut/OS BSD License (was Re: branches\devnut_m3n and STM32F2 devices) In-Reply-To: <4F3AD354.2080108@ngi.it> References: <4F39E257.7000405@proconx.com> <4F3AD354.2080108@ngi.it> Message-ID: ---------- Forwarded message ---------- From: G.Di Sirio Date: Tue, Feb 14, 2012 at 10:34 PM Subject: Re: [En-Nut-Discussion] Fwd: Nut/OS BSD License (was Re: branches\devnut_m3n and STM32F2 devices) Hi Guillame, Interesting indeed, I agree that Linux and ChibiOS/Nut-OS/others-similar have different licensing issues. This is something that troubled me a lot when I decided to turn ChibiOS into an open source project. It is true that a BSD or similar license would offer the greatest freedom for users but that would mean for me to automatically surrender any right on the code. I also felt that releasing something, basically for free, under a BSD license could devalue it somehow. It is free, it can't be really good, right? It is also true that a GPL license makes a "linkable" OS unusable for commercial applications so I decided to offer it under GPL3 with a linking exception AND alternatively under a GPL-free proprietary license. Hobbyists, students and small commercial users don't have problems with GPL+exception, big corporate users usually don't want to be bound even by a watered down GPL. IMO GPL is actually an advantage if you want a project to remain truly open AND also try to be profitable. So far this GPL+exception solution proved to work pretty well, the project is growing nicely. ciao, Giovanni Il 14/02/2012 19.57, Guillaume Fortaine ha scritto: > Hello, > > This is an interesting debate. What do you think of it ? > > I look forward to your answer, > > Best Regards, > > Guillaume FORTAINE > > > On Tue, Feb 14, 2012 at 5:25 AM, Henrik Maier ?wrote: >> >> Hello Guillaume, >> >> In reference to the article you are referring to, the situation for an >> embedded OS which is linked is very different to an OS like Linux. It is >> possible to use GPLed Linux with closed source applications. But if >> Nut/OS would be GPL, it would not be possible to keep your application >> code closed source which some users may prefer for commercial reasons. >> >> I believe the reason that Nut/OS has a BSD license contributes to the >> fact that we have a large commercial user base. >> >> Henrik >> >> On 14/02/2012 1:15 PM, Guillaume Fortaine wrote: >>> >>> I would greatly appreciate to invite you to a further reading of the >>> article entitled "Opinion: License to FUD (comparing GPL and BSD)" : >>> >>> http://www.linuxfordevices.com/c/a/Linux-For-Devices-Articles/Opinion-License-to-FUD-comparing-GPL-and-BSD/ >>> >> _______________________________________________ >> http://lists.egnite.de/mailman/listinfo/en-nut-discussion From hmnews at proconx.com Wed Feb 15 10:43:31 2012 From: hmnews at proconx.com (Henrik Maier) Date: Wed, 15 Feb 2012 19:43:31 +1000 Subject: [En-Nut-Discussion] Fwd: Fwd: Nut/OS BSD License (was Re: branches\devnut_m3n and STM32F2 devices) In-Reply-To: References: <4F39E257.7000405@proconx.com> <4F3AD354.2080108@ngi.it> Message-ID: <4F3B7E43.1070508@proconx.com> Hello Guillaume, The original question from you to some of the Cortex M3 branch developers was why we don't use libopencm3 and we explained the drawbacks of a GPL license. Even a GPL Expeption license instead of a BSD license for the OS (as preferred by Giovanni from ChibiOS) would be incompatible with a pure GPL license, which means if you integrate as you suggested libopencm3 into your project, you have to disclose the complete source including your application as the GPL Exception license applies only to the OS but not to other GPLed code like libopencm3. Regards Henrik On 15/02/2012 8:08 AM, Guillaume Fortaine wrote: > ---------- Forwarded message ---------- > From: G.Di Sirio > Date: Tue, Feb 14, 2012 at 10:34 PM > Subject: Re: [En-Nut-Discussion] Fwd: Nut/OS BSD License (was Re: > branches\devnut_m3n and STM32F2 devices) > > > Hi Guillame, > > Interesting indeed, I agree that Linux and > ChibiOS/Nut-OS/others-similar have different licensing issues. > > This is something that troubled me a lot when I decided to turn > ChibiOS into an open source project. It is true that a BSD or similar > license would offer the greatest freedom for users but that would mean > for me to automatically surrender any right on the code. I also felt > that releasing something, basically for free, under a BSD license > could devalue it somehow. It is free, it can't be really good, right? > > It is also true that a GPL license makes a "linkable" OS unusable for > commercial applications so I decided to offer it under GPL3 with a > linking exception AND alternatively under a GPL-free proprietary > license. > > Hobbyists, students and small commercial users don't have problems > with GPL+exception, big corporate users usually don't want to be bound > even by a watered down GPL. IMO GPL is actually an advantage if you > want a project to remain truly open AND also try to be profitable. > > So far this GPL+exception solution proved to work pretty well, the > project is growing nicely. > > ciao, > Giovanni > > Il 14/02/2012 19.57, Guillaume Fortaine ha scritto: > >> Hello, >> >> This is an interesting debate. What do you think of it ? >> >> I look forward to your answer, >> >> Best Regards, >> >> Guillaume FORTAINE >> >> >> On Tue, Feb 14, 2012 at 5:25 AM, Henrik Maier wrote: >>> >>> Hello Guillaume, >>> >>> In reference to the article you are referring to, the situation for an >>> embedded OS which is linked is very different to an OS like Linux. It is >>> possible to use GPLed Linux with closed source applications. But if >>> Nut/OS would be GPL, it would not be possible to keep your application >>> code closed source which some users may prefer for commercial reasons. >>> >>> I believe the reason that Nut/OS has a BSD license contributes to the >>> fact that we have a large commercial user base. >>> >>> Henrik >>> >>> On 14/02/2012 1:15 PM, Guillaume Fortaine wrote: >>>> >>>> I would greatly appreciate to invite you to a further reading of the >>>> article entitled "Opinion: License to FUD (comparing GPL and BSD)" : >>>> >>>> http://www.linuxfordevices.com/c/a/Linux-For-Devices-Articles/Opinion-License-to-FUD-comparing-GPL-and-BSD/ >>>> >>> _______________________________________________ >>> http://lists.egnite.de/mailman/listinfo/en-nut-discussion > _______________________________________________ > http://lists.egnite.de/mailman/listinfo/en-nut-discussion > From ulrich.prinz at googlemail.com Wed Feb 15 10:51:51 2012 From: ulrich.prinz at googlemail.com (Ulrich Prinz) Date: Wed, 15 Feb 2012 10:51:51 +0100 Subject: [En-Nut-Discussion] Anybody on Embedded World 2012? In-Reply-To: <4F37FD03.7080309@googlemail.com> References: <1328174237.2086.12.camel@platon> <4F37FD03.7080309@googlemail.com> Message-ID: So what day do we take 28 or 29? Ulrich Am 12. Februar 2012 18:55 schrieb Ulrich Prinz : > Hi! > > Some of my colleagues and I plan to go there, but a date has not been > fixed. CeBit is right after that and we need to be prepared to show up > there shortly on request. > > So I will write a date when the car is ordered :) > > Ulrich > > Am 02.02.2012 10:17, schrieb Ole Reinhardt: >> Hi all, >> >> just to be the first, I'm curious if anybody (beside of Egnite :-) will >> be on the Embedded World this year. >> >> Perhaps we could meet again? >> >> Right now I plan to be there at 28.02 or 29.02.2012 >> >> Bye, >> >> Ole >> From joerg.wiegelmann at gmx.de Wed Feb 15 13:37:01 2012 From: joerg.wiegelmann at gmx.de (Joerg Wiegelmann) Date: Wed, 15 Feb 2012 13:37:01 +0100 Subject: [En-Nut-Discussion] Atmega 2561with more than 128k code and Winavr In-Reply-To: References: <4F397095.3020708@gmx.de> <20281.36759.32008.174174@elektron.ikp.physik.tu-darmstadt.de> Message-ID: <4F3BA6ED.5010503@gmx.de> Hi Thiago, thank you for your help. I do as you recommended and I got new errors: D:/nut/nutbld/lib\libnutcrt.a(fputs_p.o): In function `fputs_P': fputs_p.c:(.text+0xc): undefined reference to `__strlen_P' and the old errors again.... D:/nut/nutbld/lib\libnutcrt.a(vfprintf.o): In function `vfprintf': vfprintf.c:(.text+0xa): warning: internal error: out of range error vfprintf.c:(.text+0xc): warning: internal error: out of range error I'm really disappointed now and I'm thinking about a change to another hardware platform. Perhaps EIR or Arm with C# or so..... My intention was to maintain my home-automation-project over the years. But with a code size more than 128k it isn't possible any more to deal with Atmel. Thank you all for your help, any idea is welcome Joerg Am 14.02.2012 15:52, schrieb Thiago A. Corr?a ......, but I would check out latest AVR Studio (comes with compiler now) and try to build against that compiler. Maybe it got fixed. From c.bonnemayer at maastrichtuniversity.nl Wed Feb 15 16:19:05 2012 From: c.bonnemayer at maastrichtuniversity.nl (Bonnemayer C (PSYCHOLOGY)) Date: Wed, 15 Feb 2012 16:19:05 +0100 Subject: [En-Nut-Discussion] stammering audio playback on EIR/VS1053B Message-ID: Dear all, Being a starter with Nut/OS I tried some NutWiki examples to gain some knowledge about this OS. As a Nut/OS newbee I hope you can forgive me for possible stupid questions. With a slightly modified version of the NutWiki MMC MP3 player I tried to play .ogg and .flac files (the latter with the VS1053B patch v1.95) on my EIR board. It appears that when using high quality files (with low compression and/or high bitrates) the output is interrupted during playback. I.e. the file plays for a second or so, waits for half a second, and then continues where it has left, this happens intermittentally. I tried several audio formats and to me it seems that high bitrate files (mp3 > 192 kbps, ogg > 44.1KHz, 147kbps) have more problems than low bitrate files. I played around with some settings, but changing VSCODEC0_OUTPUT_BUFSIZ in audio.h doesn't help. Also, changing VSCODEC0_SPI_RATE has no effect. it looks like that the problem lies in the fact that the VS1053 codec shares the SPI bus with the MMC interface, so there's a lot of data trafic on this bus. Unfortunately I don't have a logic analyzer, so I can't verify this. Does anybody has any suggestions for further troubleshooting? Best regards, Charles Bonnemayer Hardware: EIR board with VS1053 audio codec software: Nut/OS 4.10.1, Yagarto with GCC-4.6.2 Win OS: Windows XP SP3 From bon at elektron.ikp.physik.tu-darmstadt.de Wed Feb 15 17:53:18 2012 From: bon at elektron.ikp.physik.tu-darmstadt.de (Uwe Bonnes) Date: Wed, 15 Feb 2012 17:53:18 +0100 Subject: [En-Nut-Discussion] Anybody on Embedded World 2012? In-Reply-To: References: <1328174237.2086.12.camel@platon> <4F37FD03.7080309@googlemail.com> Message-ID: <20283.58110.884872.85050@elektron.ikp.physik.tu-darmstadt.de> >>>>> "Ulrich" == Ulrich Prinz writes: Ulrich> So what day do we take 28 or 29? Ulrich I am planning for the 28. Probably however I will drive home by car with other people or train home at about 18.00. Bye -- Uwe Bonnes bon at elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- From harald.kipp at egnite.de Wed Feb 15 18:33:04 2012 From: harald.kipp at egnite.de (Harald Kipp) Date: Wed, 15 Feb 2012 18:33:04 +0100 Subject: [En-Nut-Discussion] stammering audio playback on EIR/VS1053B In-Reply-To: References: Message-ID: <4F3BEC50.3030109@egnite.de> Hi Charles, On 15.02.2012 16:19, Bonnemayer C (PSYCHOLOGY) wrote: > With a slightly modified version of the NutWiki MMC MP3 player I tried to play .ogg and .flac files (the latter with the VS1053B patch v1.95) on my EIR board. It appears that when using high quality files (with low compression and/or high bitrates) the output is interrupted during playback. I.e. the file plays for a second or so, waits for half a second, and then continues where it has left, this happens intermittentally. I tried several audio formats and to me it seems that high bitrate files (mp3 > 192 kbps, ogg > 44.1KHz, 147kbps) have more problems than low bitrate files. > I played around with some settings, but changing VSCODEC0_OUTPUT_BUFSIZ in audio.h doesn't help. Also, changing VSCODEC0_SPI_RATE has no effect. > > it looks like that the problem lies in the fact that the VS1053 codec shares the SPI bus with the MMC interface, so there's a lot of data trafic on this bus. Unfortunately I don't have a logic analyzer, so I can't verify this. When designing the EIR, I intentionally did not share the SPI bus between MMC and the codec. Instead, I connected the MMC to the SSC in the hope, that one day I may be able to mimic SPI with the SSC interface. A first attempt failed, so I decided to use software SPI (bit-banging) as a temporary solution. However, when trying to play audio files from MMC, I experienced the same problems that you described. The good news is, that I finally managed to make SPI working on the SSC hardware, even with DMA (Atmel term: PDC). The bad new is, that a minor hardware change is required. You must connect PA16(TK) Port A connector pin 17 with PA19(RK) Port A connector pin 20 The problem with SSC is, that you cannot stop the receiver. But you can stop the transmitter, so my idea was to feed the receiver clock from the transmitter clock. I created a new SPI buts driver based on SSC and... it works! :-) The bad news is, that we are, in general, not allowed to add new features to a stable version. Therefore this new driver is only available in the current beta 5.0. However, I'm almost sure, that the driver will work with version 4.10 too. If you do not want to modify the configuration scripts (which may not be trivial, because the directory structure was modified), then you can simply place the driver's code in your local app directory and add it to the app's Makefile. You can find the code here http://ethernut.svn.sourceforge.net/viewvc/ethernut/trunk/nut/arch/arm/dev/atmel/ Look out for spibus*at91ssc.c. There's also an include file required #include or, if locally used #include "spibus_ssc.h" If you are considering to upgrade to Nut/OS 5.0 (looks quite stable to me), then you may wait a bit. I'm currently building a new beta release. Here's the code to use this new driver: printf("Register memory card device..."); if (NutRegisterSpiDevice(&devSpiMmcGpio, &spiBus0Ssc, 0)) { puts("failed"); } else { puts("OK"); } printf("Register file system..."); if (NutRegisterDevice(&devPhat0, 0, 0)) { puts("failed"); } else { puts("OK"); } printf("Mounting memory card..."); volid = _open(DEV_MMCARD_NAME ":1/PHAT0", _O_RDWR | _O_BINARY); if (volid == -1) { printf("Error %d\n", errno); for (;;); } puts("OK"); So far I had no time to test its real performance, but playing and recording on MMC worked. I remember having had problems with recording 192kbps streams, probably because of MMC latencies. This may be solved by using larger buffers. I'm also aware, that the PHAT filesystem layer is somewhat slow. Best regards, Harald From harald.kipp at egnite.de Wed Feb 15 19:25:40 2012 From: harald.kipp at egnite.de (Harald Kipp) Date: Wed, 15 Feb 2012 19:25:40 +0100 Subject: [En-Nut-Discussion] Ethernut 5 + Eclipse tutorial In-Reply-To: References: <70E051BE-4CD4-48C1-81D3-8AEC4A889653@dr-clauss.de> <4F364D09.9020602@egnite.de> Message-ID: <4F3BF8A4.9020800@egnite.de> Just for the records: >>> But when I want to build the project, Eclipse puts out "Cannot run >>> program "make" ". I have no idea, what I've made wrong. The path- >>> variable for yargarto is set correctly. Markus found the problem: The C/C++ Plugin wasn't properly installed. Regards, Harald From harald.kipp at egnite.de Wed Feb 15 19:54:52 2012 From: harald.kipp at egnite.de (Harald Kipp) Date: Wed, 15 Feb 2012 19:54:52 +0100 Subject: [En-Nut-Discussion] xgSMTPC Bugs In-Reply-To: <4F035707.7090805@egnite.de> References: <000001ccc717$2dd94250$898bc6f0$@s.profanter.me> <4F035707.7090805@egnite.de> Message-ID: <4F3BFF7C.40502@egnite.de> > On 30.12.2011 18:19, Stefan Profanter wrote: >> You can rewiew the code changes here and maybe add it to the SVN-Repo: >> >> https://codereview.appspot.com/5505086/ Applied to trunk and branch 4.10. Thanks again, Harald From thiago.correa at gmail.com Wed Feb 15 20:38:12 2012 From: thiago.correa at gmail.com (=?ISO-8859-1?Q?Thiago_A=2E_Corr=EAa?=) Date: Wed, 15 Feb 2012 17:38:12 -0200 Subject: [En-Nut-Discussion] Feature Request: Create Application Directory" for (q)nutconf In-Reply-To: <4F37A2F1.1060302@googlemail.com> References: <1328712760.2167.51.camel@platon> <4F37A2F1.1060302@googlemail.com> Message-ID: Hi, I have been wondering for a while how we could have a "New Project with Nut/OS" kind of wizard, like visual studio, into qnutconf and how it would build you the basic makefiles. It's interesting to know how ppl actually use Nut/OS in their environment. In particular, I keep my nuts/os in c:\programming\ethernut and my projects as c:\programming\comm5\firmware\ Inside I create a makefile that references the sample makefiles like this: include /programming/ethernut/nutapp/Makedefs SRCS = mysource.c LIBS = $(LIBDIR)/nutinit.o -lnutos -lnutarch -lnutdev -lnutcrt -lnutc -lnutgorp OBJS = $(SRCS:.c=.o) TARG = $(PROJ).hex all: $(OBJS) $(TARG) $(ITARG) $(DTARG) dep: $(CC) -I$(top_srcdir)/include -M main.c include /programming/ethernut/nutapp/Makerules It's simple and shouldn't be hard to generate, yet I don't think it's simple enough for the beginner. I'm interested in opinions. Kind Regards, Thiago A. Correa On Sun, Feb 12, 2012 at 9:30 AM, Ulrich Prinz wrote: > Hi! > > At first the separation of directory and makefile generation from > creation of all examples would be very helpfull. > > To add an option that enables to export all libraries and headers and > creates a set of working application makefiles is very fine. > We often need to keep nut/os libraries synced with the application > source code to be able to reproduce avery single software release. > > So if we could export the libraries and headers in parallel with the > applications it would be very handy for checking them in to SVN or > GIT. > > Ulrich > > > Am 08.02.2012 15:52, schrieb Ole Reinhardt: >> Hi Ulrich, >> >>> But if you develop lots of your own projects you might not like to >>> have all the examples installed. >> >> Yes, I well know this problem. I personally prefer to have a >> pre-compiled Nut/OS and to use just a few simple makefiles with my >> application, not all this directory hirarchy. >> >> Especialy when deploying Nut/OS as development environment for a board >> your customers won't ever compile Nut/OS by their own but just use the >> ready build libraries. >> >> So what I would suggest is to add an "Install Nut/OS" which would build >> the libraries, install it into a folder and add the necessary makefiles >> (just the ones for your compiler setting) >> >> As an example see >> >> http://www.embedded-it.de/bsp-download/webserver_relais_demo.tar.gz >> >> (folder Nut/OS) >> >> I also modified the application standard makefiles to refer to the >> pre-installed ones. >> >> Another idea: >> >> This install button could also copy the header files so that one would >> not have to install the whole source tree too. >> >> Bye, >> >> Ole >> >> > _______________________________________________ > http://lists.egnite.de/mailman/listinfo/en-nut-discussion From klaus.kloos at gmx.de Thu Feb 16 07:58:59 2012 From: klaus.kloos at gmx.de (Klaus Kloos) Date: Thu, 16 Feb 2012 07:58:59 +0100 Subject: [En-Nut-Discussion] Strange newlib syscall dependencies / linker problems when using 64bit integers In-Reply-To: <20274.26791.136327.58886@elektron.ikp.physik.tu-darmstadt.de> References: <1328566767.2181.11.camel@platon> <20273.21491.975139.994432@elektron.ikp.physik.tu-darmstadt.de> <1328703310.2167.5.camel@platon> <20274.26791.136327.58886@elektron.ikp.physik.tu-darmstadt.de> Message-ID: <23491BEC-072A-446D-92B5-760C27D7CBF8@gmx.de> Hello Some days ago there have been problems with linking using 64bit integers and im not shure if a solution was found. I stumbled over the same problem and found the following solution for me (Ethernut 4.10, yagarto). the following: --- /* .ARM.exidx is sorted, so has to go in its own output section. kl for using long long*/ .ARM.exidx : { __exidx_start = .; *(.ARM.exidx* .gnu.linkonce.armexidx.*) __exidx_end = .; } >rom --- was added to my .ld file right after the .text segment Somewhere i had to create the empty functions: --- void _sbrk(void){ } void _getpid(void){ } void _kill(void){ } void _exit(int status){ while(1){;} } --- But dont ask me why ..... This was all. It wasnt necessary for me to remove the -fno-exceptions -fno-rtti flags like some other descriptions are telling. Now the int64 are working, i have only little doubts in what situations the _exit functions is called and freezes my prg. Greetings Klaus From klaus.kloos at gmx.de Thu Feb 16 08:22:36 2012 From: klaus.kloos at gmx.de (Klaus Kloos) Date: Thu, 16 Feb 2012 08:22:36 +0100 Subject: [En-Nut-Discussion] SPI in IRQ Message-ID: <67F1A9B8-D367-4DB9-8EED-0519FE1687C0@gmx.de> Hello I have to work with an 24bit ADC AD7767 with 32kSPS. The values can be read between two finished conversions from the device using SPI. There are ca. 30us left for this when using the 32kSPS. My first though was to get the 'value ready' signal by IRQ, inform a thread by NutEventPostFromIrq() and get the value by SPI in a separate thread. But that is much to slow. Im not able to guaranty a context switch in this short time. The second approach was to get the SPI-value in the IRQ by bitbanging. This is a little to slow and very ugly. I will have to code this part in assembler..... So I tried to use the NutOS functions. (*spiBus1At91.bus_alloc) and (*spiBus1At91.bus_release) are called outside the IRQ, (*spiBus1At91.bus_transfer) is called at IRQ time. The transfer of the 3 bytes last ca. 12us using 10MHz SPI. It is working, but unreliable. Sometimes my device freezes. Im almost sure that the SPI-functions are not designed to be used like this. What are my possibilities? Is there a recommended way to solve such time-critical SPI-requests? Can I get the Nut/OS functions IRQ save somehow? Thanks in advance for any hint. Greetings Klaus Ingenieurb?ro Kloos Soft+Hardware Entwicklung Haus Heyden Strasse 111 52134 Herzogenrath Tel.: 02407/918376 Handy.: 0176/20925123 From harald.kipp at egnite.de Thu Feb 16 10:29:34 2012 From: harald.kipp at egnite.de (Harald Kipp) Date: Thu, 16 Feb 2012 10:29:34 +0100 Subject: [En-Nut-Discussion] SPI in IRQ In-Reply-To: <67F1A9B8-D367-4DB9-8EED-0519FE1687C0@gmx.de> References: <67F1A9B8-D367-4DB9-8EED-0519FE1687C0@gmx.de> Message-ID: <4F3CCC7E.5090804@egnite.de> Hi Klaus, On 16.02.2012 08:22, Klaus Kloos wrote: > So I tried to use the NutOS functions. (*spiBus1At91.bus_alloc) and (*spiBus1At91.bus_release) are called outside the IRQ, (*spiBus1At91.bus_transfer) is called at IRQ time. > The transfer of the 3 bytes last ca. 12us using 10MHz SPI. It is working, but unreliable. Sometimes my device freezes. Probably. In general, it is not allowed to call API functions in interrupt context, except NutEventPostFromIrq(). As a special exception it is possible to use stdio functions on a polling device, usually devDebug. > What are my possibilities? Is there a recommended way to solve such time-critical SPI-requests? > Can I get the Nut/OS functions IRQ save somehow? Nut/OS allows to use native interrupt handlers. For the AT91 you can use static void MySpiIrqHandler(void) __attribute__ ((naked)); void MySpiIrqHandler(void) { IRQ_ENTRY(); ...your code here... IRQ_EXIT(); } In your main code you need to write the address of the handler into the related AIC service routine register. outr(AIC_SVR(SPI0_ID), (unsigned int) MySpiIrqHandler); And...not to forget...it is always a good idea to check the datasheet. ;-) Regards, Harald From info at pragmalab.nl Thu Feb 16 10:54:49 2012 From: info at pragmalab.nl (PragmaLab (Rob van Lieshout)) Date: Thu, 16 Feb 2012 10:54:49 +0100 Subject: [En-Nut-Discussion] 2561with more than 128k code and Winavr In-Reply-To: References: Message-ID: <001c01ccec91$056a7e20$103f7a60$@nl> Hi Joerg >I'm really disappointed now and I'm thinking about a change to another >hardware platform. Perhaps EIR or Arm with C# or so..... >My intention was to maintain my home-automation-project over the years. >But with a code size more than 128k it isn't possible any more to deal >with Atmel. Codesize > 128K for the ATMega256 and WinAVR shouldn't be a problem at all. First WinAVR version that dealt correctly with the 128k boundary was 20070525. We still use that one for our (commercial) product (almost 256K used now). Not sure what the problem can be exactly, but if you wish I could send you my makefile. WinAVR 20100110 can be used as well. At the time (must be more then 4 years now), we had lots of problems when we ported our code to the Mega256, but one by one the problems were solved. Regards, Rob From klaus.kloos at gmx.de Thu Feb 16 12:04:28 2012 From: klaus.kloos at gmx.de (Klaus Kloos) Date: Thu, 16 Feb 2012 12:04:28 +0100 Subject: [En-Nut-Discussion] SPI in IRQ In-Reply-To: <4F3CCC7E.5090804@egnite.de> References: <67F1A9B8-D367-4DB9-8EED-0519FE1687C0@gmx.de> <4F3CCC7E.5090804@egnite.de> Message-ID: <5021F9A0-B4B6-479A-8589-9364E7DDD0AA@gmx.de> Hello Harald Thanks for your fast answer. > On 16.02.2012 08:22, Klaus Kloos wrote: >> So I tried to use the NutOS functions. (*spiBus1At91.bus_alloc) and (*spiBus1At91.bus_release) are called outside the IRQ, (*spiBus1At91.bus_transfer) is called at IRQ time. >> The transfer of the 3 bytes last ca. 12us using 10MHz SPI. It is working, but unreliable. Sometimes my device freezes. > > Probably. In general, it is not allowed to call API functions in > interrupt context, except NutEventPostFromIrq(). As a special exception > it is possible to use stdio functions on a polling device, usually devDebug. > ok, i was aware that this is not the right way. It was only a test and it gave me a 'near to working' result :-) My hope was to get bus-transfer() IRQ save somehow...... What is necessary to make a function IRQ save? >> What are my possibilities? Is there a recommended way to solve such time-critical SPI-requests? >> Can I get the Nut/OS functions IRQ save somehow? > > Nut/OS allows to use native interrupt handlers. For the AT91 you can use > > static void MySpiIrqHandler(void) __attribute__ ((naked)); > void MySpiIrqHandler(void) > { > IRQ_ENTRY(); > ...your code here... > IRQ_EXIT(); > } > > In your main code you need to write the address of the handler into the > related AIC service routine register. > > outr(AIC_SVR(SPI0_ID), (unsigned int) MySpiIrqHandler); > Interesting, this might give me back the 1us which I loose between an IRQ and the calling of my IRQ-routine using the NutOS way. But that's not the main problem. How do I get the SPI-Value in my 30us slot? I see these ways: Is there a way to generate a fast context-switch from IRQ to the thread which is allowed to call bus_transfer()? Can this be done reliable in ca. 10us? Then I can use the NutOS SPI routines. An other way is the read the data in the IRQ. But then I have to code a function like bus_transfer() by myself (?). Not a nice chance... A simple solution would be working without an IRQ and do everything in a thread without allowing a context-switch. So the sam7 will freeze for up to 50ms (i have to read 1000 values). > And...not to forget...it is always a good idea to check the datasheet. ;-) > Not that I have completely memorized it, but Ive read it several times. The problem seems clear. Im too slow. There is also a 128kSPS variant of the chip available. Then the time slot is less than 8us. Im happy that Im not forced to solve this problem.... Greetings Klaus From ulrich.prinz at googlemail.com Thu Feb 16 15:25:58 2012 From: ulrich.prinz at googlemail.com (Ulrich Prinz) Date: Thu, 16 Feb 2012 15:25:58 +0100 Subject: [En-Nut-Discussion] SPI in IRQ In-Reply-To: <5021F9A0-B4B6-479A-8589-9364E7DDD0AA@gmx.de> References: <67F1A9B8-D367-4DB9-8EED-0519FE1687C0@gmx.de> <4F3CCC7E.5090804@egnite.de> <5021F9A0-B4B6-479A-8589-9364E7DDD0AA@gmx.de> Message-ID: Hi Klaus, If I understand the datasheet of the ADC correctly it serves you with /DRDY signal every time a sample is complete. So if you write a GPIO IRQ handler that reads the SPI at this time, you are done with the first part. For reading SPI you need to throw out dummy bytes that just trigger SCK so the ADC can write via MISO to your AT91. To get more free CPU time, you should think about using DMA transfer for SPI. So you set up a dummy region of RAM that hold a fixed pattern of control words and dummy bytes. Then you set up another region to store the read values into. Then you setup and start DMA with completion interrupt set. The DMA completion interrupt then shows your application that there is a new value available. If you need several values at a time, you can expand the regions of dummy and reception values and setup the DMA to transfer this bigger regions. The DMA Interrupt then only counts down the number of samples per block and calls your application after counter has reached 0. To be more flexible and gather some additional time: You can set the AT91 DMA to work with separate pages. So if a DMA is completed you can flip to a nother page where it continues to work right away. So after you sampled one page, you have time to decode and move the date from there, while the DMA continues to write into the second page. After the second page is completed the DMA flips back to the first page or even a third page. If I remeber my last AT91 devel over a year ago, it should be possible to implement you ADC routines with just DMA and a single DMA interrupt handler. In general: You should keep a state variable in you code, that shows if your sampling is active. If not active, you can use normal nut/os SPI functions to setup / program your ADC. After activating your sampling, the variable should state that no normal nut/os function should trigger SPI. You did not state the reason for this construction but in general I would suppose to use the I2S interface of an AT91 or STM32 and use the special features of this interface that automates constant time sampling and delivery of data with very low software overhead including multi buffer handling ( work in one while the other is filled, then switch) I2S is just a derivate of SPI... Ulrich Am 16. Februar 2012 12:04 schrieb Klaus Kloos : > Hello Harald > > Thanks for your fast answer. > >> On 16.02.2012 08:22, Klaus Kloos wrote: >>> So I tried to use the NutOS functions. (*spiBus1At91.bus_alloc) and (*spiBus1At91.bus_release) are called outside the IRQ, ?(*spiBus1At91.bus_transfer) is called at IRQ time. >>> The transfer of the 3 bytes last ca. 12us using 10MHz SPI. It is working, but unreliable. Sometimes my device freezes. >> >> Probably. In general, it is not allowed to call API functions in >> interrupt context, except NutEventPostFromIrq(). As a special exception >> it is possible to use stdio functions on a polling device, usually devDebug. >> > ok, i was aware that this is not the right way. It was only a test and it gave me a 'near to working' result :-) My hope was to get bus-transfer() IRQ save somehow...... > What is necessary to make a function IRQ save? > >>> What are my possibilities? Is there a recommended way to solve such time-critical SPI-requests? >>> Can I get the Nut/OS functions IRQ save somehow? >> >> Nut/OS allows to use native interrupt handlers. For the AT91 you can use >> >> static void MySpiIrqHandler(void) __attribute__ ((naked)); >> void MySpiIrqHandler(void) >> { >> ? ?IRQ_ENTRY(); >> ...your code here... >> ? ?IRQ_EXIT(); >> } >> >> In your main code you need to write the address of the handler into the >> related AIC service routine register. >> >> outr(AIC_SVR(SPI0_ID), (unsigned int) MySpiIrqHandler); >> > Interesting, this might give me back the 1us which I loose between an IRQ and the calling of my IRQ-routine using the NutOS way. > > But that's not the main problem. How do I get the SPI-Value in my 30us slot? I see these ways: > Is there a way to generate a fast context-switch from IRQ to the thread which is allowed to call bus_transfer()? Can this be done reliable in ca. 10us? > Then I can use the NutOS SPI routines. > > An other way is the read the data in the IRQ. But then I have to code a function like bus_transfer() by myself (?). Not a nice chance... > > A simple solution would be working without an IRQ and do everything in a thread without allowing a context-switch. So the sam7 will freeze for up to 50ms (i have to read 1000 values). > >> And...not to forget...it is always a good idea to check the datasheet. ;-) >> > Not that I have completely memorized it, but Ive read it several times. The problem seems clear. Im too slow. > There is also a 128kSPS variant of the chip available. Then the time slot is less than 8us. Im happy that Im not forced to solve this problem.... > > Greetings Klaus > _______________________________________________ > http://lists.egnite.de/mailman/listinfo/en-nut-discussion From ulrich.prinz at googlemail.com Thu Feb 16 16:00:35 2012 From: ulrich.prinz at googlemail.com (Ulrich Prinz) Date: Thu, 16 Feb 2012 16:00:35 +0100 Subject: [En-Nut-Discussion] Feature Request: Create Application Directory" for (q)nutconf In-Reply-To: References: <1328712760.2167.51.camel@platon> <4F37A2F1.1060302@googlemail.com> Message-ID: Hi Thiago, Im an not sure if it is wise to only keep one nut/os for several different projects... In commercial programming you need to be able to restore every release of your software and sometimes you must restore an old state that has generates an identical md5sum of the binry output. So if you in the meantime have improved nut/os with some things, you cannot restore the project to an identical checksum as the libraries have changed. What we do is to keep the following structure under version control: project-x/nut project-x/nutapp-arch-gcc project-x/nutapp-arch-gcc/bootloader project-x/nutapp-arch-gcc/device-a project-x/nutapp-arch-gcc/device-b project-x/nutapp-arch-gcc/device-c So if a new person joins development, - he checks out project-x - starts qnutconf with the project-x.conf file - builds nut/os - build application If a new project is started you can either switch / branch to it from an existing constellation or you could export your current projext-x/nut to a new porject-y. - run qnutconf with a most matching existing conf, modify it and do an initial checkin. - build nut/os, create sample directory - add your new device-f or copy/rename a matching demo code (mostly uart demo :) ) - delete all unneeded demo directories. - check in the device With that procedure you can keep the nut/os and application / device sources und strict version control. It is even possible to switch achitecture in the evaluation phase of a project and keeping both architectures side by side to see what is most efficient. So for me it is really helpfull to be able to create and (important) update that nutapp-arch-xyz directory including all Makefiles but excluding all demos. What we did in the past was to take nut/os from sourceforge and our applications from our own version control system. But it showed up that this was not working as there is no link between the application software version and the nut/os software version. You either need to check in nut/os in an unclean state to have a fixed revision number or you have to track all differencs to the last checkout. Any other way will lead to the situation where the last generated binary file for a device cannot be reproduced anymore. Best regards Ulrich Am 15. Februar 2012 20:38 schrieb Thiago A. Corr?a : > Hi, > > > I have been wondering for a while how we could have a "New Project > with Nut/OS" kind of wizard, like visual studio, into qnutconf and how > it would build you the basic makefiles. It's interesting to know how > ppl actually use Nut/OS in their environment. > > In particular, I keep my nuts/os in c:\programming\ethernut and my > projects as c:\programming\comm5\firmware\ > Inside I create a makefile that references the sample > makefiles like this: > > include /programming/ethernut/nutapp/Makedefs > > SRCS = ?mysource.c > LIBS = ?$(LIBDIR)/nutinit.o -lnutos -lnutarch -lnutdev -lnutcrt -lnutc -lnutgorp > OBJS = ?$(SRCS:.c=.o) > TARG = ?$(PROJ).hex > > all: $(OBJS) $(TARG) $(ITARG) $(DTARG) > > dep: > ? ? ? ?$(CC) -I$(top_srcdir)/include -M main.c > > > include /programming/ethernut/nutapp/Makerules > > > It's simple and shouldn't be hard to generate, yet I don't think it's > simple enough for the beginner. I'm interested in opinions. > > > Kind Regards, > ? ?Thiago A. Correa > > On Sun, Feb 12, 2012 at 9:30 AM, Ulrich Prinz > wrote: >> Hi! >> >> At first the separation of directory and makefile generation from >> creation of all examples would be very helpfull. >> >> To add an option that enables to export all libraries and headers and >> creates a set of working application makefiles is very fine. >> We often need to keep nut/os libraries synced with the application >> source code to be able to reproduce avery single software release. >> >> So if we could export the libraries and headers in parallel with the >> applications it would be very handy for checking them in to SVN or >> GIT. >> >> Ulrich >> >> >> Am 08.02.2012 15:52, schrieb Ole Reinhardt: >>> Hi Ulrich, >>> >>>> But if you develop lots of your own projects you might not like to >>>> have all the examples installed. >>> >>> Yes, I well know this problem. I personally prefer to have a >>> pre-compiled Nut/OS and to use just a few simple makefiles with my >>> application, not all this directory hirarchy. >>> >>> Especialy when deploying Nut/OS as development environment for a board >>> your customers won't ever compile Nut/OS by their own but just use the >>> ready build libraries. >>> >>> So what I would suggest is to add an "Install Nut/OS" which would build >>> the libraries, install it into a folder and add the necessary makefiles >>> (just the ones for your compiler setting) >>> >>> As an example see >>> >>> http://www.embedded-it.de/bsp-download/webserver_relais_demo.tar.gz >>> >>> (folder Nut/OS) >>> >>> I also modified the application standard makefiles to refer to the >>> pre-installed ones. >>> >>> Another idea: >>> >>> This install button could also copy the header files so that one would >>> not have to install the whole source tree too. >>> >>> Bye, >>> >>> Ole >>> >>> >> _______________________________________________ >> http://lists.egnite.de/mailman/listinfo/en-nut-discussion > _______________________________________________ > http://lists.egnite.de/mailman/listinfo/en-nut-discussion From ulrich.prinz at googlemail.com Thu Feb 16 16:19:00 2012 From: ulrich.prinz at googlemail.com (Ulrich Prinz) Date: Thu, 16 Feb 2012 16:19:00 +0100 Subject: [En-Nut-Discussion] Anybody on Embedded World 2012? In-Reply-To: <20283.58110.884872.85050@elektron.ikp.physik.tu-darmstadt.de> References: <1328174237.2086.12.camel@platon> <4F37FD03.7080309@googlemail.com> <20283.58110.884872.85050@elektron.ikp.physik.tu-darmstadt.de> Message-ID: Hi! I thought about having lunch together in the town near by after 18:00 as we drive by car and don't like get into the usual traffic jams in the evening. Ulrich Am 15. Februar 2012 17:53 schrieb Uwe Bonnes : >>>>>> "Ulrich" == Ulrich Prinz writes: > > ? ?Ulrich> So what day do we take 28 or 29? ?Ulrich > > I am planning for the 28. Probably however I will drive home by car with > other people or train home ?at about 18.00. > > Bye > -- > Uwe Bonnes ? ? ? ? ? ? ? ?bon at elektron.ikp.physik.tu-darmstadt.de > > Institut fuer Kernphysik ?Schlossgartenstrasse 9 ?64289 Darmstadt > --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- > _______________________________________________ > http://lists.egnite.de/mailman/listinfo/en-nut-discussion From guillaume.fortaine at devopspace.com Thu Feb 16 23:51:12 2012 From: guillaume.fortaine at devopspace.com (Guillaume Fortaine) Date: Thu, 16 Feb 2012 23:51:12 +0100 Subject: [En-Nut-Discussion] Mini C library, for small embedded MCU Message-ID: Hello, For your information : http://code.google.com/p/minilib-c/ "A small C library, based on newlib library, but more compact and with fewer functions" Best Regards, Guillaume FORTAINE From bon at elektron.ikp.physik.tu-darmstadt.de Fri Feb 17 11:17:52 2012 From: bon at elektron.ikp.physik.tu-darmstadt.de (Uwe Bonnes) Date: Fri, 17 Feb 2012 11:17:52 +0100 Subject: [En-Nut-Discussion] Anybody on Embedded World 2012? In-Reply-To: References: <1328174237.2086.12.camel@platon> <4F37FD03.7080309@googlemail.com> <20283.58110.884872.85050@elektron.ikp.physik.tu-darmstadt.de> Message-ID: <20286.10576.571167.651853@elektron.ikp.physik.tu-darmstadt.de> >>>>> "Ulrich" == Ulrich Prinz writes: Ulrich> Hi! I thought about having lunch together in the town near by Ulrich> after 18:00 as we drive by car and don't like get into the usual Ulrich> traffic jams in the evening. Getting back by train after 18.00 is taking longer. I now have booked a ticket for the 28.2. to arrive at the fair at 10:30 and I have to leave 17:30. If you go the 28.2 too, perhaps we can meet for lunch or a coffee, or even only a talk in some of the meeting points. Bye -- Uwe Bonnes bon at elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- From ulrich.prinz at googlemail.com Fri Feb 17 12:42:25 2012 From: ulrich.prinz at googlemail.com (Ulrich Prinz) Date: Fri, 17 Feb 2012 12:42:25 +0100 Subject: [En-Nut-Discussion] Anybody on Embedded World 2012? In-Reply-To: <20286.10576.571167.651853@elektron.ikp.physik.tu-darmstadt.de> References: <1328174237.2086.12.camel@platon> <4F37FD03.7080309@googlemail.com> <20283.58110.884872.85050@elektron.ikp.physik.tu-darmstadt.de> <20286.10576.571167.651853@elektron.ikp.physik.tu-darmstadt.de> Message-ID: Hi! We had to change to 29th cause of some meetings on 28th... Sorry Regards Ulrich Am 17. Februar 2012 11:17 schrieb Uwe Bonnes : >>>>>> "Ulrich" == Ulrich Prinz writes: > > ? ?Ulrich> Hi! ?I thought about having lunch together in the town near by > ? ?Ulrich> after 18:00 as we drive by car and don't like get into the usual > ? ?Ulrich> traffic jams in the evening. > > Getting back by train after 18.00 is taking longer. > > I now have booked a ticket for the 28.2. to arrive at the fair at 10:30 and > I have to leave 17:30. If you go the 28.2 too, perhaps we can meet for lunch > or a coffee, or even only a talk in some of the meeting points. > > Bye > > -- > Uwe Bonnes ? ? ? ? ? ? ? ?bon at elektron.ikp.physik.tu-darmstadt.de > > Institut fuer Kernphysik ?Schlossgartenstrasse 9 ?64289 Darmstadt > --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- > _______________________________________________ > http://lists.egnite.de/mailman/listinfo/en-nut-discussion From markus.dost at dr-clauss.de Mon Feb 20 08:22:17 2012 From: markus.dost at dr-clauss.de (Markus Dost) Date: Mon, 20 Feb 2012 08:22:17 +0100 Subject: [En-Nut-Discussion] Ethernut 5 + Eclipse tutorial In-Reply-To: <4F3BF8A4.9020800@egnite.de> References: <70E051BE-4CD4-48C1-81D3-8AEC4A889653@dr-clauss.de> <4F364D09.9020602@egnite.de> <4F3BF8A4.9020800@egnite.de> Message-ID: <74F54EEB-B219-4776-91AC-C2CEC862D94F@dr-clauss.de> Hi, I try to debug the Ethernut 5 board with the turtelizer2 and Eclipse. After starting OpenOCD, I want to run the debugging and the console puts out: "Info: accepting 'gdb' connection from 3333" But then the progress stops and this error message appears: "Error in final launch sequence Failed to execute MI command: -target-select remote localhost:3333 Error message from debugger back end: Malformed response to offset query, timeout Malformed response to offset query, timeout" Does anybody know what I've made wrong? Best regards, Markus From harald.kipp at egnite.de Mon Feb 20 09:28:44 2012 From: harald.kipp at egnite.de (Harald Kipp) Date: Mon, 20 Feb 2012 09:28:44 +0100 Subject: [En-Nut-Discussion] Ethernut 5 + Eclipse tutorial In-Reply-To: <74F54EEB-B219-4776-91AC-C2CEC862D94F@dr-clauss.de> References: <70E051BE-4CD4-48C1-81D3-8AEC4A889653@dr-clauss.de> <4F364D09.9020602@egnite.de> <4F3BF8A4.9020800@egnite.de> <74F54EEB-B219-4776-91AC-C2CEC862D94F@dr-clauss.de> Message-ID: <4F42043C.8000608@egnite.de> Hi Markus, On 20.02.2012 08:22, Markus Dost wrote: > But then the progress stops and this error message appears: > "Error in final launch sequence > Failed to execute MI command: > -target-select remote localhost:3333 > > Error message from debugger back end: > Malformed response to offset query, timeout > Malformed response to offset query, timeout" Are you sure that you selected "Standard GDB Hardware Debugging Launcher" http://www.ethernut.de/img/indigo-debug-config-main.png If not, click on "Select other...". May be you should first make sure that the OpenOCD - Turtelizer - Ethernut chain is working. http://www.ethernut.de/en/hardware/enut5/openocd.html Regards, Harald From markus.dost at dr-clauss.de Mon Feb 20 11:17:12 2012 From: markus.dost at dr-clauss.de (Markus Dost) Date: Mon, 20 Feb 2012 11:17:12 +0100 Subject: [En-Nut-Discussion] Ethernut 5 + Eclipse tutorial In-Reply-To: <4F42043C.8000608@egnite.de> References: <70E051BE-4CD4-48C1-81D3-8AEC4A889653@dr-clauss.de> <4F364D09.9020602@egnite.de> <4F3BF8A4.9020800@egnite.de> <74F54EEB-B219-4776-91AC-C2CEC862D94F@dr-clauss.de> <4F42043C.8000608@egnite.de> Message-ID: Hi Harald, Am 20.02.2012 um 09:28 schrieb Harald Kipp: > Are you sure that you selected "Standard GDB Hardware Debugging > Launcher" > Right, I forgot it. But now I get the following error: "symbol-file C:\\ethernut-4.10\\nutapp\\events\\events.elf Ignoring packet error, continuing ... warning: unrecognized item "timeout" in "qSupported" response Ignoring packet error, continuing ... Ignoring packet error, continuing ... Ignoring packet error, continuing ... Ignoring packet error, continuing ... Ignoring packet error, continuing ... load C:\\ethernut-4.10\\nutapp\\events\\events.elf You can't do that when your target is 'None'" The settings for the debugger are the same as in the tutorial. Is it necessary to start a GDB-server? I'm very new at this stuff ... > May be you should first make sure that the OpenOCD - Turtelizer - > Ethernut chain is working. I would say the chain is working. I can load .bin-Files to the board and execute them. Regards, Markus From harald.kipp at egnite.de Mon Feb 20 20:05:55 2012 From: harald.kipp at egnite.de (Harald Kipp) Date: Mon, 20 Feb 2012 20:05:55 +0100 Subject: [En-Nut-Discussion] Ethernut 5 + Eclipse tutorial In-Reply-To: References: <70E051BE-4CD4-48C1-81D3-8AEC4A889653@dr-clauss.de> <4F364D09.9020602@egnite.de> <4F3BF8A4.9020800@egnite.de> <74F54EEB-B219-4776-91AC-C2CEC862D94F@dr-clauss.de> <4F42043C.8000608@egnite.de> Message-ID: <4F429993.3000803@egnite.de> Hi Markus, On 20.02.2012 11:17, Markus Dost wrote: > warning: unrecognized item "timeout" in "qSupported" response > Ignoring packet error, continuing ... > Ignoring packet error, continuing ... > Ignoring packet error, continuing ... > Ignoring packet error, continuing ... > Ignoring packet error, continuing ... > load C:\\ethernut-4.10\\nutapp\\events\\events.elf > You can't do that when your target is 'None'" > > The settings for the debugger are the same as in the tutorial. Is it > necessary to start a GDB-server? I'm very new at this stuff ... OpenOCD works as a GDB server in this case and yes, it needs to be started, either manually or from within OpenOCD. http://www.ethernut.de/en/tools/eclipse/confdebug.html (Near the end of that page) The tricky part may be how to start it. You may set the SDRAM Configuration in Eclipse http://www.ethernut.de/en/hardware/enut5/enut50scd43.png but I prefer the command line version openocd -d3 -s ../../nut/tools/turtelizer2 -c "source [find interface/turtelizer2.cfg]" -c "source [find board/ethernut5.cfg]" -c init -c "reset init" -c halt as done here http://www.ethernut.de/img/indigo-debug-tools.png In this case you don't need to specify any montior commands http://www.ethernut.de/img/indigo-debug-config-startup.png (Textarea below "Halt" is left empty) Best regards, Harald From ole.reinhardt at embedded-it.de Mon Feb 20 21:28:57 2012 From: ole.reinhardt at embedded-it.de (Ole Reinhardt) Date: Mon, 20 Feb 2012 21:28:57 +0100 Subject: [En-Nut-Discussion] Strange newlib syscall dependencies / linker problems when using 64bit integers In-Reply-To: <23491BEC-072A-446D-92B5-760C27D7CBF8@gmx.de> References: <1328566767.2181.11.camel@platon> <20273.21491.975139.994432@elektron.ikp.physik.tu-darmstadt.de> <1328703310.2167.5.camel@platon> <20274.26791.136327.58886@elektron.ikp.physik.tu-darmstadt.de> <23491BEC-072A-446D-92B5-760C27D7CBF8@gmx.de> Message-ID: <1329769737.2299.3.camel@platon> Hi all, I've been on a business trip for the last week, so sorry for the late answer. > Some days ago there have been problems with linking using 64bit integers and im not shure if a solution was found. I stumbled over the same problem and found the following solution for me (Ethernut 4.10, yagarto). > the following: > --- > /* .ARM.exidx is sorted, so has to go in its own output section. kl for using long long*/ > .ARM.exidx : { > __exidx_start = .; > *(.ARM.exidx* .gnu.linkonce.armexidx.*) > __exidx_end = .; > } >rom > --- > was added to my .ld file right after the .text segment > > Somewhere i had to create the empty functions: > --- > void _sbrk(void){ > } > > void _getpid(void){ > } > > void _kill(void){ > } > > void _exit(int status){ > while(1){;} > } Yes this is the solution. I decided to go another way and to use only 32bit integers after a redesign of my algorithm. The mentioned function stubs are the needed "syscall" stubs for Newlib. In fact they hopefully won't ever be used. The _exit() function will only be called in case of a "software exeption" like a division by zero. Bye, Ole -- Thermotemp GmbH, Embedded-IT Embedded Hard-/ Software and Open Source Development, Integration and Consulting http://www.embedded-it.de Gesch?ftsstelle Siegen - Steinstra?e 67 - D-57072 Siegen - tel +49 (0)271 5513597, +49 (0)271-73681 - fax +49 (0)271 736 97 Hauptsitz - Hademarscher Weg 7 - 13503 Berlin Tel +49 (0)30 4315205 - Fax +49 (0)30 43665002 Gesch?ftsf?hrer: J?rg Friedrichs, Ole Reinhardt Handelsregister Berlin Charlottenburg HRB 45978 UstID DE 156329280 From ole.reinhardt at embedded-it.de Mon Feb 20 21:31:54 2012 From: ole.reinhardt at embedded-it.de (Ole Reinhardt) Date: Mon, 20 Feb 2012 21:31:54 +0100 Subject: [En-Nut-Discussion] Anybody on Embedded World 2012? In-Reply-To: <20286.10576.571167.651853@elektron.ikp.physik.tu-darmstadt.de> References: <1328174237.2086.12.camel@platon> <4F37FD03.7080309@googlemail.com> <20283.58110.884872.85050@elektron.ikp.physik.tu-darmstadt.de> <20286.10576.571167.651853@elektron.ikp.physik.tu-darmstadt.de> Message-ID: <1329769914.2299.5.camel@platon> Hi all, > Getting back by train after 18.00 is taking longer. I'll be there at the 28.02. too. Let's exchange phone numbers before or agree on a meeting point / time :) Bye, Ole -- Thermotemp GmbH, Embedded-IT Embedded Hard-/ Software and Open Source Development, Integration and Consulting http://www.embedded-it.de Gesch?ftsstelle Siegen - Steinstra?e 67 - D-57072 Siegen - tel +49 (0)271 5513597, +49 (0)271-73681 - fax +49 (0)271 736 97 Hauptsitz - Hademarscher Weg 7 - 13503 Berlin Tel +49 (0)30 4315205 - Fax +49 (0)30 43665002 Gesch?ftsf?hrer: J?rg Friedrichs, Ole Reinhardt Handelsregister Berlin Charlottenburg HRB 45978 UstID DE 156329280 From markus.dost at dr-clauss.de Tue Feb 21 08:09:02 2012 From: markus.dost at dr-clauss.de (Markus Dost) Date: Tue, 21 Feb 2012 08:09:02 +0100 Subject: [En-Nut-Discussion] Ethernut 5 + Eclipse tutorial In-Reply-To: <4F429993.3000803@egnite.de> References: <70E051BE-4CD4-48C1-81D3-8AEC4A889653@dr-clauss.de> <4F364D09.9020602@egnite.de> <4F3BF8A4.9020800@egnite.de> <74F54EEB-B219-4776-91AC-C2CEC862D94F@dr-clauss.de> <4F42043C.8000608@egnite.de> <4F429993.3000803@egnite.de> Message-ID: Hi Harald Am 20.02.2012 um 20:05 schrieb Harald Kipp: > OpenOCD works as a GDB server in this case and yes, it needs to be > started, either manually or from within OpenOCD. > > http://www.ethernut.de/en/tools/eclipse/confdebug.html > (Near the end of that page) > > The tricky part may be how to start it. You may set the SDRAM > Configuration in Eclipse > > http://www.ethernut.de/en/hardware/enut5/enut50scd43.png > > but I prefer the command line version > > openocd -d3 -s ../../nut/tools/turtelizer2 -c "source [find > interface/turtelizer2.cfg]" -c "source [find board/ethernut5.cfg]" - > c init -c "reset init" -c halt > > as done here > > http://www.ethernut.de/img/indigo-debug-tools.png > > In this case you don't need to specify any montior commands > > http://www.ethernut.de/img/indigo-debug-config-startup.png > (Textarea below "Halt" is left empty) Thank your for your help but my settings for OpenOCD and the debug configuration are exactly what you've written here. Here are the console outputs after starting OpenOCD: Open On-Chip Debugger 0.5.0 (2011-11-23-10:33) Licensed under GNU GPL v2 For bug reports, read http://openocd.berlios.de/doc/doxygen/bugs.html Info : only one transport option; autoselect 'jtag' trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain adapter_nsrst_delay: 300 jtag_ntrst_delay: 200 RCLK - adaptive srst_only separate srst_gates_jtag srst_open_drain Info : device: 4 "2232C" Info : deviceID: 67354056 Info : SerialNumber: TLV6QNFFA Info : Description: Turtelizer JTAG/RS232 Adapter A Info : RCLK (adaptive clock speed) not supported - fallback to 3 kHz Info : JTAG tap: at91sam9260.cpu tap/device found: 0x0792603f (mfg: 0x01f, part: 0x7926, ver: 0x0) Info : Embedded ICE version 6 Info : at91sam9260.cpu: hardware has 2 breakpoint/watchpoint units RCLK not supported - fallback to 5 kHz target state: halted target halted in ARM state due to debug-request, current mode: Supervisor cpsr: 0x400000d3 pc: 0x27f72084 MMU: disabled, D-Cache: disabled, I-Cache: enabled Info : JTAG tap: at91sam9260.cpu tap/device found: 0x0792603f (mfg: 0x01f, part: 0x7926, ver: 0x0) target state: halted target halted in ARM state due to breakpoint, current mode: Supervisor cpsr: 0x000000d3 pc: 0x00000000 MMU: disabled, D-Cache: disabled, I-Cache: disabled RCLK not supported - fallback to 3000 kHz dcc downloads are enabled Warn : NOTE! Severe performance degradation without fast memory access enabled. Type 'help fast'. Info : accepting 'gdb' connection from 3333 and the arm-none-eabi-gdb.exe: symbol-file C:\\ethernut-4.10\\nutapp\\events\\events.elf Ignoring packet error, continuing... warning: unrecognized item "timeout" in "qSupported" response Ignoring packet error, continuing... Ignoring packet error, continuing... Ignoring packet error, continuing... Ignoring packet error, continuing... Ignoring packet error, continuing... Ignoring packet error, continuing... load C:\\ethernut-4.10\\nutapp\\events\\events.elf You can't do that when your target is `None' set $pc=0x20000000 No registers. tbreak main Cannot access memory at address 0x200002a4 continue The program is not being run. For me it seems that the arm-none-eabi-gdb.exe has problems to access the controller. Regards, Markus From harald.kipp at egnite.de Tue Feb 21 12:48:50 2012 From: harald.kipp at egnite.de (Harald Kipp) Date: Tue, 21 Feb 2012 12:48:50 +0100 Subject: [En-Nut-Discussion] Ethernut 5 + Eclipse tutorial In-Reply-To: References: <70E051BE-4CD4-48C1-81D3-8AEC4A889653@dr-clauss.de> <4F364D09.9020602@egnite.de> <4F3BF8A4.9020800@egnite.de> <74F54EEB-B219-4776-91AC-C2CEC862D94F@dr-clauss.de> <4F42043C.8000608@egnite.de> <4F429993.3000803@egnite.de> Message-ID: <4F4384A2.9010204@egnite.de> Hi Markus, On 21.02.2012 08:09, Markus Dost wrote: > and the arm-none-eabi-gdb.exe: > > symbol-file C:\\ethernut-4.10\\nutapp\\events\\events.elf > Ignoring packet error, continuing... > warning: unrecognized item "timeout" in "qSupported" response > Ignoring packet error, continuing... > Ignoring packet error, continuing... > Ignoring packet error, continuing... > Ignoring packet error, continuing... > Ignoring packet error, continuing... > Ignoring packet error, continuing... > load C:\\ethernut-4.10\\nutapp\\events\\events.elf > You can't do that when your target is `None' > set $pc=0x20000000 > No registers. > tbreak main > Cannot access memory at address 0x200002a4 > continue > The program is not being run. > > For me it seems that the arm-none-eabi-gdb.exe has problems to access > the controller. Mh...no idea right now. I've updated the webpage http://www.ethernut.de/en/tools/eclipse/confdebug.html Here's my ethernut5.cfg ======================================================================= # We add to the minimal configuration. source [find target/at91sam9260.cfg] # If DCC downloads are enabled, we need a work area. # The configuration line below is intentionally commented, # because this option may fail when code is directly loaded # into internal SRAM. In this case you may provide another # area, a few kB will do. The configuration below will occupy # the complete SRAM. #$_TARGETNAME configure -work-area-phys 0x00300000 -work-area-size 0x8000 $_TARGETNAME configure -event reset-start { # At reset CPU runs at 32.768 kHz. # JTAG Frequency must be 6 times slower if RCLK is not supported. jtag_rclk 5 # For memory access we must halt the CPU halt wait_halt # Optionally enable DCC downloads. If enabled, # a work area must be provided too (see above). # arm7_9 dcc_downloads enable ;# Enable faster DCC downloads # RSTC_MR : enable user reset, MMU may be enabled... use physical address mww phys 0xfffffd08 0xa5000501 } $_TARGETNAME configure -event reset-init { mww 0xfffffd44 0x00008000 ;# WDT_MR : disable watchdog mww 0xfffffc20 0x00004001 ;# CKGR_MOR : enable the main oscillator sleep 20 ;# wait 20 ms mww 0xfffffc30 0x00000001 ;# PMC_MCKR : switch to main oscillator sleep 10 ;# wait 10 ms mww 0xfffffc28 0x2060bf09 ;# CKGR_PLLAR: Set PLLA Register for 198.656 MHz sleep 20 ;# wait 20 ms mww 0xfffffc30 0x00000101 ;# PMC_MCKR : Select prescaler (divide by 2) sleep 10 ;# wait 10 ms mww 0xfffffc30 0x00000102 ;# PMC_MCKR : Clock from PLLA is selected (99.328 MHz) sleep 10 ;# wait 10 ms # Increase JTAG Speed to 6 MHz if RCLK is not supported jtag_rclk 5000 # Fast memory access may fail, when the CPU is running # in slow clock mode. Intentionally disabled by default. # arm7_9 fast_memory_access enable mww 0xfffff870 0xffff0000 ;# PIO_ASR : Select peripheral function for D15..D31 mww 0xfffff804 0xffff0000 ;# PIO_PDR : Disable PIO function for D15..D31 mww 0xffffef1c 0x00010002 ;# EBI_CSA : Assign EBI Chip Select 1 to SDRAM, VDDIOMSEL set for +3V3 memory mww 0xffffea08 0x85227259 ;# SDRAMC_CR : Configure SDRAM (2 x Micron MT48LC16M16A2 : 4M x 16Bit x 4 Banks) mww 0xffffea00 0x1 ;# SDRAMC_MR : issue a NOP command mww 0x20000000 0 mww 0xffffea00 0x2 ;# SDRAMC_MR : issue an 'All Banks Precharge' command mww 0x20000000 0 mww 0xffffea00 0x4 ;# SDRAMC_MR : issue 8 x 'Auto-Refresh' Command mww 0x20000000 0 mww 0xffffea00 0x4 mww 0x20000000 0 mww 0xffffea00 0x4 mww 0x20000000 0 mww 0xffffea00 0x4 mww 0x20000000 0 mww 0xffffea00 0x4 mww 0x20000000 0 mww 0xffffea00 0x4 mww 0x20000000 0 mww 0xffffea00 0x4 mww 0x20000000 0 mww 0xffffea00 0x4 mww 0x20000000 0 mww 0xffffea00 0x3 ;# SDRAMC_MR : issue a 'Load Mode Register' command mww 0x20000000 0 mww 0xffffea00 0x0 ;# SDRAMC_MR : normal mode mww 0x20000000 0 mww 0xffffea04 0x2b6 ;# SDRAMC_TR : Set refresh timer count to 7us # mww 0xFFFFEF00 0x00000003 ;# MATRIX_MRCR : Remap internal SRAM to address 0 } ======================================================================= Here is the at91sam9260.cfg ======================================================================= ###################################### # Target: Atmel AT91SAM9260 ###################################### if { [info exists CHIPNAME] } { set _CHIPNAME $CHIPNAME } else { set _CHIPNAME at91sam9260 } if { [info exists ENDIAN] } { set _ENDIAN $ENDIAN } else { set _ENDIAN little } if { [info exists CPUTAPID ] } { set _CPUTAPID $CPUTAPID } else { # force an error till we get a good number set _CPUTAPID 0x0792603f } reset_config trst_and_srst separate trst_push_pull srst_open_drain # jtag newtap $_CHIPNAME cpu -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id $_CPUTAPID jtag_nsrst_delay 300 jtag_ntrst_delay 200 jtag_rclk 3 ###################### # Target configuration ###################### set _TARGETNAME $_CHIPNAME.cpu target create $_TARGETNAME arm926ejs -endian $_ENDIAN -chain-position $_TARGETNAME -variant arm926ejs # Internal sram1 memory $_TARGETNAME configure -work-area-phys 0x00300000 -work-area-size 0x1000 -work-area-backup 1 ======================================================================= and finally the turtelizer2.cfg ======================================================================= # # egnite Turtelizer 2 # # http://www.ethernut.de/en/hardware/turtelizer/index.html # interface turtle ft2232_device_desc "Turtelizer JTAG/RS232 Adapter" ft2232_layout turtelizer2 ft2232_vid_pid 0x0403 0xbdc8 reset_config srst_only ======================================================================= One thing you may try is to reduce jtag_rclk 5000 to mmmmhhhh... jtag_rclk 1000 Just in case that there are cable problems. Btw. are you using the original red JTAG adapter board with the four header connectors? Regards, Harald From hs at ehse.de Tue Feb 21 14:18:05 2012 From: hs at ehse.de (Hermann Schulz) Date: Tue, 21 Feb 2012 14:18:05 +0100 Subject: [En-Nut-Discussion] En-Nut-Discussion Digest, Vol 100, Issue 14 In-Reply-To: References: Message-ID: <4F2A84D399A34099B82156600364CF41@buerorechner> Hello Rob, have you documented the problems? We also have an interest in our application to upgrade the ATMEGA256 Can you give us some hints? Best Regards Hermann Today's Topics: 1. Re: 2561with more than 128k code and Winavr (PragmaLab (Rob van Lieshout)) Codesize > 128K for the ATMega256 and WinAVR shouldn't be a problem at all. First WinAVR version that dealt correctly with the 128k boundary was 20070525. We still use that one for our (commercial) product (almost 256K used now). Not sure what the problem can be exactly, but if you wish I could send you my makefile. WinAVR 20100110 can be used as well. At the time (must be more then 4 years now), we had lots of problems when we ported our code to the Mega256, but one by one the problems were solved. Regards, Rob From markus.dost at dr-clauss.de Tue Feb 21 14:27:26 2012 From: markus.dost at dr-clauss.de (Markus Dost) Date: Tue, 21 Feb 2012 14:27:26 +0100 Subject: [En-Nut-Discussion] Ethernut 5 + Eclipse tutorial In-Reply-To: <4F4384A2.9010204@egnite.de> References: <70E051BE-4CD4-48C1-81D3-8AEC4A889653@dr-clauss.de> <4F364D09.9020602@egnite.de> <4F3BF8A4.9020800@egnite.de> <74F54EEB-B219-4776-91AC-C2CEC862D94F@dr-clauss.de> <4F42043C.8000608@egnite.de> <4F429993.3000803@egnite.de> <4F4384A2.9010204@egnite.de> Message-ID: <77065E5F-1EC9-4C31-9D12-C99129F17842@dr-clauss.de> Hi Harald, there were some differences between my ethernut5.cfg- and turtelizer2.cfg-files and yours. Mainly in the ethernut5.cfg. But when I use your files the debugging works :-) . Only the console of OpenOCD displays some warnings after starting it: Warn : NOTE! DCC downloads have not been enabled, defaulting to slow memory writes. Type 'help dcc'. Warn : NOTE! Severe performance degradation without fast memory access enabled. Type 'help fast'. And after starting the debugging it puts out: Warn : acknowledgment received, but no packet pending Do I have to worry about these? Thank you very much for your help. Best regards, Markus From harald.kipp at egnite.de Tue Feb 21 14:51:48 2012 From: harald.kipp at egnite.de (Harald Kipp) Date: Tue, 21 Feb 2012 14:51:48 +0100 Subject: [En-Nut-Discussion] Ethernut 5 + Eclipse tutorial In-Reply-To: <77065E5F-1EC9-4C31-9D12-C99129F17842@dr-clauss.de> References: <70E051BE-4CD4-48C1-81D3-8AEC4A889653@dr-clauss.de> <4F364D09.9020602@egnite.de> <4F3BF8A4.9020800@egnite.de> <74F54EEB-B219-4776-91AC-C2CEC862D94F@dr-clauss.de> <4F42043C.8000608@egnite.de> <4F429993.3000803@egnite.de> <4F4384A2.9010204@egnite.de> <77065E5F-1EC9-4C31-9D12-C99129F17842@dr-clauss.de> Message-ID: <4F43A174.5020907@egnite.de> Hi Markus, I further enhanced the debugging page http://www.ethernut.de/en/tools/eclipse/confdebug.html with a new chapter "Solving OpenOCD and GDB Problems" On 21.02.2012 14:27, Markus Dost wrote: > there were some differences between my ethernut5.cfg- and > turtelizer2.cfg-files and yours. Mainly in the ethernut5.cfg. But when > I use your files the debugging works :-) . Mh...may be the Turtelizer/OpenOCD package needs to be updated. In any case http://www.ethernut.de/en/hardware/enut5/openocd.html should help to understand what is going on. > Only the console of OpenOCD displays some warnings after starting it: > > Warn : NOTE! DCC downloads have not been enabled, defaulting to slow > memory writes. Type 'help dcc'. Warn : NOTE! Severe performance > degradation without fast memory access enabled. Type 'help fast'. This is explained on that page in chapter "Optimizing Binary Downloads". > And after starting the debugging it puts out: > > Warn : acknowledgment received, but no packet pending > > Do I have to worry about these? Same here, no idea. Seems to be harmless. > Thank you very much for your help. Thank _you_ for your patience. Sometimes the OpenOCD/GDB/Eclipse combo is a bullheaded bastard, that drives me crazy. But over the time I understand more details and found, that actually everything is running quite well. Anyway, my writing is behind and the documents still need some polishing. Regards, Harald From bon at elektron.ikp.physik.tu-darmstadt.de Tue Feb 21 16:18:09 2012 From: bon at elektron.ikp.physik.tu-darmstadt.de (Uwe Bonnes) Date: Tue, 21 Feb 2012 16:18:09 +0100 Subject: [En-Nut-Discussion] node_cs definition in NUTSPINODE Message-ID: <20291.46513.680158.931408@elektron.ikp.physik.tu-darmstadt.de> Hello, if I understand right, node_cs in the NUTSPINODE structure is a symbolic number that later in xxxSpiChipSelect() gets decoded from a fixed list of possibilities into port/pin and an access to that port/pin combination. Why don't we use both a node_port and node_pin entry in the NUTSPINODE structure and xxxSpiChipSelect() does the access direct on the resulting port/pin combination, at the cost of a NUTSPINODE structure 4 to 7 bytes larger. 4 Bytes larger if the compiler aligns the NUTSPINODE structure at 4 byte, 7 bytes with no alignment in the NUTSPINODE structure. If structure size is an issue, we could also encode port and pin via ((symbolic port number)& 0x0f) << 4 | (pin & 0x0f), in a microsoft like attitude : Nobody will ever use more then 16 ports with 16 pins each :-) or as uint16_t with ((symbolic port number) & 0xff) << 8 | (pin & 0xff) That way, users can have SPI CS on arbitrary pins without the need to change NUTOS. On cm3 node_cs could also be the 32 bit bit-band adress to the GPIOx_BSRR of that port/bit. To set CS high, we would write 1 to that address, to set CS low we would write 1 to the address 64 bytes above. In that light I propose to make node_cs a 32 bits entitie. Bye -- Uwe Bonnes bon at elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- From harald.kipp at egnite.de Tue Feb 21 19:57:21 2012 From: harald.kipp at egnite.de (Harald Kipp) Date: Tue, 21 Feb 2012 19:57:21 +0100 Subject: [En-Nut-Discussion] node_cs definition in NUTSPINODE In-Reply-To: <20291.46513.680158.931408@elektron.ikp.physik.tu-darmstadt.de> References: <20291.46513.680158.931408@elektron.ikp.physik.tu-darmstadt.de> Message-ID: <4F43E911.6090203@egnite.de> Hello Uwe, On 21.02.2012 16:18, Uwe Bonnes wrote: > if I understand right, node_cs in the NUTSPINODE structure is a symbolic > number that later in xxxSpiChipSelect() gets decoded from a fixed list of > possibilities into port/pin and an access to that port/pin combination. That's right. The "fixed" list is configurable, of course. > That way, users can have SPI CS on arbitrary pins without the need to change > NUTOS. After finishing the code, I discovered that passing the chip select number from application code via int NutRegisterSpiDevice(NUTDEVICE * dev, NUTSPIBUS * bus, int cs); was not a good idea. In practice you will configure Nut/OS for a specific board once and never change it. Furthermore, Nut/OS doesn't currently allow to re-use a device. If you got 4 DataFlash chips, you'll need devSpiAt45d0 to devSpiAt45d3. Each SPI bus device has a fixed hardware chip select. > In that light I propose > to make node_cs a 32 bits entitie. My proposal would be to remove the cs parameter and configure the chip select in the device driver. I'm open to arguments, of course. Regards, Harald From ulrich.prinz at googlemail.com Wed Feb 22 17:26:08 2012 From: ulrich.prinz at googlemail.com (Ulrich Prinz) Date: Wed, 22 Feb 2012 17:26:08 +0100 Subject: [En-Nut-Discussion] node_cs definition in NUTSPINODE In-Reply-To: <4F43E911.6090203@egnite.de> References: <20291.46513.680158.931408@elektron.ikp.physik.tu-darmstadt.de> <4F43E911.6090203@egnite.de> Message-ID: Hi! > > was not a good idea. In practice you will configure Nut/OS for a > specific board once and never change it. I fully agree :) > > Furthermore, Nut/OS doesn't currently allow to re-use a device. If you > got 4 DataFlash chips, you'll need devSpiAt45d0 to devSpiAt45d3. Each > SPI bus device has a fixed hardware chip select. > Right, there must be one ICB per used ChipSelect even the SPI bus itself is reused. > >> In that light I propose >> to make node_cs a 32 bits entitie. > > My proposal would be to remove the cs parameter and configure the chip > select in the device driver. > I fully agree, as it is more convenient to do hardware-configuration by qnutconf instead doing some here, some there, some... > I'm open to arguments, of course. Here you got mine :) Ulrich From guillaume.fortaine at devopspace.com Wed Feb 22 22:40:16 2012 From: guillaume.fortaine at devopspace.com (Guillaume Fortaine) Date: Wed, 22 Feb 2012 22:40:16 +0100 Subject: [En-Nut-Discussion] mbed RTOS In-Reply-To: References: Message-ID: Hello, For your information : http://mbed.org/handbook/RTOS#c2681 "Hi Jim, All, FYI, we're now also starting an "official" networking code stack too; we really wanted to have an RTOS in place to allow networking to use a sockets-like interface without the need for polling. Now that is in place, we're on it! More soon... Simon" Best Regards, Guillaume FORTAINE From jose.vallet at aalto.fi Thu Feb 23 07:44:52 2012 From: jose.vallet at aalto.fi (Jose) Date: Thu, 23 Feb 2012 08:44:52 +0200 Subject: [En-Nut-Discussion] node_cs definition in NUTSPINODE In-Reply-To: References: <20291.46513.680158.931408@elektron.ikp.physik.tu-darmstadt.de> <4F43E911.6090203@egnite.de> Message-ID: <4F45E064.9010708@aalto.fi> Hello. Now that you mention CS lines of SPI drivers, one comment. A while ago, before the new SPI drivers (in the 4.6 version), we could not fully use NutOS SPI drivers in our boards because, to our best knowledge, there was not support for decoders in CS lines. That is, we wanted 16 chip select lines from up to 4 pins from the microcontroller. Thus we had to make our own. Let me abuse your knowledge here, so I don't have to check the source code myself(I' a bit rusty ;)): do the new SPI drivers support decoders for the CS lines? If not, it would be a nice feature to have, IMHO. BR Jose On 02/22/2012 06:26 PM, Ulrich Prinz wrote: > Hi! > >> >> was not a good idea. In practice you will configure Nut/OS for a >> specific board once and never change it. > > I fully agree :) >> >> Furthermore, Nut/OS doesn't currently allow to re-use a device. If you >> got 4 DataFlash chips, you'll need devSpiAt45d0 to devSpiAt45d3. Each >> SPI bus device has a fixed hardware chip select. >> > Right, there must be one ICB per used ChipSelect even the SPI bus > itself is reused. >> >>> In that light I propose >>> to make node_cs a 32 bits entitie. >> >> My proposal would be to remove the cs parameter and configure the chip >> select in the device driver. >> > I fully agree, as it is more convenient to do hardware-configuration > by qnutconf instead doing some here, some there, some... > >> I'm open to arguments, of course. > > Here you got mine :) > > Ulrich > _______________________________________________ > http://lists.egnite.de/mailman/listinfo/en-nut-discussion From markus.dost at dr-clauss.de Thu Feb 23 11:20:01 2012 From: markus.dost at dr-clauss.de (Markus Dost) Date: Thu, 23 Feb 2012 11:20:01 +0100 Subject: [En-Nut-Discussion] Ethernut 5: Problem with MMC mounting Message-ID: <296AEE26-B9E4-46B8-9377-DE96FA79B9D9@dr-clauss.de> Hi, I want to use a SD-Card on my Ethernut5-Board and try to mount it with the following code: #ifdef USE_MMCSD int mmc_volume; printf("\nRegister PHAT..."); if (NutRegisterDevice(&devPhat0, 0, 0)){ puts("failed"); } else { puts("OK"); printf("Register %s...", DEV_MMCARD0_NAME); if (NutRegisterDevice(&DEV_MMCARD0, 0, 0)){ puts("failed"); } else { puts("OK"); printf("Mounting MMC-/SD-Card..."); NutThreadYield(); //enable Interrupts mmc_volume = _open(DEV_MMCARD0_NAME ":1/PHAT0", _O_RDWR | _O_BINARY); if (mmc_volume == -1){ printf("failed: error %d\n", errno); } else { puts("OK"); } } } #endif /* USE_MMCSD */ The registrations of the PHAT file system and the MMC-/SD-Card driver work. But the command _open() cannot access my card and fails with the error code 19 (ENODEV). The Nut/OS-Version is 4.10.1 and the card is a Canon SDC-32M with 32 MB. Does anybody have an idea what I've made wrong? Best regards, Markus From bon at elektron.ikp.physik.tu-darmstadt.de Thu Feb 23 11:27:48 2012 From: bon at elektron.ikp.physik.tu-darmstadt.de (Uwe Bonnes) Date: Thu, 23 Feb 2012 11:27:48 +0100 Subject: [En-Nut-Discussion] node_cs definition in NUTSPINODE In-Reply-To: References: <20291.46513.680158.931408@elektron.ikp.physik.tu-darmstadt.de> <4F43E911.6090203@egnite.de> Message-ID: <20294.5284.128644.29814@elektron.ikp.physik.tu-darmstadt.de> >>>>> "Ulrich" == Ulrich Prinz writes: Ulrich> Hi! >> was not a good idea. In practice you will configure Nut/OS for a >> specific board once and never change it. Ulrich> I fully agree :) I disagree: With adrino-like board or the STM32 discovery boards, you have ample pin headers and on a jumper board people would like to connect external SPI devices with their CS_N connected to some arbitray GPIO. But probably in that situation they don't like to do an extra branch of their NUTOS library. And with Jose's question for decoded chip selects even more requirements arise. What if the User could provide his own Stm32SpiChipSelect() function, perhaps by making the Stm32SpiChipSelect() definition in the library __weak__? And with an 32 bit argument to encode the GPIO Pin! >> Furthermore, Nut/OS doesn't currently allow to re-use a device. If >> you got 4 DataFlash chips, you'll need devSpiAt45d0 to >> devSpiAt45d3. Each SPI bus device has a fixed hardware chip select. >> Ulrich> Right, there must be one ICB per used ChipSelect even the SPI Ulrich> bus itself is reused. Think also about the zillion of SPI devices where we don't have a NUTOS driver. Users should be able to use these devices too, even on the same SPI bus as e.g. devSpiAt45d0 with only a diffent CS. Bye -- Uwe Bonnes bon at elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- From ulrich.prinz at googlemail.com Fri Feb 24 11:09:48 2012 From: ulrich.prinz at googlemail.com (Ulrich Prinz) Date: Fri, 24 Feb 2012 11:09:48 +0100 Subject: [En-Nut-Discussion] node_cs definition in NUTSPINODE In-Reply-To: <20294.5284.128644.29814@elektron.ikp.physik.tu-darmstadt.de> References: <20291.46513.680158.931408@elektron.ikp.physik.tu-darmstadt.de> <4F43E911.6090203@egnite.de> <20294.5284.128644.29814@elektron.ikp.physik.tu-darmstadt.de> Message-ID: Hi Uwe, one could see it like this or like that... The problem is that we have to find a compromize between the different options a CPU provides. On some we have GPIO-CS only, on others we have fixed hardware CS and on the third we have not only optional hardware-CS but diffferent modes of it too. I think we have to keep the basic setup features inside qnutconf as these decide the parts of the low level driver that are to be compiled into the library. Then we could make the registration function more Nut/OS standard alike so we provide port and pin as an option instead of a 32bit value that no one knows of how to provide. But then we must add some traps, at least for the debug version of the libraries: If you use an AT91SAM and enable hardware-CS, we must trap a registration to illegal port/pin combinations as only a few pins are provided for CS by this chips. I hope this is a good compromize. Ulrich Am 23. Februar 2012 11:27 schrieb Uwe Bonnes : >>>>>> "Ulrich" == Ulrich Prinz writes: > > ? ?Ulrich> Hi! > ? ?>> ?was not a good idea. In practice you will configure Nut/OS for a > ? ?>> specific board once and never change it. > > ? ?Ulrich> I fully agree :) > > I disagree: > > With adrino-like board or the STM32 discovery boards, you have ample pin > headers and on a jumper board people would like to connect external SPI > devices with their CS_N connected to some arbitray GPIO. But probably in > that situation they don't like to do an extra branch of their NUTOS library. > > And with Jose's question for decoded chip selects even more requirements > arise. What if the User could provide his own Stm32SpiChipSelect() function, > perhaps by making the Stm32SpiChipSelect() definition in the library > __weak__? And with an 32 bit argument to encode the GPIO Pin! > > ? ?>> ?Furthermore, Nut/OS doesn't currently allow to re-use a device. If > ? ?>> you got 4 DataFlash chips, you'll need devSpiAt45d0 to > ? ?>> devSpiAt45d3. Each SPI bus device has a fixed hardware chip select. > ? ?>> > ? ?Ulrich> Right, there must be one ICB per used ChipSelect even the SPI > ? ?Ulrich> bus itself is reused. > > Think also about the zillion of SPI devices where we don't have a NUTOS > driver. Users should be able to use these devices too, even on the same SPI > bus as e.g. devSpiAt45d0 with only a diffent CS. > > Bye > -- > Uwe Bonnes ? ? ? ? ? ? ? ?bon at elektron.ikp.physik.tu-darmstadt.de > > Institut fuer Kernphysik ?Schlossgartenstrasse 9 ?64289 Darmstadt > --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- > _______________________________________________ > http://lists.egnite.de/mailman/listinfo/en-nut-discussion From bon at elektron.ikp.physik.tu-darmstadt.de Sun Feb 26 10:42:28 2012 From: bon at elektron.ikp.physik.tu-darmstadt.de (Uwe Bonnes) Date: Sun, 26 Feb 2012 10:42:28 +0100 Subject: [En-Nut-Discussion] node_cs definition in NUTSPINODE In-Reply-To: References: <20291.46513.680158.931408@elektron.ikp.physik.tu-darmstadt.de> <4F43E911.6090203@egnite.de> <20294.5284.128644.29814@elektron.ikp.physik.tu-darmstadt.de> Message-ID: <20297.65156.609884.709229@elektron.ikp.physik.tu-darmstadt.de> >>>>> "Ulrich" == Ulrich Prinz writes: Ulrich> Hi Uwe, one could see it like this or like that... Ulrich> The problem is that we have to find a compromize between the Ulrich> different options a CPU provides. On some we have GPIO-CS only, Ulrich> on others we have fixed hardware CS and on the third we have not Ulrich> only optional hardware-CS but diffferent modes of it too. Wouldn't a __weak__ linking definition of the NUTOS Stm32SpiChipSelect() function be a good compromise? -- Uwe Bonnes bon at elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- From ulrich.prinz at googlemail.com Mon Feb 27 12:06:46 2012 From: ulrich.prinz at googlemail.com (Ulrich Prinz) Date: Mon, 27 Feb 2012 12:06:46 +0100 Subject: [En-Nut-Discussion] node_cs definition in NUTSPINODE In-Reply-To: <20297.65156.609884.709229@elektron.ikp.physik.tu-darmstadt.de> References: <20291.46513.680158.931408@elektron.ikp.physik.tu-darmstadt.de> <4F43E911.6090203@egnite.de> <20294.5284.128644.29814@elektron.ikp.physik.tu-darmstadt.de> <20297.65156.609884.709229@elektron.ikp.physik.tu-darmstadt.de> Message-ID: I am not sure if that really solves the problems. Ok, in emac we started to implement a cross weak linking. So the emac code provides read and write to phy and the phy provides init and status requests. This is simple as regardless of emac or phy these functions are standarized. With SPI building a standard is difficult as the IPs on the silicons are sometimes totally different. On AVR jou have no CS but have to use manual GPIO. On ARM/Cortex every chip is different. So on SAM7 you can use GPIO, you can use the shadow SPI so you have 4 dedicated and hardware supported CS lines or you can use 1 out of 16 without shadow if you set a decoder behind the 4 CS lines. On STM32 you again have to use GPIO Oh, now I see what you think of! we provide some standarized functions in the main spi driver routine and provide separate CS drivers. Dependant on the nutconf setting the one or the others are linked. I am not sure if that will work as the core spi handling might differ and connect much closer to the CS handling than we expect. Nevertheless we need to provide a cs setup that correspands to our termes. What we have to keep in mind too ist that the SPI bus configuration is highly device dependent. I mean the chip connected on the other end. So setting up the bus is fairly only activating the SPI system, provide clocks to it and select the right alternate pin setups. The real setup is device dependent. So speed, mode, delays whatever is a separate thing. So Stm32SpiChipSelect()... May be we should provide something like this: NutSpiRegister( SPI_BUS); NutSpiAssignDevice( SOME_DEVICE, cs_port, cs_pin, spi_mode, spi_speed); And SOME_DEVICE can be a device that we already provide, but it may be an empty framework that provides a simple read and write functionality too. So one could either use this simple device to work with any SPI slave that he likes in the application code or he might copy that framework and add a new driver that provides more functionality. All that looks more easy to me than uint32_t spi_port = (NUTGPIO_PORTA << 8) | NUT_GPIO_PIN7; int mode = SPI_MODE3; NutSpiRegister( SPI_BUS, &spi_port); _ioctl(SPI_BUS, SPI_SET_MODE, &mode); mode = 100000; _ioctl(SPI_BUS, SPI_SET_SPEED, &mode); and now youre lost as you need to provide a device driver. Ulrich Am 26. Februar 2012 10:42 schrieb Uwe Bonnes : >>>>>> "Ulrich" == Ulrich Prinz writes: > > ? ?Ulrich> Hi Uwe, one could see it like this or like that... > > ? ?Ulrich> The problem is that we have to find a compromize between the > ? ?Ulrich> different options a CPU provides. ?On some we have GPIO-CS only, > ? ?Ulrich> on others we have fixed hardware CS and on the third we have not > ? ?Ulrich> only optional hardware-CS but diffferent modes of it too. > > Wouldn't a __weak__ linking definition of the NUTOS Stm32SpiChipSelect() > function be a good compromise? > > > -- > Uwe Bonnes ? ? ? ? ? ? ? ?bon at elektron.ikp.physik.tu-darmstadt.de > > Institut fuer Kernphysik ?Schlossgartenstrasse 9 ?64289 Darmstadt > --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- > _______________________________________________ > http://lists.egnite.de/mailman/listinfo/en-nut-discussion From bon at elektron.ikp.physik.tu-darmstadt.de Mon Feb 27 15:24:53 2012 From: bon at elektron.ikp.physik.tu-darmstadt.de (Uwe Bonnes) Date: Mon, 27 Feb 2012 15:24:53 +0100 Subject: [En-Nut-Discussion] DEVNUT_M3N: Added board directory for CM3 arch Message-ID: <20299.37429.660346.837110@elektron.ikp.physik.tu-darmstadt.de> Ole, what is the reason to add this directory? ------------------------------------------------------------------------ r3908 | olereinhardt | 2012-02-25 18:23:13 +0100 (Sa, 25. Feb 2012) | 2 Zeilen Added board directory for CM3 arch Don't board specific definitions go into nut/include/arch/[subarch/]board/ ? Or what definitions do go intend to put into nut/arch/cm3/board/ Bye -- Uwe Bonnes bon at elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- From bon at elektron.ikp.physik.tu-darmstadt.de Mon Feb 27 16:07:32 2012 From: bon at elektron.ikp.physik.tu-darmstadt.de (Uwe Bonnes) Date: Mon, 27 Feb 2012 16:07:32 +0100 Subject: [En-Nut-Discussion] Devnut_m3n: Local GIT tree pushed to SVN Message-ID: <20299.39988.561872.265081@elektron.ikp.physik.tu-darmstadt.de> Hello, I just pushed my local Devnut_m3n Git tree to SVN. Areas of work where the extention of Nikolays and Ulrichs work for F1 to STM32L1/STM32F2 and STM32F4 and consolidation of that work. I have tested GPIO/UART/SPI/TWI and small aspects of OTG on different boards. On the F4 Discovery board, I couldn't get the I2C device CS43L22 to acknowledge the I2C address, but on another F4 board with another I2C device I receievd an acknowledge, so this may be F4 Discovery board related. For OTG I only substitued the hardware time used for the UART TX flush by a NUTOS timer. OTG is still picky about the sequence of things happening. E.g. writing to the device while enumeration is still in progress with stall the device. Ulrich, please have a look at how the more flexible L1/F2/F4 remap configuration is implemented and how devices for the different families are handled in general. Some L1/F2/F4 GPIO properities are not mapped yet ( Pull-down, 4 speed option versus 3 speed options on F1). Ole has already a definition for Pull-down for NXP CM3, for the speed option I propose someting like SPEED_SLOW, SPEED_MEDIUM, SPEED_FAST and SPEED_FASTEST with SPEED_SLOW mapped on F1 to SPEED_MEDIUM. Perhaps this is something for Ole and Ulrich to talk about when they perhaps meet on embedded world. Bye -- Uwe Bonnes bon at elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- From ole.reinhardt at embedded-it.de Mon Feb 27 17:59:34 2012 From: ole.reinhardt at embedded-it.de (Ole Reinhardt) Date: Mon, 27 Feb 2012 17:59:34 +0100 Subject: [En-Nut-Discussion] DEVNUT_M3N: Added board directory for CM3 arch In-Reply-To: <20299.37429.660346.837110@elektron.ikp.physik.tu-darmstadt.de> References: <20299.37429.660346.837110@elektron.ikp.physik.tu-darmstadt.de> Message-ID: <1330361974.2153.27.camel@platon> Hi Uwe, > what is the reason to add this directory? > > ------------------------------------------------------------------------ > r3908 | olereinhardt | 2012-02-25 18:23:13 +0100 (Sa, 25. Feb 2012) | 2 Zeilen > > Added board directory for CM3 arch > > > Don't board specific definitions go into > nut/include/arch/[subarch/]board/ > ? > Or what definitions do go intend to put into > nut/arch/cm3/board/ As an example see nut/arch/arm/board/*.c (from trunk) You can put board specific init code in here which will be automaticaly selected during compile time according to the PLATFORM variable configured in the configurator. I need this e.g. to initialise the SDRAM controller and configure board specific I/O pin settings. bye, Ole -- Thermotemp GmbH, Embedded-IT Embedded Hard-/ Software and Open Source Development, Integration and Consulting http://www.embedded-it.de Gesch?ftsstelle Siegen - Steinstra?e 67 - D-57072 Siegen - tel +49 (0)271 5513597, +49 (0)271-73681 - fax +49 (0)271 736 97 Hauptsitz - Hademarscher Weg 7 - 13503 Berlin Tel +49 (0)30 4315205 - Fax +49 (0)30 43665002 Gesch?ftsf?hrer: J?rg Friedrichs, Ole Reinhardt Handelsregister Berlin Charlottenburg HRB 45978 UstID DE 156329280 From guillaume.fortaine at devopspace.com Tue Feb 28 03:29:27 2012 From: guillaume.fortaine at devopspace.com (Guillaume Fortaine) Date: Tue, 28 Feb 2012 03:29:27 +0100 Subject: [En-Nut-Discussion] Webduino In-Reply-To: References: Message-ID: Hello, For your information : https://github.com/sirleech/Webduino "This is an Arduino-based Web Server library, originally developed for a class at NYC Resistor. It's called Webduino, and it's an extensible web server library for the Arduino using the Wiznet-based Ethernet shields. It's released under the MIT license allowing all sorts of reuse. *Features : -URL parameter parsing -Handle the following HTTP Methods: GET, HEAD, POST, PUT, DELETE, PATCH -Web Forms -Images -JSON/RESTful interface -HTTP Basic Authentication" Best Regards, Guillaume FORTAINE From ulrich.prinz at googlemail.com Tue Feb 28 17:02:21 2012 From: ulrich.prinz at googlemail.com (Ulrich Prinz) Date: Tue, 28 Feb 2012 17:02:21 +0100 Subject: [En-Nut-Discussion] Webduino In-Reply-To: References: Message-ID: Hi Guillaume, would you mind stop flooding the mailinglist with this type of 'SPAM'. Most of us are well informed about what's going on in the world of embedded systems, from AVR to CortexA15. We are not living in our own world here and if we need solutions that do not exist in Nut/OS, we ask here... ... and then we might be pleased by receiving links to other sites that present a solution. This is a support request and feature discussion list for Nut/OS, not an embedded world newsletter. Hope, this is ok for you, so thank you for understanding. Ulrich Am 28. Februar 2012 03:29 schrieb Guillaume Fortaine : > Hello, > > For your information : > > https://github.com/sirleech/Webduino > > "This is an Arduino-based Web Server library, originally developed for > a class at NYC Resistor. It's called Webduino, and it's an extensible > web server library for the Arduino using the Wiznet-based Ethernet > shields. It's released under the MIT license allowing all sorts of > reuse. > > *Features : > > -URL parameter parsing > -Handle the following HTTP Methods: GET, HEAD, POST, PUT, DELETE, PATCH > -Web Forms > -Images > -JSON/RESTful interface > -HTTP Basic Authentication" > > Best Regards, > > Guillaume FORTAINE > _______________________________________________ > http://lists.egnite.de/mailman/listinfo/en-nut-discussion From ulrich.prinz at googlemail.com Wed Feb 1 16:59:46 2012 From: ulrich.prinz at googlemail.com (Ulrich Prinz) Date: Wed, 1 Feb 2012 16:59:46 +0100 Subject: [En-Nut-Discussion] devnut_m3n branch linker severely broken? Message-ID: Hi all, in devnut_m3n the linker setup is severely broken. I t is impossible to link a system without big code overhead. It looks like both, stdlib and nutos wrappers, are linked into the system. I tried several approaches to compile a tiny bootloader that was only 6..8k in an older version of the branch and now is 14k or even bigger. It compiled without any problems if -lnutcrt is omitted. In the current branch state nutcrt library cannot be omitted an any way and whole libc.a is included too. Any trial by adding -nostdlib ended in either having nothing or having all. That means: Either you get arm-none-eabi-gcc canboot.o stm32/stm32_can.o stm32/stm32_appl.o stm32/stm32_adc.o paulus/bl_canopen.o paulus/bl_crc.o paulus/bl_user.o paulus/bl_flash.o cmc_led.o cmc_sid.o -mcpu=cortex-m3 -mthumb -mlittle-endian -D__CORTEX__ -g -nostartfiles -L./ -Tstm32f10x_boot.ld -Wl,-Map=canboot.map,--cref,--no-warn-mismatch -L../../nutbld-stm32-gcc/lib -nostdlib -Wl,- -start-group ../../nutbld-stm32-gcc/lib/nutinit.o -lnutos -lnutdev -lnutarch -Wl,--end-group -o canboot.elf paulus/bl_canopen.o: In function `doCANopen': bl_canopen.c:(.text.doCANopen+0x1b8): undefined reference to `memcpy' bl_canopen.c:(.text.doCANopen+0x1ea): undefined reference to `memcpy' paulus/bl_flash.o: In function `flashData': bl_flash.c:(.text.flashData+0x22): undefined reference to `memset' ../../nutbld-stm32-gcc/lib\libnutos.a(heap.o): In function `NutHeapRootAllocClear': heap.c:(.text.NutHeapRootAllocClear+0x10): undefined reference to `memset' ../../nutbld-stm32-gcc/lib\libnutos.a(heap.o): In function `NutHeapRootRealloc': heap.c:(.text.NutHeapRootRealloc+0xa0): undefined reference to `memcpy' ../../nutbld-stm32-gcc/lib\libnutos.a(heap.o): In function `NutHeapDump': heap.c:(.text.NutHeapDump+0x12): undefined reference to `fprintf' ../../nutbld-stm32-gcc/lib\libnutos.a(thread.o): In function `GetThreadByName': thread.c:(.text.GetThreadByName+0x12): undefined reference to `strcmp' ../../nutbld-stm32-gcc/lib\libnutos.a(timer.o): In function `NutClockSet': timer.c:(.text.NutClockSet+0x8): undefined reference to `memset' ../../nutbld-stm32-gcc/lib\libnutos.a(confos.o): In function `NutLoadConfig': confos.c:(.text.NutLoadConfig+0x1c): undefined reference to `memcmp' confos.c:(.text.NutLoadConfig+0x26): undefined reference to `strcpy' ../../nutbld-stm32-gcc/lib\libnutos.a(confos.o): In function `NutSaveConfig': confos.c:(.text.NutSaveConfig+0x10): undefined reference to `memcpy' ../../nutbld-stm32-gcc/lib\libnutarch.a(context.o): In function `NutThreadCreate': context.c:(.text.NutThreadCreate+0x46): undefined reference to `memcpy' ../../nutbld-stm32-gcc/lib\libnutarch.a(stm32_flash.o): In function `Stm32FlashRead': stm32_flash.c:(.text.Stm32FlashRead+0x2): undefined reference to `memcpy' ../../nutbld-stm32-gcc/lib\libnutarch.a(stm32_flash.o): In function `Stm32FlashWrite': stm32_flash.c:(.text.Stm32FlashWrite+0x7a): undefined reference to `memcpy' stm32_flash.c:(.text.Stm32FlashWrite+0x96): undefined reference to `memcpy' ../../nutbld-stm32-gcc/lib\libnutarch.a(stm32_flash.o):stm32_flash.c:(.text.Stm32FlashWrite+0xa0): more undefined references to `memcpy' follow ../../nutbld-stm32-gcc/lib\libnutarch.a(stm32_flash.o): In function `Stm32FlashParamWrite': stm32_flash.c:(.text.Stm32FlashParamWrite+0x2c): undefined reference to `memcmp' collect2: ld returned 1 exit status make: *** [canboot.elf] Error 1 Or you get LDFLAGS: -mcpu=cortex-m3 -mthumb -mlittle-endian -D__CORTEX__ -g -nostartfiles -L./ -Tstm32f10x_boot.ld -Wl,-Map=canboot.map,--cr ef,--no-warn-mismatch -L../../nutbld-stm32-gcc/lib ************************************************** arm-none-eabi-gcc canboot.o stm32/stm32_can.o stm32/stm32_appl.o stm32/stm32_adc.o paulus/bl_canopen.o paulus/bl_crc.o paulus/bl_user.o paulus/bl_flash.o cmc_led.o cmc_sid.o -mcpu=cortex-m3 -mthumb -mlittle-endian -D__CORTEX__ -g -nostartfiles -L./ -Tstm32f10x_boot.ld -Wl,-Map=canboot.map,--cref,--no-warn-mismatch -L../../nutbld-stm32-gcc/lib -Wl,--start-group ../../nutbld-stm32-gcc/lib/nutinit.o -lnutos -lnutdev -lnutarch -Wl,--end-group -o canboot.elf c:/programme/yagarto/bin/../lib/gcc/arm-none-eabi/4.6.0/../../../../arm-none-eabi/bin/ld.exe: canboot.elf section `.text' will not fit in region `FLASH0' c:/programme/yagarto/bin/../lib/gcc/arm-none-eabi/4.6.0/../../../../arm-none-eabi/bin/ld.exe: region `FLASH0' overflowed by 5616 bytes collect2: ld returned 1 exit status make: *** [canboot.elf] Error 1 Our you get lots of missing _fopen() _fwrite() _sbrk_r()... of the newlib. I actually have no idea of how to fix that... I tried comparision of the different versions but do not find the modification that is the cause for this. Best regards Ulrich From ole.reinhardt at embedded-it.de Wed Feb 1 17:10:39 2012 From: ole.reinhardt at embedded-it.de (Ole Reinhardt) Date: Wed, 01 Feb 2012 17:10:39 +0100 Subject: [En-Nut-Discussion] devnut_m3n branch linker severely broken? In-Reply-To: References: Message-ID: <1328112639.2090.32.camel@platon> Hi Ulrich, > in devnut_m3n the linker setup is severely broken. > I t is impossible to link a system without big code overhead. It looks > like both, stdlib and nutos wrappers, are linked into the system. Are you shure that this is a problem of the devnut_m3n in general or just a problem with the STM32 implementation / Linker scripts? With the LPC1788 implementation I compiled my little test program (some blinking LEDs) and it just has 3K of size, not more than a few weeks ago. On the other hand there are no references to the nutcrt right now. AFAIK Uwe modified the STM32 linker scripts not long ago. Have you just looked at the different segments (arm-none-eabi-objdump -h yourfile.elf) to see which segment growed that much? Are you sure you used the same toolchain than before? Bye, Ole -- Thermotemp GmbH, Embedded-IT Embedded Hard-/ Software and Open Source Development, Integration and Consulting http://www.embedded-it.de Gesch?ftsstelle Siegen - Steinstra?e 67 - D-57072 Siegen - tel +49 (0)271 5513597, +49 (0)271-73681 - fax +49 (0)271 736 97 Hauptsitz - Hademarscher Weg 7 - 13503 Berlin Tel +49 (0)30 4315205 - Fax +49 (0)30 43665002 Gesch?ftsf?hrer: J?rg Friedrichs, Ole Reinhardt Handelsregister Berlin Charlottenburg HRB 45978 UstID DE 156329280 From ole.reinhardt at embedded-it.de Wed Feb 1 17:14:39 2012 From: ole.reinhardt at embedded-it.de (Ole Reinhardt) Date: Wed, 01 Feb 2012 17:14:39 +0100 Subject: [En-Nut-Discussion] devnut_m3n branch linker severely broken? In-Reply-To: References: Message-ID: <1328112879.2090.35.camel@platon> Hi Ulrich, > in devnut_m3n the linker setup is severely broken. > I t is impossible to link a system without big code overhead. It looks > like both, stdlib and nutos wrappers, are linked into the system. I just did further testing and compiled the "simple.c" demo for the AT91 platform which results in 11K!!! Might that be a general Nut/OS problem? Any unused dependencies? bye, Ole -- Thermotemp GmbH, Embedded-IT Embedded Hard-/ Software and Open Source Development, Integration and Consulting http://www.embedded-it.de Gesch?ftsstelle Siegen - Steinstra?e 67 - D-57072 Siegen - tel +49 (0)271 5513597, +49 (0)271-73681 - fax +49 (0)271 736 97 Hauptsitz - Hademarscher Weg 7 - 13503 Berlin Tel +49 (0)30 4315205 - Fax +49 (0)30 43665002 Gesch?ftsf?hrer: J?rg Friedrichs, Ole Reinhardt Handelsregister Berlin Charlottenburg HRB 45978 UstID DE 156329280 From bon at elektron.ikp.physik.tu-darmstadt.de Wed Feb 1 17:43:49 2012 From: bon at elektron.ikp.physik.tu-darmstadt.de (Uwe Bonnes) Date: Wed, 1 Feb 2012 17:43:49 +0100 Subject: [En-Nut-Discussion] devnut_m3n branch linker severely broken? In-Reply-To: <1328112639.2090.32.camel@platon> References: <1328112639.2090.32.camel@platon> Message-ID: <20265.27589.342884.65068@elektron.ikp.physik.tu-darmstadt.de> >>>>> "Ole" == Ole Reinhardt writes: Ole> Hi Ulrich, >> in devnut_m3n the linker setup is severely broken. I t is impossible >> to link a system without big code overhead. It looks like both, >> stdlib and nutos wrappers, are linked into the system. Ole> Are you shure that this is a problem of the devnut_m3n in general Ole> or just a problem with the STM32 implementation / Linker scripts? Ole> With the LPC1788 implementation I compiled my little test program Ole> (some blinking LEDs) and it just has 3K of size, not more than a Ole> few weeks ago. Ole> On the other hand there are no references to the nutcrt right now. Ole> AFAIK Uwe modified the STM32 linker scripts not long ago. At least the SVN log says that I didn't touch stm32f10x_flash.ld. Last change was r3523 | astralix | 2011-07-20 23:01:23 +0200 (Mi, 20. Jul 2011) | 1 Zeile Ge?nderte Pfade: M /branches/devnut_m3n/nut/arch/cm3/ldscripts/stm32f10x_flash.ld Thx Uwe: fixed linking fail with gcc > 4.5.1 toolchains. Bye -- Uwe Bonnes bon at elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- From ole.reinhardt at embedded-it.de Thu Feb 2 10:17:17 2012 From: ole.reinhardt at embedded-it.de (Ole Reinhardt) Date: Thu, 02 Feb 2012 10:17:17 +0100 Subject: [En-Nut-Discussion] Anybody on Embedded World 2012? Message-ID: <1328174237.2086.12.camel@platon> Hi all, just to be the first, I'm curious if anybody (beside of Egnite :-) will be on the Embedded World this year. Perhaps we could meet again? Right now I plan to be there at 28.02 or 29.02.2012 Bye, Ole -- Thermotemp GmbH, Embedded-IT Embedded Hard-/ Software and Open Source Development, Integration and Consulting http://www.embedded-it.de Gesch?ftsstelle Siegen - Steinstra?e 67 - D-57072 Siegen - tel +49 (0)271 5513597, +49 (0)271-73681 - fax +49 (0)271 736 97 Hauptsitz - Hademarscher Weg 7 - 13503 Berlin Tel +49 (0)30 4315205 - Fax +49 (0)30 43665002 Gesch?ftsf?hrer: J?rg Friedrichs, Ole Reinhardt Handelsregister Berlin Charlottenburg HRB 45978 UstID DE 156329280 From bon at elektron.ikp.physik.tu-darmstadt.de Thu Feb 2 10:51:42 2012 From: bon at elektron.ikp.physik.tu-darmstadt.de (Uwe Bonnes) Date: Thu, 2 Feb 2012 10:51:42 +0100 Subject: [En-Nut-Discussion] Anybody on Embedded World 2012? In-Reply-To: <1328174237.2086.12.camel@platon> References: <1328174237.2086.12.camel@platon> Message-ID: <20266.23726.4377.606481@elektron.ikp.physik.tu-darmstadt.de> >>>>> "Ole" == Ole Reinhardt writes: Ole> Hi all, just to be the first, I'm curious if anybody (beside of Ole> Egnite :-) will be on the Embedded World this year. Ole> Perhaps we could meet again? Ole> Right now I plan to be there at 28.02 or 29.02.2012 I plan to go one of those both days too. Bye -- Uwe Bonnes bon at elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- From ulrich.prinz at googlemail.com Thu Feb 2 14:44:37 2012 From: ulrich.prinz at googlemail.com (Ulrich Prinz) Date: Thu, 2 Feb 2012 14:44:37 +0100 Subject: [En-Nut-Discussion] devnut_m3n branch linker severely broken? In-Reply-To: <1328112639.2090.32.camel@platon> References: <1328112639.2090.32.camel@platon> Message-ID: Hi Ole, yes I am on the same toolchain, just updated nutos to 3726. Looks like libnutc and libc got some unusual interconnections. If I exclude one, I get missing memcpy/memchr/... and if I exclude the other, I get missing _sbrk_r and others and additionally the code size grows again about 6k. So the thing insists on loading libnutc and libc... No idea why. I tested both toolchains, yagarto with gcc 4.6.0 on Windows and eCross on Linux. Same results. Ulrich From markus.dost at dr-clauss.de Mon Feb 6 11:12:22 2012 From: markus.dost at dr-clauss.de (Markus Dost) Date: Mon, 6 Feb 2012 11:12:22 +0100 Subject: [En-Nut-Discussion] Ethernut 2.1, httpd-app: size of the .hex-file Message-ID: <881197B3-A14F-4F7F-AD1D-990132B8A50A@dr-clauss.de> Hi, I have a problem with the Ethernut 2.1-board, which is maybe trivial: I configured the OS for the board with an ATmega128 and compiled the httpd-app. The building worked fine, but the size of the .hex-file is about 260 KB. This is too large for program memory of the controller, so I wonder whether this is a normal code size or something went wrong. Best regards, Markus From harald.kipp at egnite.de Mon Feb 6 12:06:56 2012 From: harald.kipp at egnite.de (Harald Kipp) Date: Mon, 06 Feb 2012 12:06:56 +0100 Subject: [En-Nut-Discussion] Ethernut 2.1, httpd-app: size of the .hex-file In-Reply-To: <881197B3-A14F-4F7F-AD1D-990132B8A50A@dr-clauss.de> References: <881197B3-A14F-4F7F-AD1D-990132B8A50A@dr-clauss.de> Message-ID: <4F2FB450.1040005@egnite.de> Hi Markus, On 06.02.2012 11:12, Markus Dost wrote: > I configured the OS for the board with an ATmega128 and compiled the > httpd-app. The building worked fine, but the size of the .hex-file is > about 260 KB. This is too large for program memory of the controller, > so I wonder whether this is a normal code size or something went wrong. The hex file contains ASCII format, each byte is coded in two ASCII characters. http://en.wikipedia.org/wiki/Intel_hex Therefore, it is at least twice as large as the binary code. In addition, the hex file contains addresses, checksums, CR/LF and more. How large is httpserv.bin? This file contains the pure flash image. Regards, Harald From markus.dost at dr-clauss.de Mon Feb 6 12:22:42 2012 From: markus.dost at dr-clauss.de (Markus Dost) Date: Mon, 6 Feb 2012 12:22:42 +0100 Subject: [En-Nut-Discussion] Ethernut 2.1, httpd-app: size of the .hex-file In-Reply-To: <4F2FB450.1040005@egnite.de> References: <881197B3-A14F-4F7F-AD1D-990132B8A50A@dr-clauss.de> <4F2FB450.1040005@egnite.de> Message-ID: Hi Harald, thanks for your answer. Until now, I had develop AVR-projects only in the AVR-Studio which told me the memory usage after compiling. So I didn't care about the hex-file :-) The size of my .bin-File is 93 KB and the last memory adress in the .hex-file ist 10730. So everything should be fine ^^. Best regards, Markus Am 06.02.2012 um 12:06 schrieb Harald Kipp: > Hi Markus, > > On 06.02.2012 11:12, Markus Dost wrote: >> I configured the OS for the board with an ATmega128 and compiled the >> httpd-app. The building worked fine, but the size of the .hex-file is >> about 260 KB. This is too large for program memory of the controller, >> so I wonder whether this is a normal code size or something went >> wrong. > > The hex file contains ASCII format, each byte is coded in two ASCII > characters. > > http://en.wikipedia.org/wiki/Intel_hex > > Therefore, it is at least twice as large as the binary code. In > addition, the hex file contains addresses, checksums, CR/LF and more. > > How large is httpserv.bin? This file contains the pure flash image. > > Regards, > > Harald > _______________________________________________ > http://lists.egnite.de/mailman/listinfo/en-nut-discussion From bon at elektron.ikp.physik.tu-darmstadt.de Mon Feb 6 12:52:06 2012 From: bon at elektron.ikp.physik.tu-darmstadt.de (Uwe Bonnes) Date: Mon, 6 Feb 2012 12:52:06 +0100 Subject: [En-Nut-Discussion] Ethernut 2.1, httpd-app: size of the .hex-file In-Reply-To: References: <881197B3-A14F-4F7F-AD1D-990132B8A50A@dr-clauss.de> <4F2FB450.1040005@egnite.de> Message-ID: <20271.48870.255532.166297@elektron.ikp.physik.tu-darmstadt.de> >>>>> "Markus" == Markus Dost writes: Markus> Hi Harald, thanks for your answer. Until now, I had develop Markus> AVR-projects only in the AVR-Studio which told me the memory Markus> usage after compiling. So I didn't care about the hex-file :-) For e.g. AVR, use avr-size for that purpose. -- Uwe Bonnes bon at elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- From ole.reinhardt at embedded-it.de Mon Feb 6 23:19:26 2012 From: ole.reinhardt at embedded-it.de (Ole Reinhardt) Date: Mon, 06 Feb 2012 23:19:26 +0100 Subject: [En-Nut-Discussion] Strange newlib syscall dependencies / linker problems when using 64bit integers Message-ID: <1328566767.2181.11.camel@platon> Hi all, in one special situation I need to use a 64bit devision on a Cortex M3. Compiling works fine, but the linker trows the following problems: arm-eCross-eabi-gcc test.o -mcpu=cortex-m3 -mthumb -mlittle-endian -D__CORTEX__ -nostartfiles -L/home/ole/work/Streamit/NutOS_M3N/nut/arch/cm3/ldscripts -Tlpc1778_flash.ld -Wl,-Map=uart.map,--cref,--gc-sections -L/home/ole/work/Streamit/nut-build-lpc177x_8x/lib -Wl,--start-group /home/ole/work/Streamit/nut-build-lpc177x_8x/lib/nutinit.o -lnutcrt -lnutarch -lnutdev -lnutos -lnutdev -lnutarch -Wl,--end-group -o uart.elf /opt/arm-eCross-eabi/bin/../lib/gcc/arm-eCross-eabi/4.5.2/../../../../arm-eCross-eabi/lib/thumb/v7m/libc.a(lib_a-abort.o): In function `abort': /home/ole/work/eCross/newlib-build/arm-eCross-eabi/thumb/v7m/newlib/libc/stdlib/../../../../../../../src/newlib-1.19.0/newlib/libc/stdlib/abort.c:63: undefined reference to `_exit' /opt/arm-eCross-eabi/bin/../lib/gcc/arm-eCross-eabi/4.5.2/../../../../arm-eCross-eabi/lib/thumb/v7m/libc.a(lib_a-signalr.o): In function `_kill_r': /home/ole/work/eCross/newlib-build/arm-eCross-eabi/thumb/v7m/newlib/libc/reent/../../../../../../../src/newlib-1.19.0/newlib/libc/reent/signalr.c:61: undefined reference to `_kill' /opt/arm-eCross-eabi/bin/../lib/gcc/arm-eCross-eabi/4.5.2/../../../../arm-eCross-eabi/lib/thumb/v7m/libc.a(lib_a-signalr.o): In function `_getpid_r': /home/ole/work/eCross/newlib-build/arm-eCross-eabi/thumb/v7m/newlib/libc/reent/../../../../../../../src/newlib-1.19.0/newlib/libc/reent/signalr.c:96: undefined reference to `_getpid' /opt/arm-eCross-eabi/bin/../lib/gcc/arm-eCross-eabi/4.5.2/../../../../arm-eCross-eabi/lib/thumb/v7m/libc.a(lib_a-sbrkr.o): In function `_sbrk_r': /home/ole/work/eCross/newlib-build/arm-eCross-eabi/thumb/v7m/newlib/libc/reent/../../../../../../../src/newlib-1.19.0/newlib/libc/reent/sbrkr.c:60: undefined reference to `_sbrk' collect2: ld returned 1 exit status The program itself looks like this: #include int main() { uint64_t *a,b; volatile uint64_t c; a = 0xaa000aa00; b= 0xaa00aa0000550055; c = b/(*a); if (c < 100) return 1; while(1); return 0; } Btw: defining a as pointer is just a trick to trick the optimizer (which eliminates constant calculations) Beside the above problem the linker complained about overlapping sections .data with (implicit?) segments ARM.extab ad ARN.exidx I fixed this by adding the requested segments (see part of the lpc17xx_flash.ld linker script below): .text : { . = ALIGN(4); _svect = .; KEEP(*(.isr_vector)) _evect = .; *(.text .text.* .gnu.linkonce.t.*) *(.rodata .rodata* .gnu.linkonce.r.*) *(.glue_7t) *(.glue_7) *(.gcc_except_table) . = ALIGN(4); /* _etext = .;*/ } > FLASH0 /* for exception handling/unwind - some Newlib functions (in common with C++ and STDC++) use this. */ .ARM.extab : { *(.ARM.extab* .gnu.linkonce.armextab.*) } > FLASH0 __exidx_start = .; .ARM.exidx : { *(.ARM.exidx* .gnu.linkonce.armexidx.*) } > FLASH0 __exidx_end = .; _etext = .; .vtable (NOLOAD): { . = ALIGN(4); _vtable = .; *(.vtable*) . = ALIGN(4); _evtable = .; } > SRAM0 Does anybody has an idea of what is going wrong here? Best regards, Ole Reinhardt -- Thermotemp GmbH, Embedded-IT Embedded Hard-/ Software and Open Source Development, Integration and Consulting http://www.embedded-it.de Gesch?ftsstelle Siegen - Steinstra?e 67 - D-57072 Siegen - tel +49 (0)271 5513597, +49 (0)271-73681 - fax +49 (0)271 736 97 Hauptsitz - Hademarscher Weg 7 - 13503 Berlin Tel +49 (0)30 4315205 - Fax +49 (0)30 43665002 Gesch?ftsf?hrer: J?rg Friedrichs, Ole Reinhardt Handelsregister Berlin Charlottenburg HRB 45978 UstID DE 156329280 From thiago.correa at gmail.com Tue Feb 7 00:11:42 2012 From: thiago.correa at gmail.com (=?ISO-8859-1?Q?Thiago_A=2E_Corr=EAa?=) Date: Mon, 6 Feb 2012 21:11:42 -0200 Subject: [En-Nut-Discussion] Anybody on Embedded World 2012? In-Reply-To: <1328174237.2086.12.camel@platon> References: <1328174237.2086.12.camel@platon> Message-ID: Hi, On Thu, Feb 2, 2012 at 7:17 AM, Ole Reinhardt wrote: > Hi all, > > just to be the first, I'm curious if anybody (beside of Egnite :-) will > be on the Embedded World this year. > > Perhaps we could meet again? > > Right now I plan to be there at 28.02 or 29.02.2012 > I wish I could keep up the trend I was going, visiting the Embedded World every 2 years, but this year I won't be able to. I hope Egnite will have a good return on the event this year so they can be there next year as well :) From ulrich.prinz at googlemail.com Tue Feb 7 16:41:48 2012 From: ulrich.prinz at googlemail.com (Ulrich Prinz) Date: Tue, 7 Feb 2012 16:41:48 +0100 Subject: [En-Nut-Discussion] Strange newlib syscall dependencies / linker problems when using 64bit integers In-Reply-To: <1328566767.2181.11.camel@platon> References: <1328566767.2181.11.camel@platon> Message-ID: Hi Ole, I never had this kind of problem, but I never used 64 bit variables... But... I compared the local nut/os version for cortexM3 with the sourceforge one and the only bigger difference is the double -L parameter for the linker. You remember the problem I have that building a simple uart example results in 14k code instead of 6k or less in older versions? I guess (but didn't test, cause lack of time) that this might be the problem. Can you test again with LDFLAGS = ...-T'path/to/linker/ldscript.ld' ... -L'path_to_libs' instead of LDFLAGS = ... -L'path/to/linker/' -T'ldscript.ld' ... -L'path_to_libs' It's just a feeling... Linker might test the first search path only and include stdlibs on failing result even the nutos libs exist in the second one. If it is still needed to have the linker scripts in search path, we could reorder the parameters and test again: LDFLAGS = ... -L'path_to_libs' ... -L'path/to/linker/' -T'ldscript.ld' Ulrich Am 6. Februar 2012 23:19 schrieb Ole Reinhardt : > Hi all, > > in one special situation I need to use a 64bit devision on a Cortex M3. > Compiling works fine, but the linker trows the following problems: > > arm-eCross-eabi-gcc test.o -mcpu=cortex-m3 -mthumb -mlittle-endian > -D__CORTEX__ -nostartfiles > -L/home/ole/work/Streamit/NutOS_M3N/nut/arch/cm3/ldscripts > -Tlpc1778_flash.ld -Wl,-Map=uart.map,--cref,--gc-sections > -L/home/ole/work/Streamit/nut-build-lpc177x_8x/lib > -Wl,--start-group /home/ole/work/Streamit/nut-build-lpc177x_8x/lib/nutinit.o -lnutcrt -lnutarch -lnutdev -lnutos -lnutdev -lnutarch ? -Wl,--end-group -o uart.elf > /opt/arm-eCross-eabi/bin/../lib/gcc/arm-eCross-eabi/4.5.2/../../../../arm-eCross-eabi/lib/thumb/v7m/libc.a(lib_a-abort.o): In function `abort': > /home/ole/work/eCross/newlib-build/arm-eCross-eabi/thumb/v7m/newlib/libc/stdlib/../../../../../../../src/newlib-1.19.0/newlib/libc/stdlib/abort.c:63: undefined reference to `_exit' > /opt/arm-eCross-eabi/bin/../lib/gcc/arm-eCross-eabi/4.5.2/../../../../arm-eCross-eabi/lib/thumb/v7m/libc.a(lib_a-signalr.o): In function `_kill_r': > /home/ole/work/eCross/newlib-build/arm-eCross-eabi/thumb/v7m/newlib/libc/reent/../../../../../../../src/newlib-1.19.0/newlib/libc/reent/signalr.c:61: undefined reference to `_kill' > /opt/arm-eCross-eabi/bin/../lib/gcc/arm-eCross-eabi/4.5.2/../../../../arm-eCross-eabi/lib/thumb/v7m/libc.a(lib_a-signalr.o): In function `_getpid_r': > /home/ole/work/eCross/newlib-build/arm-eCross-eabi/thumb/v7m/newlib/libc/reent/../../../../../../../src/newlib-1.19.0/newlib/libc/reent/signalr.c:96: undefined reference to `_getpid' > /opt/arm-eCross-eabi/bin/../lib/gcc/arm-eCross-eabi/4.5.2/../../../../arm-eCross-eabi/lib/thumb/v7m/libc.a(lib_a-sbrkr.o): In function `_sbrk_r': > /home/ole/work/eCross/newlib-build/arm-eCross-eabi/thumb/v7m/newlib/libc/reent/../../../../../../../src/newlib-1.19.0/newlib/libc/reent/sbrkr.c:60: undefined reference to `_sbrk' > collect2: ld returned 1 exit status > > > The program itself looks like this: > > #include > int main() > { > ? ?uint64_t *a,b; > ? ?volatile uint64_t c; > ? ?a = 0xaa000aa00; > > ? ?b= 0xaa00aa0000550055; > > ? ?c = b/(*a); > > ? ?if (c < 100) return 1; > > ? ?while(1); > ? ?return 0; > } > > Btw: defining a as pointer is just a trick to trick the optimizer (which > eliminates constant calculations) > > > Beside the above problem the linker complained about overlapping > sections .data with (implicit?) segments ARM.extab ad ARN.exidx > > I fixed this by adding the requested segments (see part of the > lpc17xx_flash.ld linker script below): > > ? .text : > ? ?{ > ? ? ? ?. = ALIGN(4); > ? ? ? ?_svect = .; > ? ? ? ?KEEP(*(.isr_vector)) > ? ? ? ?_evect = .; > ? ? ? ?*(.text .text.* .gnu.linkonce.t.*) > ? ? ? ?*(.rodata .rodata* .gnu.linkonce.r.*) > ? ? ? ?*(.glue_7t) > ? ? ? ?*(.glue_7) > ? ? ? ?*(.gcc_except_table) > ? ? ? ? ? ?. = ALIGN(4); > /* ? ? ? ?_etext = .;*/ > ? ?} > FLASH0 > > ? ?/* for exception handling/unwind - some Newlib functions (in common > with C++ and STDC++) use this. */ > > ? ?.ARM.extab : > ? ?{ > ? ? ? ?*(.ARM.extab* .gnu.linkonce.armextab.*) > ? ?} > ?FLASH0 > > ? ?__exidx_start = .; > ? ?.ARM.exidx : > ? ?{ > ? ? ? ?*(.ARM.exidx* .gnu.linkonce.armexidx.*) > ? ?} > ?FLASH0 > ? ?__exidx_end = .; > > ? ?_etext = .; > > ? ?.vtable (NOLOAD): > ? ?{ > ? ? ? ?. = ALIGN(4); > ? ? ? ? ? ?_vtable = .; > ? ? ? ? ? ?*(.vtable*) > ? ? ? ?. = ALIGN(4); > ? ? ? ? ? ?_evtable = .; > ? ?} > SRAM0 > > > Does anybody has an idea of what is going wrong here? > > Best regards, > > Ole Reinhardt > > -- > > Thermotemp GmbH, Embedded-IT > > Embedded Hard-/ Software and Open Source Development, > Integration and Consulting > > http://www.embedded-it.de > > Gesch?ftsstelle Siegen - Steinstra?e 67 - D-57072 Siegen - > tel +49 (0)271 5513597, +49 (0)271-73681 - fax +49 (0)271 736 97 > > Hauptsitz - Hademarscher Weg 7 - 13503 Berlin > Tel +49 (0)30 4315205 - Fax +49 (0)30 43665002 > Gesch?ftsf?hrer: J?rg Friedrichs, Ole Reinhardt > Handelsregister Berlin Charlottenburg HRB 45978 UstID DE 156329280 > > _______________________________________________ > http://lists.egnite.de/mailman/listinfo/en-nut-discussion From bon at elektron.ikp.physik.tu-darmstadt.de Tue Feb 7 17:40:19 2012 From: bon at elektron.ikp.physik.tu-darmstadt.de (Uwe Bonnes) Date: Tue, 7 Feb 2012 17:40:19 +0100 Subject: [En-Nut-Discussion] Strange newlib syscall dependencies / linker problems when using 64bit integers In-Reply-To: References: <1328566767.2181.11.camel@platon> Message-ID: <20273.21491.975139.994432@elektron.ikp.physik.tu-darmstadt.de> >>>>> "Ulrich" == Ulrich Prinz writes: Ulrich> Hi Ole, I never had this kind of problem, but I never used 64 Ulrich> bit variables... Ulrich> But... I compared the local nut/os version for cortexM3 with the Ulrich> sourceforge one and the only bigger difference is the double -L Ulrich> parameter for the linker. You remember the problem I have that Ulrich> building a simple uart example results in 14k code instead of 6k Ulrich> or less in older versions? I guess (but didn't test, cause lack Ulrich> of time) that this might be the problem. Ulrich> Can you test again with LDFLAGS = Ulrich> ...-T'path/to/linker/ldscript.ld' ... -L'path_to_libs' instead Ulrich> of LDFLAGS = ... -L'path/to/linker/' -T'ldscript.ld' Ulrich> ... -L'path_to_libs' Ulrich> It's just a feeling... Linker might test the first search path Ulrich> only and include stdlibs on failing result even the nutos libs Ulrich> exist in the second one. The order doesn't seem to make a difference: * Order as produced by our tree: arm-none-eabi-gcc owi_test.o owi_timer.o -mcpu=cortex-m3 -mthumb -mlittle-endian -D__CORTEX__ -nostartfiles -L../../../devnut_m3n_git/nut/arch/cm3/ldscripts -Tstm32f107xC_flash.ld -Wl,-Map=owi_test.map,--cref,--gc-sections -L../.././lib -Wl,--start-group ../.././lib/nutinit.o -lnutcrt -lnutarch -lnutdev -lnutos -lnutdev -lnutarch -Wl,--end-group -o owi_test.elf > arm-none-eabi-size owi_test.elf text data bss dec hex filename 24296 320 1380 25996 658c owi_test.elf * All linker specific files at the end: > arm-none-eabi-gcc owi_test.o owi_timer.o -mcpu=cortex-m3 -mthumb -mlittle-endian -D__CORTEX__ -nostartfiles -L../.././lib ../.././lib/nutinit.o -lnutcrt -lnutarch -lnutdev -lnutos -lnutdev -lnutarch -nostartfiles -L../../../devnut_m3n_git/nut/arch/cm3/ldscripts -Tstm32f107xC_flash.ld -Wl,-Map=owi_test.map,--cref,--gc-sections -Wl,--start-group -Wl,--end-group -o owi_test.elf > arm-none-eabi-size owi_test.elf text data bss dec hex filename 24296 320 1380 25996 658c owi_test.elf -- Uwe Bonnes bon at elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- From markus.dost at dr-clauss.de Wed Feb 8 07:39:51 2012 From: markus.dost at dr-clauss.de (Markus Dost) Date: Wed, 8 Feb 2012 07:39:51 +0100 Subject: [En-Nut-Discussion] Ethernut 2 + MMC Message-ID: <09CEBDA4-62FB-4FCA-B254-1EF3A3DCFD64@dr-clauss.de> Hi, did somebody used the MMC-functions with an ATmega128? In the Wiki and the Configurator it is written that the device drivers have been tested only for the AT91. Best regards, Markus From ole.reinhardt at embedded-it.de Wed Feb 8 13:15:10 2012 From: ole.reinhardt at embedded-it.de (Ole Reinhardt) Date: Wed, 08 Feb 2012 13:15:10 +0100 Subject: [En-Nut-Discussion] Strange newlib syscall dependencies / linker problems when using 64bit integers In-Reply-To: <20273.21491.975139.994432@elektron.ikp.physik.tu-darmstadt.de> References: <1328566767.2181.11.camel@platon> <20273.21491.975139.994432@elektron.ikp.physik.tu-darmstadt.de> Message-ID: <1328703310.2167.5.camel@platon> Hi! > The order doesn't seem to make a difference: Right. And the described problem does not depend on the linked libs (i tried several combinations). The simple divide test program even did not need any lib linked at all, does it? What I found out so far is that gcc implements the division by using a function "idiv" or similar, which itself depends on these syscalls to be implemented. In fact this does not rely to your problem at all. So I think we have two disjunct problems here. I just found another thread on microcontroller.net describing the same problem (but on a different platform) but their solition (to implement the newlib syscall stubs) is not really satisfying in the Nut/OS environment... What do you think? Where would you implement these syscall stubs (most of these functions just return 0, only sbrk_r has to be correctly implemented) Bye, Ole -- Thermotemp GmbH, Embedded-IT Embedded Hard-/ Software and Open Source Development, Integration and Consulting http://www.embedded-it.de Gesch?ftsstelle Siegen - Steinstra?e 67 - D-57072 Siegen - tel +49 (0)271 5513597, +49 (0)271-73681 - fax +49 (0)271 736 97 Hauptsitz - Hademarscher Weg 7 - 13503 Berlin Tel +49 (0)30 4315205 - Fax +49 (0)30 43665002 Gesch?ftsf?hrer: J?rg Friedrichs, Ole Reinhardt Handelsregister Berlin Charlottenburg HRB 45978 UstID DE 156329280 From bon at elektron.ikp.physik.tu-darmstadt.de Wed Feb 8 13:20:55 2012 From: bon at elektron.ikp.physik.tu-darmstadt.de (Uwe Bonnes) Date: Wed, 8 Feb 2012 13:20:55 +0100 Subject: [En-Nut-Discussion] Strange newlib syscall dependencies / linker problems when using 64bit integers In-Reply-To: <1328703310.2167.5.camel@platon> References: <1328566767.2181.11.camel@platon> <20273.21491.975139.994432@elektron.ikp.physik.tu-darmstadt.de> <1328703310.2167.5.camel@platon> Message-ID: <20274.26791.136327.58886@elektron.ikp.physik.tu-darmstadt.de> >>>>> "Ole" == Ole Reinhardt writes: ... Ole> I just found another thread on microcontroller.net describing the Ole> same problem (but on a different platform) but their solition (to Ole> implement the newlib syscall stubs) is not really satisfying in the Ole> Nut/OS environment... Can you give a link to that thread? Thanks -- Uwe Bonnes bon at elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- From ulrich.prinz at googlemail.com Wed Feb 8 13:46:32 2012 From: ulrich.prinz at googlemail.com (Ulrich Prinz) Date: Wed, 8 Feb 2012 13:46:32 +0100 Subject: [En-Nut-Discussion] Strange newlib syscall dependencies / linker problems when using 64bit integers In-Reply-To: <20273.21491.975139.994432@elektron.ikp.physik.tu-darmstadt.de> References: <1328566767.2181.11.camel@platon> <20273.21491.975139.994432@elektron.ikp.physik.tu-darmstadt.de> Message-ID: Got a part of it: in app/Makevars.cm3-gcc the linker lines where disabled. If you add back the line LDFLAGS = $(MCFLAGS) -nostartfiles -T$(LDSCRIPT) -Wl,-Map=$(PROJ).map,--cref,--gc-sections -L$(LIBDIR) it works without the overhead. For latest version it must be modified to LDPATH and LDNAME. Might be that you have to run 'Create Sampledirectory' from qnutconf again to apply the modification to the nutconf.mk files. Creating a local project without this modification results in a binary image of 90k, with patch applied it is 85k. Bootloader without patch is 14850 bytes, with patch applied it is 8252 bytes. Ulrich Am 7. Februar 2012 17:40 schrieb Uwe Bonnes : >>>>>> "Ulrich" == Ulrich Prinz writes: > > ? ?Ulrich> Hi Ole, I never had this kind of problem, but I never used 64 > ? ?Ulrich> bit variables... > > ? ?Ulrich> But... I compared the local nut/os version for cortexM3 with the > ? ?Ulrich> sourceforge one and the only bigger difference is the double -L > ? ?Ulrich> parameter for the linker. ?You remember the problem I have that > ? ?Ulrich> building a simple uart example results in 14k code instead of 6k > ? ?Ulrich> or less in older versions? ?I guess (but didn't test, cause lack > ? ?Ulrich> of time) that this might be the problem. > > ? ?Ulrich> Can you test again with LDFLAGS = > ? ?Ulrich> ...-T'path/to/linker/ldscript.ld' ... -L'path_to_libs' instead > ? ?Ulrich> of LDFLAGS = ... -L'path/to/linker/' -T'ldscript.ld' > ? ?Ulrich> ... -L'path_to_libs' > > ? ?Ulrich> It's just a feeling... ?Linker might test the first search path > ? ?Ulrich> only and include stdlibs on failing result even the nutos libs > ? ?Ulrich> exist in the second one. > > > > The order doesn't seem to make a difference: > * Order as produced by our tree: > > arm-none-eabi-gcc owi_test.o owi_timer.o -mcpu=cortex-m3 -mthumb -mlittle-endian -D__CORTEX__ -nostartfiles -L../../../devnut_m3n_git/nut/arch/cm3/ldscripts -Tstm32f107xC_flash.ld -Wl,-Map=owi_test.map,--cref,--gc-sections -L../.././lib -Wl,--start-group ../.././lib/nutinit.o -lnutcrt -lnutarch -lnutdev -lnutos -lnutdev -lnutarch ? -Wl,--end-group -o owi_test.elf > ?> arm-none-eabi-size owi_test.elf > ? text ? ?data ? ? bss ? ? dec ? ? hex filename > ?24296 ? ? 320 ? ?1380 ? 25996 ? ?658c owi_test.elf > > * All linker specific files at the end: >> arm-none-eabi-gcc owi_test.o owi_timer.o -mcpu=cortex-m3 -mthumb -mlittle-endian -D__CORTEX__ -nostartfiles -L../.././lib ../.././lib/nutinit.o -lnutcrt -lnutarch -lnutdev -lnutos -lnutdev -lnutarch -nostartfiles -L../../../devnut_m3n_git/nut/arch/cm3/ldscripts -Tstm32f107xC_flash.ld -Wl,-Map=owi_test.map,--cref,--gc-sections -Wl,--start-group -Wl,--end-group -o owi_test.elf > >> arm-none-eabi-size owi_test.elf > ?text ? ?data ? ? bss ? ? dec ? ? hex filename > ?24296 ? ? 320 ? ?1380 ? 25996 ? ?658c owi_test.elf > > -- > Uwe Bonnes ? ? ? ? ? ? ? ?bon at elektron.ikp.physik.tu-darmstadt.de > > Institut fuer Kernphysik ?Schlossgartenstrasse 9 ?64289 Darmstadt > --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- > _______________________________________________ > http://lists.egnite.de/mailman/listinfo/en-nut-discussion From bon at elektron.ikp.physik.tu-darmstadt.de Wed Feb 8 14:49:19 2012 From: bon at elektron.ikp.physik.tu-darmstadt.de (Uwe Bonnes) Date: Wed, 8 Feb 2012 14:49:19 +0100 Subject: [En-Nut-Discussion] Strange newlib syscall dependencies / linker problems when using 64bit integers In-Reply-To: References: <1328566767.2181.11.camel@platon> <20273.21491.975139.994432@elektron.ikp.physik.tu-darmstadt.de> Message-ID: <20274.32095.606195.13954@elektron.ikp.physik.tu-darmstadt.de> >>>>> "Ulrich" == Ulrich Prinz writes: Ulrich> Got a part of it: in app/Makevars.cm3-gcc the linker lines where Ulrich> disabled. If you add back the line LDFLAGS = $(MCFLAGS) Ulrich> -nostartfiles -T$(LDSCRIPT) Ulrich> -Wl,-Map=$(PROJ).map,--cref,--gc-sections -L$(LIBDIR) it works Ulrich> without the overhead. Ulrich> For latest version it must be modified to LDPATH and LDNAME. Ulrich> Might be that you have to run 'Create Sampledirectory' from Ulrich> qnutconf again to apply the modification to the nutconf.mk Ulrich> files. Ulrich> Creating a local project without this modification results in a Ulrich> binary image of 90k, with patch applied it is 85k. Bootloader Ulrich> without patch is 14850 bytes, with patch applied it is 8252 Ulrich> bytes. Ulrich, what exactly is missing from the command arm-none-eabi-gcc owi_test.o owi_timer.o -mcpu=cortex-m4 -mthumb -mlittle-endian -D__CORTEX__ -nostartfiles -L../../../devnut_m3n_git/nut/arch/cm3/ldscripts -Tstm32f405xG_ram.ld -Wl,-Map=owi_test.map,--cref,--gc-sections -L../.././lib -Wl,--start-group ../.././lib/nutinit.o -lnutcrt -lnutarch -lnutdev -lnutos -lnutdev -lnutarch -Wl,--end-group -o owi_test.elf as produced by devnut_m3n-SVN? Bye -- Uwe Bonnes bon at elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- From ulrich.prinz at googlemail.com Wed Feb 8 14:59:48 2012 From: ulrich.prinz at googlemail.com (Ulrich Prinz) Date: Wed, 8 Feb 2012 14:59:48 +0100 Subject: [En-Nut-Discussion] Feature Request: Create Application Directory" for (q)nutconf Message-ID: Hi all! If you develop with nutos and use (q)nutconf you like to press the button 'Create Sample Directory' and have your build system set up in the given directory. But if you develop lots of your own projects you might not like to have all the examples installed. This gets even more disturbing if you implement new architectures and have to add and change nut/app/Make*.* files that are used to create the needed NutConf.mk and others in the top application directory. With every 'Create Sample Directory' call the examples are reinstalled. So I guess it could help to add and sort the Build->xxx menu like this: 1) Create/Update Application Directory 2) Copy Examples to Application Directory Option 1 only creates or updates the given application directory Option 2 calls optionn 1 and then additionally copies over all non existing files from the nut/app directory. 3) Copy Hardware Testing Code There could be an Option 3 after we moved out the hardware driver test examples like eeprom, PCF expander and others that are very hardware dependent to a different directory. Option 3 then calls Option 1 and additionally copies all non existing files from that driver test directory to the application dir. How about that? Ulrich From ole.reinhardt at embedded-it.de Wed Feb 8 15:22:32 2012 From: ole.reinhardt at embedded-it.de (Ole Reinhardt) Date: Wed, 08 Feb 2012 15:22:32 +0100 Subject: [En-Nut-Discussion] Strange newlib syscall dependencies / linker problems when using 64bit integers In-Reply-To: <20274.26791.136327.58886@elektron.ikp.physik.tu-darmstadt.de> References: <1328566767.2181.11.camel@platon> <20273.21491.975139.994432@elektron.ikp.physik.tu-darmstadt.de> <1328703310.2167.5.camel@platon> <20274.26791.136327.58886@elektron.ikp.physik.tu-darmstadt.de> Message-ID: <1328710952.2167.19.camel@platon> Hi Uwe, > Can you give a link to that thread? here it is: http://embdev.net/topic/129607 It's the english version of microcontroller.net Btw: It's no problem of cortex but also shows on other platforms as you read in the thread (they use a ARM7) bye, Ole -- Thermotemp GmbH, Embedded-IT Embedded Hard-/ Software and Open Source Development, Integration and Consulting http://www.embedded-it.de Gesch?ftsstelle Siegen - Steinstra?e 67 - D-57072 Siegen - tel +49 (0)271 5513597, +49 (0)271-73681 - fax +49 (0)271 736 97 Hauptsitz - Hademarscher Weg 7 - 13503 Berlin Tel +49 (0)30 4315205 - Fax +49 (0)30 43665002 Gesch?ftsf?hrer: J?rg Friedrichs, Ole Reinhardt Handelsregister Berlin Charlottenburg HRB 45978 UstID DE 156329280 From ole.reinhardt at embedded-it.de Wed Feb 8 15:25:01 2012 From: ole.reinhardt at embedded-it.de (Ole Reinhardt) Date: Wed, 08 Feb 2012 15:25:01 +0100 Subject: [En-Nut-Discussion] Ethernut 2 + MMC In-Reply-To: <09CEBDA4-62FB-4FCA-B254-1EF3A3DCFD64@dr-clauss.de> References: <09CEBDA4-62FB-4FCA-B254-1EF3A3DCFD64@dr-clauss.de> Message-ID: <1328711101.2167.21.camel@platon> Hi Markus, > did somebody used the MMC-functions with an ATmega128? In the Wiki and > the Configurator it is written that the device drivers have been > tested only for the AT91. Sure, it is available on every Ethernut 1.3 and 2.x board... Can you please give me a link, where it is written that it's only tested on the AT91 platform? There are several different MMC drivers available. Perhaps you looked at the AT91 driver? Bye, Ole -- Thermotemp GmbH, Embedded-IT Embedded Hard-/ Software and Open Source Development, Integration and Consulting http://www.embedded-it.de Gesch?ftsstelle Siegen - Steinstra?e 67 - D-57072 Siegen - tel +49 (0)271 5513597, +49 (0)271-73681 - fax +49 (0)271 736 97 Hauptsitz - Hademarscher Weg 7 - 13503 Berlin Tel +49 (0)30 4315205 - Fax +49 (0)30 43665002 Gesch?ftsf?hrer: J?rg Friedrichs, Ole Reinhardt Handelsregister Berlin Charlottenburg HRB 45978 UstID DE 156329280 From ole.reinhardt at embedded-it.de Wed Feb 8 15:52:40 2012 From: ole.reinhardt at embedded-it.de (Ole Reinhardt) Date: Wed, 08 Feb 2012 15:52:40 +0100 Subject: [En-Nut-Discussion] Feature Request: Create Application Directory" for (q)nutconf In-Reply-To: References: Message-ID: <1328712760.2167.51.camel@platon> Hi Ulrich, > But if you develop lots of your own projects you might not like to > have all the examples installed. Yes, I well know this problem. I personally prefer to have a pre-compiled Nut/OS and to use just a few simple makefiles with my application, not all this directory hirarchy. Especialy when deploying Nut/OS as development environment for a board your customers won't ever compile Nut/OS by their own but just use the ready build libraries. So what I would suggest is to add an "Install Nut/OS" which would build the libraries, install it into a folder and add the necessary makefiles (just the ones for your compiler setting) As an example see http://www.embedded-it.de/bsp-download/webserver_relais_demo.tar.gz (folder Nut/OS) I also modified the application standard makefiles to refer to the pre-installed ones. Another idea: This install button could also copy the header files so that one would not have to install the whole source tree too. Bye, Ole -- Thermotemp GmbH, Embedded-IT Embedded Hard-/ Software and Open Source Development, Integration and Consulting http://www.embedded-it.de Gesch?ftsstelle Siegen - Steinstra?e 67 - D-57072 Siegen - tel +49 (0)271 5513597, +49 (0)271-73681 - fax +49 (0)271 736 97 Hauptsitz - Hademarscher Weg 7 - 13503 Berlin Tel +49 (0)30 4315205 - Fax +49 (0)30 43665002 Gesch?ftsf?hrer: J?rg Friedrichs, Ole Reinhardt Handelsregister Berlin Charlottenburg HRB 45978 UstID DE 156329280 From info at pragmalab.nl Wed Feb 8 22:10:31 2012 From: info at pragmalab.nl (PragmaLab (Rob van Lieshout)) Date: Wed, 8 Feb 2012 22:10:31 +0100 Subject: [En-Nut-Discussion] Ethernut 2 + MMC In-Reply-To: References: Message-ID: <010b01cce6a6$173ff990$45bfecb0$@nl> >did somebody used the MMC-functions with an ATmega128? In the Wiki and >the Configurator it is written that the device drivers have been >tested only for the AT91. Hi Markus, Do you mean the MMCard module? That's used for SD-cards as well, and yes, we used it with ATmega128 and ATmega256. Works fine. Be aware that it depends on a low-level block device driver for the actual communication. Regards, Rob van Lieshout From markus.dost at dr-clauss.de Thu Feb 9 08:58:26 2012 From: markus.dost at dr-clauss.de (Markus Dost) Date: Thu, 9 Feb 2012 08:58:26 +0100 Subject: [En-Nut-Discussion] Ethernut 5 + Eclipse tutorial Message-ID: <70E051BE-4CD4-48C1-81D3-8AEC4A889653@dr-clauss.de> Hi, I have the next question/problem. I want to pass the tutorial to build and debug applications with the Ethernut 5 and the Eclipse IDE: http://www.ethernut.de/en/hardware/enut5/debugging.html But when I want to build the project, Eclipse puts out "Cannot run program "make" ". I have no idea, what I've made wrong. The path- variable for yargarto is set correctly. When I try to build the application with the cmd.exe and the command "make all", it works. Best regards, Markus From hmnews at proconx.com Fri Feb 10 06:39:44 2012 From: hmnews at proconx.com (Henrik Maier) Date: Fri, 10 Feb 2012 15:39:44 +1000 Subject: [En-Nut-Discussion] Possible race condition in DHCP and DHCPKick Message-ID: <4F34ADA0.3070002@proconx.com> Hi all, it appears that there is a race condition in DHCP, routine DhcpKick(): I observed cases where the following sequence would cause a system lock-up because the NutEventWait/dhcpDone condition is never fullfilled. Some debugging and analysis of the order of events sent and received between the caller and DHCP thread shows, that there are cases where NutEventPost does a context switch and the dhcpDone event is sent before(!) NutEventWait(&dhcpDone) is called resulting the subsequent call of NutEventWait(&dhcpDone) to never return. ... NutEventPost(&dhcpWake); NutEventWait(&dhcpDone, NUT_WAIT_INFINITE); ... The issue seems to be fixed once above NutEventPost is changed to a NutEventPostAsync which avoids the context switch before NutEventWait is called: ... NutEventPostAsync(&dhcpWake); NutEventWait(&dhcpDone, NUT_WAIT_INFINITE); ... If there are no objections or further insight into this topic, I would submit a bug report to tracker and a patch. I think in most applications DhcpKick is only called once during system start and the issue does not come up. But if a system changes from DHCP to statically allocated IP addresses or vice versa, DhcpKick is called on every change and the issue comes to surface. Regards Henrik Maier From bon at elektron.ikp.physik.tu-darmstadt.de Fri Feb 10 10:56:09 2012 From: bon at elektron.ikp.physik.tu-darmstadt.de (Uwe Bonnes) Date: Fri, 10 Feb 2012 10:56:09 +0100 Subject: [En-Nut-Discussion] branches\devnut_m3n and STM32F2 devices In-Reply-To: References: Message-ID: <20276.59833.948122.425414@elektron.ikp.physik.tu-darmstadt.de> >>>>> "Guillaume" == Guillaume Fortaine writes: Guillaume> Dear Mister Bonnes, Mister Prinz, and Mister Maier First of Guillaume> all, I would like to wish you and the people around you an Guillaume> happy new year. Guillaume> Let me introduce myself : Guillaume FORTAINE, Cloudpreneur : Guillaume> http://www.linkedin.com/in/gfortaine Guillaume> I have read with interest the discussion entitled Guillaume> "branches\devnut_m3n and STM32F2 devices" [0]. Given that Guillaume> there is an Ethernet design available around the STM32 F-2, I Guillaume> would greatly appreciate to know if you plan to port the Guillaume> Ethernut project to it, if possible, please : In my personal git tree, I have the basic devices somehow working with STM32L and STM32F1/2/4. I will commit my changes hopefully soon. Why a local git tree: It allows to edit older commits and so try and error will not result in a tons of commit. But no work on the yet unsupported/ partial supported devices has been done... Bye -- Uwe Bonnes bon at elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- From harald.kipp at egnite.de Sat Feb 11 12:12:09 2012 From: harald.kipp at egnite.de (Harald Kipp) Date: Sat, 11 Feb 2012 12:12:09 +0100 Subject: [En-Nut-Discussion] Ethernut 5 + Eclipse tutorial In-Reply-To: <70E051BE-4CD4-48C1-81D3-8AEC4A889653@dr-clauss.de> References: <70E051BE-4CD4-48C1-81D3-8AEC4A889653@dr-clauss.de> Message-ID: <4F364D09.9020602@egnite.de> Hi Markus, On 09.02.2012 08:58, Markus Dost wrote: > I have the next question/problem. I want to pass the tutorial to build > and debug applications with the Ethernut 5 and the Eclipse IDE: > http://www.ethernut.de/en/hardware/enut5/debugging.html Please note, that I recently added an updated, more general guide http://www.ethernut.de/en/tools/eclipse/ > But when I want to build the project, Eclipse puts out "Cannot run > program "make" ". I have no idea, what I've made wrong. The path- > variable for yargarto is set correctly. Guess, your PC is running Windows. You need to add the path to x:\ethernut-x.y\nut\tools\win32 http://www.ethernut.de/img/indigo-project-prop-build-env.png Hope, this helps, Harald From ole.reinhardt at embedded-it.de Sat Feb 11 17:20:50 2012 From: ole.reinhardt at embedded-it.de (Ole Reinhardt) Date: Sat, 11 Feb 2012 17:20:50 +0100 Subject: [En-Nut-Discussion] Possible race condition in DHCP and DHCPKick In-Reply-To: <4F34ADA0.3070002@proconx.com> References: <4F34ADA0.3070002@proconx.com> Message-ID: <1328977250.2984.17.camel@platon> Hi Henrik, I just looked into the code and for me it seems very likely that this race condition can occur. The problem can occur, as the dhcp code often first signals dhcpDone and waits then for a wake which might result in a race condition. But shouldn't we change the other places as well: multiple times in NutDhcpClient() ... NutEventBroadcast(&dhcpDone); NutEventWait(&dhcpWake, NUT_WAIT_INFINITE); ... To ... mutiple time: NutEventBroadcastAsync(&dhcpDone); NutEventWait(&dhcpWake, NUT_WAIT_INFINITE); ... And another more complex situation: else if (dhcpState == DHCPST_BOUND) { retries = 0; NutEventBroadcast(&dhcpDone); if (dhcpConfig->dyn_renewalTime <= NutGetSeconds() - leaseTime) { dhcpState = DHCPST_RENEWING; } else { /* Calculate the remaining lease time and take a nap. */ napTime = dhcpConfig->dyn_renewalTime - (NutGetSeconds() - leaseTime); if (napTime > MAX_DHCP_NAPTIME) { napTime = MAX_DHCP_NAPTIME; } NutEventWait(&dhcpWake, napTime * 1000UL); } } to else if (dhcpState == DHCPST_BOUND) { uint32_t now = NutGetSeconds(); retries = 0; NutEventBroadcastAsync(&dhcpDone); if (dhcpConfig->dyn_renewalTime <= now - leaseTime) { dhcpState = DHCPST_RENEWING; } else { /* Calculate the remaining lease time and take a nap. */ napTime = dhcpConfig->dyn_renewalTime - (now - leaseTime); if (napTime > MAX_DHCP_NAPTIME) { napTime = MAX_DHCP_NAPTIME; } NutEventWait(&dhcpWake, napTime * 1000UL); } } The above is more complex as NutGetSeconds also could result in a context switch. Regards, Ole -- Thermotemp GmbH, Embedded-IT Embedded Hard-/ Software and Open Source Development, Integration and Consulting http://www.embedded-it.de Gesch?ftsstelle Siegen - Steinstra?e 67 - D-57072 Siegen - tel +49 (0)271 5513597, +49 (0)271-73681 - fax +49 (0)271 736 97 Hauptsitz - Hademarscher Weg 7 - 13503 Berlin Tel +49 (0)30 4315205 - Fax +49 (0)30 43665002 Gesch?ftsf?hrer: J?rg Friedrichs, Ole Reinhardt Handelsregister Berlin Charlottenburg HRB 45978 UstID DE 156329280 From ulrich.prinz at googlemail.com Sun Feb 12 12:30:57 2012 From: ulrich.prinz at googlemail.com (Ulrich Prinz) Date: Sun, 12 Feb 2012 12:30:57 +0100 Subject: [En-Nut-Discussion] Feature Request: Create Application Directory" for (q)nutconf In-Reply-To: <1328712760.2167.51.camel@platon> References: <1328712760.2167.51.camel@platon> Message-ID: <4F37A2F1.1060302@googlemail.com> Hi! At first the separation of directory and makefile generation from creation of all examples would be very helpfull. To add an option that enables to export all libraries and headers and creates a set of working application makefiles is very fine. We often need to keep nut/os libraries synced with the application source code to be able to reproduce avery single software release. So if we could export the libraries and headers in parallel with the applications it would be very handy for checking them in to SVN or GIT. Ulrich Am 08.02.2012 15:52, schrieb Ole Reinhardt: > Hi Ulrich, > >> But if you develop lots of your own projects you might not like to >> have all the examples installed. > > Yes, I well know this problem. I personally prefer to have a > pre-compiled Nut/OS and to use just a few simple makefiles with my > application, not all this directory hirarchy. > > Especialy when deploying Nut/OS as development environment for a board > your customers won't ever compile Nut/OS by their own but just use the > ready build libraries. > > So what I would suggest is to add an "Install Nut/OS" which would build > the libraries, install it into a folder and add the necessary makefiles > (just the ones for your compiler setting) > > As an example see > > http://www.embedded-it.de/bsp-download/webserver_relais_demo.tar.gz > > (folder Nut/OS) > > I also modified the application standard makefiles to refer to the > pre-installed ones. > > Another idea: > > This install button could also copy the header files so that one would > not have to install the whole source tree too. > > Bye, > > Ole > > From ulrich.prinz at googlemail.com Sun Feb 12 12:47:54 2012 From: ulrich.prinz at googlemail.com (Ulrich Prinz) Date: Sun, 12 Feb 2012 12:47:54 +0100 Subject: [En-Nut-Discussion] Possible race condition in DHCP and DHCPKick In-Reply-To: <1328977250.2984.17.camel@platon> References: <4F34ADA0.3070002@proconx.com> <1328977250.2984.17.camel@platon> Message-ID: <4F37A6EA.20003@googlemail.com> Hi! I will forward this to Daniel, a colleague of me who implements STM32F107 EMAC actually. He did a lot testing/designing from bottom up through the OSI model and fixed some other places too. He also implemented my idea of phy.c. Am 11.02.2012 17:20, schrieb Ole Reinhardt: > Hi Henrik, > > > > And another more complex situation: > > > else if (dhcpState == DHCPST_BOUND) { > retries = 0; > NutEventBroadcast(&dhcpDone); > if (dhcpConfig->dyn_renewalTime <= NutGetSeconds() - > leaseTime) { > dhcpState = DHCPST_RENEWING; > } else { > /* Calculate the remaining lease time and take a nap. */ > napTime = dhcpConfig->dyn_renewalTime - (NutGetSeconds() > - leaseTime); > if (napTime > MAX_DHCP_NAPTIME) { > napTime = MAX_DHCP_NAPTIME; > } > NutEventWait(&dhcpWake, napTime * 1000UL); > } > } > > to > > else if (dhcpState == DHCPST_BOUND) { > uint32_t now = NutGetSeconds(); > retries = 0; > NutEventBroadcastAsync(&dhcpDone); > if (dhcpConfig->dyn_renewalTime <= now - leaseTime) { > dhcpState = DHCPST_RENEWING; > } else { > /* Calculate the remaining lease time and take a nap. */ > napTime = dhcpConfig->dyn_renewalTime - (now - > leaseTime); > if (napTime > MAX_DHCP_NAPTIME) { > napTime = MAX_DHCP_NAPTIME; > } > NutEventWait(&dhcpWake, napTime * 1000UL); > } > } > > The above is more complex as NutGetSeconds also could result in a > context switch. Isn't it more reliably to redesign dhcp into an active and a passive part. The active part can work with post/wait and simply offers a current_state variable like dhcpState. If DHCP_BOUND or DHCP_TOUT is reached it goes to sleep and wait for a restart-event. The passive part only uses nutsleep(1000) and polls dhcpState for spreading needed actions onto the stack and, if needed, wakes the active thread above. In that case only one thread is receiver and one is sender of an event. If in that situation an event of the active part is missed by the passive part, the next revolution of the passive part will get it. With that no race conditions can occur anymore. Ulrich From ole.reinhardt at embedded-it.de Sun Feb 12 19:00:01 2012 From: ole.reinhardt at embedded-it.de (Ole Reinhardt) Date: Sun, 12 Feb 2012 19:00:01 +0100 Subject: [En-Nut-Discussion] Possible race condition in DHCP and DHCPKick In-Reply-To: <4F37A6EA.20003@googlemail.com> References: <4F34ADA0.3070002@proconx.com> <1328977250.2984.17.camel@platon> <4F37A6EA.20003@googlemail.com> Message-ID: <1329069601.2501.16.camel@platon> Hi! > Isn't it more reliably to redesign dhcp into an active and a passive > part. The active part can work with post/wait and simply offers a > current_state variable like dhcpState. > If DHCP_BOUND or DHCP_TOUT is reached it goes to sleep and wait for a > restart-event. Good Idea! Please go ahead! (Or your college :) I just looked over the code without taking a redesign into account. As the DHCP part made several problems in the past a redesign might be the better choice. bye, Ole -- Thermotemp GmbH, Embedded-IT Embedded Hard-/ Software and Open Source Development, Integration and Consulting http://www.embedded-it.de Gesch?ftsstelle Siegen - Steinstra?e 67 - D-57072 Siegen - tel +49 (0)271 5513597, +49 (0)271-73681 - fax +49 (0)271 736 97 Hauptsitz - Hademarscher Weg 7 - 13503 Berlin Tel +49 (0)30 4315205 - Fax +49 (0)30 43665002 Gesch?ftsf?hrer: J?rg Friedrichs, Ole Reinhardt Handelsregister Berlin Charlottenburg HRB 45978 UstID DE 156329280 From ulrich.prinz at googlemail.com Sun Feb 12 18:55:15 2012 From: ulrich.prinz at googlemail.com (Ulrich Prinz) Date: Sun, 12 Feb 2012 18:55:15 +0100 Subject: [En-Nut-Discussion] Anybody on Embedded World 2012? In-Reply-To: <1328174237.2086.12.camel@platon> References: <1328174237.2086.12.camel@platon> Message-ID: <4F37FD03.7080309@googlemail.com> Hi! Some of my colleagues and I plan to go there, but a date has not been fixed. CeBit is right after that and we need to be prepared to show up there shortly on request. So I will write a date when the car is ordered :) Ulrich Am 02.02.2012 10:17, schrieb Ole Reinhardt: > Hi all, > > just to be the first, I'm curious if anybody (beside of Egnite :-) will > be on the Embedded World this year. > > Perhaps we could meet again? > > Right now I plan to be there at 28.02 or 29.02.2012 > > Bye, > > Ole > From markus.dost at dr-clauss.de Mon Feb 13 09:02:11 2012 From: markus.dost at dr-clauss.de (Markus Dost) Date: Mon, 13 Feb 2012 09:02:11 +0100 Subject: [En-Nut-Discussion] Ethernut 5 + Eclipse tutorial In-Reply-To: <4F364D09.9020602@egnite.de> References: <70E051BE-4CD4-48C1-81D3-8AEC4A889653@dr-clauss.de> <4F364D09.9020602@egnite.de> Message-ID: Hi Harald Am 11.02.2012 um 12:12 schrieb Harald Kipp: >> But when I want to build the project, Eclipse puts out "Cannot run >> program "make" ". I have no idea, what I've made wrong. The path- >> variable for yargarto is set correctly. > > Guess, your PC is running Windows. You need to add the path to > > x:\ethernut-x.y\nut\tools\win32 > > http://www.ethernut.de/img/indigo-project-prop-build-env.png I did that. Additional the WinAVR-package is installed and added to the path-variable, too. So eclipse should find the make.exe twice. Best regards, Markus From joerg.wiegelmann at gmx.de Mon Feb 13 21:20:37 2012 From: joerg.wiegelmann at gmx.de (Joerg Wiegelmann) Date: Mon, 13 Feb 2012 21:20:37 +0100 Subject: [En-Nut-Discussion] Atmega 2561with more than 128k code and Winavr Message-ID: <4F397095.3020708@gmx.de> Hey folks, I would like to use the atmega2561 with more than 128kByte code. When I compile my application I got a bunch of linking errors like: D:/nut/nutbld/lib\libnutarch.a(usart0avr.o):(.data+0x6c): warning: internal error: out of range error D:/nut/nutbld/lib\libnutarch.a(usart0avr.o):(.data+0x6e): warning: internal error: out of range error Does anyone has an idea? Does anyone work with more than 128kByte code and Winavr? Compiler gcc version 4.3.3 (WinAVR 20100110), NutOS Version 4.10, Windows system. Thanks Joerg From bon at elektron.ikp.physik.tu-darmstadt.de Mon Feb 13 23:32:55 2012 From: bon at elektron.ikp.physik.tu-darmstadt.de (Uwe Bonnes) Date: Mon, 13 Feb 2012 23:32:55 +0100 Subject: [En-Nut-Discussion] Atmega 2561with more than 128k code and Winavr In-Reply-To: <4F397095.3020708@gmx.de> References: <4F397095.3020708@gmx.de> Message-ID: <20281.36759.32008.174174@elektron.ikp.physik.tu-darmstadt.de> >>>>> "Joerg" == Joerg Wiegelmann writes: Joerg> Hey folks, I would like to use the atmega2561 with more than Joerg> 128kByte code. When I compile my application I got a bunch of Joerg> linking errors like: Joerg> D:/nut/nutbld/lib\libnutarch.a(usart0avr.o):(.data+0x6c): Joerg> warning: internal error: out of range error Joerg> D:/nut/nutbld/lib\libnutarch.a(usart0avr.o):(.data+0x6e): Joerg> warning: internal error: out of range error Does anyone has an Joerg> idea? Does anyone work with more than 128kByte code and Winavr? Joerg> Compiler gcc version 4.3.3 (WinAVR 20100110), NutOS Version 4.10, Joerg> Windows system. I think, gcc has problems with AVR and CODE bigger than 128 k. -- Uwe Bonnes bon at elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- From guillaume.fortaine at devopspace.com Tue Feb 14 04:14:16 2012 From: guillaume.fortaine at devopspace.com (Guillaume Fortaine) Date: Tue, 14 Feb 2012 04:14:16 +0100 Subject: [En-Nut-Discussion] Fwd: Thermotemp : eNet sam3X In-Reply-To: References: Message-ID: ---------- Forwarded message ---------- From: Guillaume Fortaine Date: Sat, Feb 11, 2012 at 9:16 PM Subject: Thermotemp : eNet sam3X To: ole.reinhardt at embedded-it.de Cc: Henrik Maier , Ulrich Prinz , bon at elektron.ikp.physik.tu-darmstadt.de Dear Mister Reinhardt, First of all, I would like to wish you and the people around you an happy new year. Let me introduce myself : Guillaume FORTAINE, Cloudpreneur : http://www.linkedin.com/in/gfortaine Having seen with interest the news about your eNet sam3X ?project, I would greatly appreciate to have more informations about it, if possible, please. To quote [0] : "01.03.2011 Cortex M3 version of the module sam7X eNet-planned! from Q3/Q4 2011 is a version of the Cortex M3-sam7X eNet module will be available. The eNet sam3X-module course is pin compatible and is based on the Atmel CPU Sam3X! First engineering samples will be available shortly" Especially, ?I would greatly appreciate to know how it compares against : -ST Cortex M3 STM32F207 Development Board Ethernet USB Device/Host CAN [1] -etherarm [2] : "This hardware is similar in concept to the Maple hardware from leaf labs. The reason for diverging from their approach is to use the LM3S series of Cortex-M3 processors from TI; the particular processor selected features an integrated Ethernet MAC and PHY providing Ethernet without requiring an additional external PHY." By the way, do you plan a devnut_m3n Ethernut branch port for it [3] ? "devnut_m3n branch of the SVN ethernut tree, used for housekeeping." I look forward to your answer, Best Regards, [0] http://embedded-it.de/ [1] http://www.ebay.com/itm/ws/eBayISAPI.dll?ViewItem&item=190638488534 [2] http://code.google.com/p/etherarm/ [3] https://github.com/UweBonnes/devnut_m3n -- Guillaume FORTAINE guillaume.fortaine at devopspace.com DevOpSpace http://www.devopspace.com +33(0)631.092.519 From guillaume.fortaine at devopspace.com Tue Feb 14 04:15:11 2012 From: guillaume.fortaine at devopspace.com (Guillaume Fortaine) Date: Tue, 14 Feb 2012 04:15:11 +0100 Subject: [En-Nut-Discussion] Fwd: Nut/Net (was Re: branches\devnut_m3n and STM32F2 devices) In-Reply-To: References: Message-ID: ---------- Forwarded message ---------- From: Guillaume Fortaine Date: Sat, Feb 11, 2012 at 9:36 PM Subject: Nut/Net (was Re: branches\devnut_m3n and STM32F2 devices) To: Henrik Maier Cc: Ulrich Prinz , bon at elektron.ikp.physik.tu-darmstadt.de, ole.reinhardt at embedded-it.de Dear Mister Maier, Thank you for your comprehensive reply. > I would suggest to shift this discussion into the Nut/Os mailing list rather > continuing it as private mail. The topic raised by Guillaume should be > discussed more broadly in the Nut/Os community. I am fine with this statement and I have just subscribed to the "En-Nut-Discussion" mailing-list : http://lists.egnite.de/mailman/listinfo/en-nut-discussion > Guillaume, you also mention ChibiOS in your mail. But we are talking about > Nut/OS here, a very different OS which for example does not require lwIP and > offers a far superior TCP/IP stack than lwIP. I would greatly appreciate that you develop your comment, if possible, please. Especially, could you provide any benchmark ? http://lists.gnu.org/archive/html/lwip-users/2011-11/msg00071.html "In fact, I have developed ftp server with lwIP, it works well enough ..and support FlashFXP and FileZilla utility. The download speed is 200KB/s and upload speed is 40KB/s in my Cortex M3 with spi flash AT45DB321D." By the way, from my point of view, Nut/Net has two main critical drawbacks : -No IPv6 support : http://www.ethernut.de/nutwiki/Nut/OS_Roadmap#IPv6 "I recently looked into Adam Dunkels' uIP again, which supports IPv6. To me it doesn't look complicated. Quite the contrary, as it is limited to single layer only and a few variables. As a first action, I'd suggest to add it to the feature request list at SourceForge." *lwIP supports IPv6 : http://git.savannah.gnu.org/cgit/lwip.git/tree/CHANGELOG "2011-05-17: Patch by Ivan Delamer (only checked in by Simon Goldschmidt) ?* nearly the whole stack: Finally, we got decent IPv6 support, big thanks to ? Ivan! (this is work in progress: we're just post release anyway :-)" -Nut/Net is not easily portable : http://embedded-source.blogspot.com/2010/01/nutos.html "Nut/Net is designed for Nut/OS and not easy to port to other OS because it uses many Nut/OS specific calls." *lwIP has been ported to many RTOS : http://lwip.wikia.com/wiki/Projects_that_use_lwIP -FreeRTOS : http://www.freertos.org/portsam7xlwIP.html "lwIP Embedded Web Server Demo" -RT-Thread : http://code.google.com/p/rt-thread/wiki/Lwip_140_MigrationGuide "lwip1.4 Migration Guide" -ChibiOS/RT : http://www.chibios.org/dokuwiki/doku.php "Support for external components uIP, lwIP, FatFs." -tmos : http://code.google.com/p/tmos/source/browse/trunk/tmos/services/#services%2Flwip-1.4.0.rc1 "lwip-1.4.0.rc1" I look forward to your answer, Best Regards, -- Guillaume FORTAINE guillaume.fortaine at devopspace.com DevOpSpace http://www.devopspace.com +33(0)631.092.519 On Sat, Feb 11, 2012 at 12:42 AM, Henrik Maier wrote: > Hi all, > > I would suggest to shift this discussion into the Nut/Os mailing list rather > continuing it as private mail. The topic raised by Guillaume should be > discussed more broadly in the Nut/Os community. > > So please post questions and replies to the NutOS mailing list: > > ? ? ? ?en-nut-discussion at egnite.de > > Guillaume, you also mention ChibiOS in your mail. But we are talking about > Nut/OS here, a very different OS which for example does not require lwIP and > offers a far superior TCP/IP stack than lwIP. > > Regards > > Henrik Maier > > > On 11/02/2012 12:29 AM, Guillaume Fortaine wrote: >> >> Dear Mister Prinz, >> >> Thank you for your comprehensive reply. >> >> >>> I hope you understand that this cannot be our intention. >> >> >> I am fine with this statement. So do you plan to leverage the CMSIS >> RTOS API instead ? >> >> http://forum.chibios.org/phpbb/viewtopic.php?f=3&t=272 >> >> "Starting from version 3.0, CMSIS will define a specific RTOS API, the >> preview is already available here: >> >> http://www.onarm.com/cmsis/download/19/version-3-0-preview-of-the-cortex-microcontroller-software-interface-standard-cmsis/ >> >> This API will allow to design RTOS-independent components. My idea is >> to focus the kernel development after version 2.4.0 on providing a >> compliant API, the new API would wrap/supplement the normal ChibiOS >> API not replace it, I still think it is particularly efficient and >> elegant. >> >> This development is interesting because it will possible to design >> complex components (file systems, networking stacks) without have to >> use a vendor specific interface. For example a stack like lwIP could >> simply assume that API instead of defining its own RTOS wrapper." >> >> >> I look forward to your answer, >> >> Best Regards, >> >> -- >> Guillaume FORTAINE >> guillaume.fortaine at devopspace.com >> DevOpSpace >> http://www.devopspace.com >> +33(0)631.092.519 >> >> >> On Fri, Feb 10, 2012 at 2:37 PM, Ulrich Prinz >> ?wrote: >>> >>> Hello Guillaume, >>> >>> >>> I need to agree with Uwe Bonnes statement. The whole team put a lot of >>> energy to get STM32 and later other CortexM based CPUs working in a >>> system that can be used free for any hobby and commercial development. >>> The work we did can only be done cause we can use the results >>> commecially. Unfortunately GPL license is (as Texas Instrument calles >>> it) a virulent license. That means that adding code that is GPL often >>> requires additional code directly connected also has to be converted >>> to GPL too. So GPL eats up part by part all code of the system and >>> therefore makes it impossible to generate a commercial code. >>> >>> You might say that linux is used commercialy too and I agree as I do >>> this myself too. But it generates a lot of development to keep your >>> core knowledge and your own inventions apart from the GPL linux code. >>> But it is possible to do it as Linux offers enough standarized >>> connections for your software that you then keep secret. >>> >>> Nut/OS is a system optimized for extremely small controllers, hardly >>> or impossible to run (uc-)linux. So your application software can and >>> must connect more tight to the system to work fast and efficient. With >>> GPL applied you will be forced to open lots of your application code >>> to everyone. >>> >>> I hope you understand that this cannot be our intention. >>> >>> Best regards >>> Ulrich >>> >>> Am 10. Februar 2012 05:27 schrieb Henrik Maier: >>>> >>>> Hello Guillaume Fortaine, >>>> >>>> The libopencm3 is GPL and because of this not license compatible with >>>> Nut/OS >>>> and therefore cannot be used. I remember seeing discussions to change >>>> the >>>> license of libopencm3 to LGPL but this was rejected. >>>> >>>> See >>>> >>>> http://www.hermann-uwe.de/blog/libopenstm32-a-free-software-firmware-library-for-stm32-arm-cortex-m3-microcontrollers >>>> >>>> Best Regards >>>> >>>> Henrik Maier >>>> >>>> >>>> >>>> On 10/02/2012 12:58 PM, Guillaume Fortaine wrote: >>>>> >>>>> >>>>> Dear Mister Bonnes, Mister Prinz, and Mister Maier >>>>> >>>>> First of all, I would like to wish you and the people around you an >>>>> happy new year. >>>>> >>>>> Let me introduce myself : Guillaume FORTAINE, Cloudpreneur : >>>>> >>>>> http://www.linkedin.com/in/gfortaine >>>>> >>>>> I have read with interest the discussion entitled "branches\devnut_m3n >>>>> and STM32F2 devices" [0]. Given that there is an Ethernet design >>>>> available around the STM32 F-2, >>>>> I would greatly appreciate to know if you plan to port the Ethernut >>>>> project to it, if possible, please ?: >>>>> >>>>> http://cgi.ebay.fr/ws/eBayISAPI.dll?ViewItem&item=190638488534 >>>>> >>>>> "ST Cortex M3 STM32F207 Development Board Ethernet USB Device/Host CAN" >>>>> >>>>> >>>>> By the way, to quote [0] : >>>>> >>>>> "What I thought I do for now is to create an new subdir under >>>>> branches\devnut_m3n\arch\cm3\dev called stm32f2 which temporarily >>>>> holds the drivers I ported across from the stm directory. Once that >>>>> becomes all stable and working I can work with the other STM32F1 >>>>> developers to maybe merge those files into one driver set suitable for >>>>> F1, F2 and maybe even F4 devices. I like to avoid as much code >>>>> duplication as possible." >>>>> >>>>> >>>>> Wouldn't it be better to leverage the libopencm3 project ? >>>>> >>>>> http://libopencm3.org/ >>>>> >>>>> "The libopencm3 project (previously known as libopenstm32) aims to >>>>> create a free/libre/open-source (GPL v3, or later) firmware library >>>>> for various ARM Cortex-M3 microcontrollers, including ST STM32, >>>>> Toshiba TX03, Atmel SAM3U, NXP LPC1000 and others." >>>>> >>>>> >>>>> I look forward to your answer, >>>>> >>>>> Best Regards, >>>>> >>>>> [0] >>>>> >>>>> http://lists.egnite.de/pipermail/en-nut-discussion/2011-December/013183.html >>>>> >>>>> -- >>>>> Guillaume FORTAINE >>>>> guillaume.fortaine at devopspace.com >>>>> DevOpSpace >>>>> http://www.devopspace.com >>>>> +33(0)631.092.519 >>>>> >>>> >> > From guillaume.fortaine at devopspace.com Tue Feb 14 04:15:45 2012 From: guillaume.fortaine at devopspace.com (Guillaume Fortaine) Date: Tue, 14 Feb 2012 04:15:45 +0100 Subject: [En-Nut-Discussion] Fwd: Nut/OS BSD License (was Re: branches\devnut_m3n and STM32F2 devices) In-Reply-To: References: Message-ID: ---------- Forwarded message ---------- From: Guillaume Fortaine Date: Sat, Feb 11, 2012 at 9:41 PM Subject: Nut/OS BSD License (was Re: branches\devnut_m3n and STM32F2 devices) To: Ulrich Prinz Cc: Henrik Maier , bon at elektron.ikp.physik.tu-darmstadt.de, ole.reinhardt at embedded-it.de, Gareth McMullin , uwe at hermann-uwe.de, Piotr Esden-Tempski Dear Mister Prinz, Thank you for your comprehensive reply. > Unfortunately GPL license is (as Texas Instrument calles > it) a virulent license. That means that adding code that is GPL often > requires additional code directly connected also has to be converted > to GPL too. So GPL eats up part by part all code of the system and > therefore makes it impossible to generate a commercial code. I would greatly appreciate to invite you to a further reading of the article entitled "Opinion: License to FUD (comparing GPL and BSD)" : http://www.linuxfordevices.com/c/a/Linux-For-Devices-Articles/Opinion-License-to-FUD-comparing-GPL-and-BSD/ Best Regards, -- Guillaume FORTAINE guillaume.fortaine at devopspace.com DevOpSpace http://www.devopspace.com +33(0)631.092.519 On Fri, Feb 10, 2012 at 2:37 PM, Ulrich Prinz wrote: > Hello Guillaume, > > I need to agree with Uwe Bonnes statement. The whole team put a lot of > energy to get STM32 and later other CortexM based CPUs working in a > system that can be used free for any hobby and commercial development. > The work we did can only be done cause we can use the results > commecially. Unfortunately GPL license is (as Texas Instrument calles > it) a virulent license. That means that adding code that is GPL often > requires additional code directly connected also has to be converted > to GPL too. So GPL eats up part by part all code of the system and > therefore makes it impossible to generate a commercial code. > > You might say that linux is used commercialy too and I agree as I do > this myself too. But it generates a lot of development to keep your > core knowledge and your own inventions apart from the GPL linux code. > But it is possible to do it as Linux offers enough standarized > connections for your software that you then keep secret. > > Nut/OS is a system optimized for extremely small controllers, hardly > or impossible to run (uc-)linux. So your application software can and > must connect more tight to the system to work fast and efficient. With > GPL applied you will be forced to open lots of your application code > to everyone. > > I hope you understand that this cannot be our intention. > > Best regards > Ulrich > > Am 10. Februar 2012 05:27 schrieb Henrik Maier : >> Hello Guillaume Fortaine, >> >> The libopencm3 is GPL and because of this not license compatible with Nut/OS >> and therefore cannot be used. I remember seeing discussions to change the >> license of libopencm3 to LGPL but this was rejected. >> >> See >> http://www.hermann-uwe.de/blog/libopenstm32-a-free-software-firmware-library-for-stm32-arm-cortex-m3-microcontrollers >> >> Best Regards >> >> Henrik Maier >> >> >> >> On 10/02/2012 12:58 PM, Guillaume Fortaine wrote: >>> >>> Dear Mister Bonnes, Mister Prinz, and Mister Maier >>> >>> First of all, I would like to wish you and the people around you an >>> happy new year. >>> >>> Let me introduce myself : Guillaume FORTAINE, Cloudpreneur : >>> >>> http://www.linkedin.com/in/gfortaine >>> >>> I have read with interest the discussion entitled "branches\devnut_m3n >>> and STM32F2 devices" [0]. Given that there is an Ethernet design >>> available around the STM32 F-2, >>> I would greatly appreciate to know if you plan to port the Ethernut >>> project to it, if possible, please ?: >>> >>> http://cgi.ebay.fr/ws/eBayISAPI.dll?ViewItem&item=190638488534 >>> >>> "ST Cortex M3 STM32F207 Development Board Ethernet USB Device/Host CAN" >>> >>> >>> By the way, to quote [0] : >>> >>> "What I thought I do for now is to create an new subdir under >>> branches\devnut_m3n\arch\cm3\dev called stm32f2 which temporarily >>> holds the drivers I ported across from the stm directory. Once that >>> becomes all stable and working I can work with the other STM32F1 >>> developers to maybe merge those files into one driver set suitable for >>> F1, F2 and maybe even F4 devices. I like to avoid as much code >>> duplication as possible." >>> >>> >>> Wouldn't it be better to leverage the libopencm3 project ? >>> >>> http://libopencm3.org/ >>> >>> "The libopencm3 project (previously known as libopenstm32) aims to >>> create a free/libre/open-source (GPL v3, or later) firmware library >>> for various ARM Cortex-M3 microcontrollers, including ST STM32, >>> Toshiba TX03, Atmel SAM3U, NXP LPC1000 and others." >>> >>> >>> I look forward to your answer, >>> >>> Best Regards, >>> >>> [0] >>> http://lists.egnite.de/pipermail/en-nut-discussion/2011-December/013183.html >>> >>> -- >>> Guillaume FORTAINE >>> guillaume.fortaine at devopspace.com >>> DevOpSpace >>> http://www.devopspace.com >>> +33(0)631.092.519 >>> >> From nategoose at gmail.com Tue Feb 14 05:08:04 2012 From: nategoose at gmail.com (Nathan Moore) Date: Mon, 13 Feb 2012 23:08:04 -0500 Subject: [En-Nut-Discussion] Fwd: Nut/OS BSD License (was Re: branches\devnut_m3n and STM32F2 devices) In-Reply-To: References: Message-ID: Nut/OS links against the applications that run under it, while Linux loads applications at runtime and those applications use an API that the Linux developers/copyright holders have expressly stated that using this API (as well as some source code which is really just the system call numbers) will not cause the rest of the application to be required to be GPL. This amounts to an amendment to the GPL license that Linux uses. From hmnews at proconx.com Tue Feb 14 05:25:59 2012 From: hmnews at proconx.com (Henrik Maier) Date: Tue, 14 Feb 2012 14:25:59 +1000 Subject: [En-Nut-Discussion] Fwd: Nut/OS BSD License (was Re: branches\devnut_m3n and STM32F2 devices) In-Reply-To: References: Message-ID: <4F39E257.7000405@proconx.com> Hello Guillaume, In reference to the article you are referring to, the situation for an embedded OS which is linked is very different to an OS like Linux. It is possible to use GPLed Linux with closed source applications. But if Nut/OS would be GPL, it would not be possible to keep your application code closed source which some users may prefer for commercial reasons. I believe the reason that Nut/OS has a BSD license contributes to the fact that we have a large commercial user base. Henrik On 14/02/2012 1:15 PM, Guillaume Fortaine wrote: > I would greatly appreciate to invite you to a further reading of the > article entitled "Opinion: License to FUD (comparing GPL and BSD)" : > > http://www.linuxfordevices.com/c/a/Linux-For-Devices-Articles/Opinion-License-to-FUD-comparing-GPL-and-BSD/ > From hmnews at proconx.com Tue Feb 14 05:30:38 2012 From: hmnews at proconx.com (Henrik Maier) Date: Tue, 14 Feb 2012 14:30:38 +1000 Subject: [En-Nut-Discussion] Possible race condition in DHCP and DHCPKick In-Reply-To: <1329069601.2501.16.camel@platon> References: <4F34ADA0.3070002@proconx.com> <1328977250.2984.17.camel@platon> <4F37A6EA.20003@googlemail.com> <1329069601.2501.16.camel@platon> Message-ID: <4F39E36E.7070502@proconx.com> I thought about a redesign myself, but commercial pressure to get a project out of the door prohibits this at the moment. So I will apply only those fixes at the moment and see if more issues pop up. On 13/02/2012 4:00 AM, Ole Reinhardt wrote: > Hi! > >> Isn't it more reliably to redesign dhcp into an active and a passive >> part. The active part can work with post/wait and simply offers a >> current_state variable like dhcpState. >> If DHCP_BOUND or DHCP_TOUT is reached it goes to sleep and wait for a >> restart-event. > > Good Idea! Please go ahead! (Or your college :) > > I just looked over the code without taking a redesign into account. As > the DHCP part made several problems in the past a redesign might be the > better choice. > > bye, > > Ole > From hmnews at proconx.com Tue Feb 14 06:25:16 2012 From: hmnews at proconx.com (Henrik Maier) Date: Tue, 14 Feb 2012 15:25:16 +1000 Subject: [En-Nut-Discussion] Fwd: Nut/Net (was Re: branches\devnut_m3n and STM32F2 devices) In-Reply-To: References: Message-ID: <4F39F03C.6010600@proconx.com> Hello Guillaume, Sorry I cannot supply a benchmark and my comments were not related to speed but to the richness and elegance of the Nut/OS and Nut/NET API. Nut/OS offers more high level TCP protocols and more network drivers than lwIP. The fact that Nut/NET is tied to Nut/OS is not a disadvantage. Nut/NET was never meant to run on another OS. OS and TCP/IP stack have become one coherent system which is easier to learn and use than plugging two separate things together. As a result sockets can be used in a stream-like fashion for example to do fprintf on a TCP socket. The lack of IP6 may be a drawback for some users, but it is not critical for me at this stage. If you require IP6 support now, than Nut/OS may be not be suitable indeed and lwIP may be the better choice for you. Regards Henrik On 14/02/2012 1:15 PM, Guillaume Fortaine wrote: > ---------- Forwarded message ---------- > From: Guillaume Fortaine > > Dear Mister Maier, > > Thank you for your comprehensive reply. > > >> I would suggest to shift this discussion into the Nut/Os mailing list rather >> continuing it as private mail. The topic raised by Guillaume should be >> discussed more broadly in the Nut/Os community. > > I am fine with this statement and I have just subscribed to the > "En-Nut-Discussion" mailing-list : > > http://lists.egnite.de/mailman/listinfo/en-nut-discussion > > >> Guillaume, you also mention ChibiOS in your mail. But we are talking about >> Nut/OS here, a very different OS which for example does not require lwIP and >> offers a far superior TCP/IP stack than lwIP. > > I would greatly appreciate that you develop your comment, if possible, please. > > Especially, could you provide any benchmark ? > > http://lists.gnu.org/archive/html/lwip-users/2011-11/msg00071.html > > "In fact, I have developed ftp server with lwIP, it works well enough ..and > support FlashFXP and FileZilla utility. > The download speed is 200KB/s and upload speed is 40KB/s in my Cortex M3 with > spi flash AT45DB321D." > > > By the way, from my point of view, Nut/Net has two main critical drawbacks : > > -No IPv6 support : > > http://www.ethernut.de/nutwiki/Nut/OS_Roadmap#IPv6 > > "I recently looked into Adam Dunkels' uIP again, which supports IPv6. To > me it doesn't look complicated. Quite the contrary, as it is limited to > single layer only and a few variables. As a first action, I'd suggest to > add it to the feature request list at SourceForge." > > > *lwIP supports IPv6 : > > http://git.savannah.gnu.org/cgit/lwip.git/tree/CHANGELOG > > "2011-05-17: Patch by Ivan Delamer (only checked in by Simon Goldschmidt) > * nearly the whole stack: Finally, we got decent IPv6 support, big thanks to > Ivan! (this is work in progress: we're just post release anyway :-)" > > > -Nut/Net is not easily portable : > > http://embedded-source.blogspot.com/2010/01/nutos.html > > "Nut/Net is designed for Nut/OS and not easy to port to other OS > because it uses many Nut/OS specific calls." > > *lwIP has been ported to many RTOS : > > http://lwip.wikia.com/wiki/Projects_that_use_lwIP > > > -FreeRTOS : http://www.freertos.org/portsam7xlwIP.html > > "lwIP Embedded Web Server Demo" > > > -RT-Thread : http://code.google.com/p/rt-thread/wiki/Lwip_140_MigrationGuide > > "lwip1.4 Migration Guide" > > > -ChibiOS/RT : http://www.chibios.org/dokuwiki/doku.php > > "Support for external components uIP, lwIP, FatFs." > > > -tmos : http://code.google.com/p/tmos/source/browse/trunk/tmos/services/#services%2Flwip-1.4.0.rc1 > > "lwip-1.4.0.rc1" > > > I look forward to your answer, > > Best Regards, > > -- > Guillaume FORTAINE > guillaume.fortaine at devopspace.com > DevOpSpace > http://www.devopspace.com > +33(0)631.092.519 > > > On Sat, Feb 11, 2012 at 12:42 AM, Henrik Maier wrote: >> Hi all, >> >> I would suggest to shift this discussion into the Nut/Os mailing list rather >> continuing it as private mail. The topic raised by Guillaume should be >> discussed more broadly in the Nut/Os community. >> >> So please post questions and replies to the NutOS mailing list: >> >> en-nut-discussion at egnite.de >> >> Guillaume, you also mention ChibiOS in your mail. But we are talking about >> Nut/OS here, a very different OS which for example does not require lwIP and >> offers a far superior TCP/IP stack than lwIP. >> >> Regards >> >> Henrik Maier >> >> >> On 11/02/2012 12:29 AM, Guillaume Fortaine wrote: >>> >>> Dear Mister Prinz, >>> >>> Thank you for your comprehensive reply. >>> >>> >>>> I hope you understand that this cannot be our intention. >>> >>> >>> I am fine with this statement. So do you plan to leverage the CMSIS >>> RTOS API instead ? >>> >>> http://forum.chibios.org/phpbb/viewtopic.php?f=3&t=272 >>> >>> "Starting from version 3.0, CMSIS will define a specific RTOS API, the >>> preview is already available here: >>> >>> http://www.onarm.com/cmsis/download/19/version-3-0-preview-of-the-cortex-microcontroller-software-interface-standard-cmsis/ >>> >>> This API will allow to design RTOS-independent components. My idea is >>> to focus the kernel development after version 2.4.0 on providing a >>> compliant API, the new API would wrap/supplement the normal ChibiOS >>> API not replace it, I still think it is particularly efficient and >>> elegant. >>> >>> This development is interesting because it will possible to design >>> complex components (file systems, networking stacks) without have to >>> use a vendor specific interface. For example a stack like lwIP could >>> simply assume that API instead of defining its own RTOS wrapper." >>> >>> >>> I look forward to your answer, >>> >>> Best Regards, >>> >>> -- >>> Guillaume FORTAINE >>> guillaume.fortaine at devopspace.com >>> DevOpSpace >>> http://www.devopspace.com >>> +33(0)631.092.519 >>> >>> >>> On Fri, Feb 10, 2012 at 2:37 PM, Ulrich Prinz >>> wrote: >>>> >>>> Hello Guillaume, >>>> >>>> >>>> I need to agree with Uwe Bonnes statement. The whole team put a lot of >>>> energy to get STM32 and later other CortexM based CPUs working in a >>>> system that can be used free for any hobby and commercial development. >>>> The work we did can only be done cause we can use the results >>>> commecially. Unfortunately GPL license is (as Texas Instrument calles >>>> it) a virulent license. That means that adding code that is GPL often >>>> requires additional code directly connected also has to be converted >>>> to GPL too. So GPL eats up part by part all code of the system and >>>> therefore makes it impossible to generate a commercial code. >>>> >>>> You might say that linux is used commercialy too and I agree as I do >>>> this myself too. But it generates a lot of development to keep your >>>> core knowledge and your own inventions apart from the GPL linux code. >>>> But it is possible to do it as Linux offers enough standarized >>>> connections for your software that you then keep secret. >>>> >>>> Nut/OS is a system optimized for extremely small controllers, hardly >>>> or impossible to run (uc-)linux. So your application software can and >>>> must connect more tight to the system to work fast and efficient. With >>>> GPL applied you will be forced to open lots of your application code >>>> to everyone. >>>> >>>> I hope you understand that this cannot be our intention. >>>> >>>> Best regards >>>> Ulrich >>>> >>>> Am 10. Februar 2012 05:27 schrieb Henrik Maier: >>>>> >>>>> Hello Guillaume Fortaine, >>>>> >>>>> The libopencm3 is GPL and because of this not license compatible with >>>>> Nut/OS >>>>> and therefore cannot be used. I remember seeing discussions to change >>>>> the >>>>> license of libopencm3 to LGPL but this was rejected. >>>>> >>>>> See >>>>> >>>>> http://www.hermann-uwe.de/blog/libopenstm32-a-free-software-firmware-library-for-stm32-arm-cortex-m3-microcontrollers >>>>> >>>>> Best Regards >>>>> >>>>> Henrik Maier >>>>> >>>>> >>>>> >>>>> On 10/02/2012 12:58 PM, Guillaume Fortaine wrote: >>>>>> >>>>>> >>>>>> Dear Mister Bonnes, Mister Prinz, and Mister Maier >>>>>> >>>>>> First of all, I would like to wish you and the people around you an >>>>>> happy new year. >>>>>> >>>>>> Let me introduce myself : Guillaume FORTAINE, Cloudpreneur : >>>>>> >>>>>> http://www.linkedin.com/in/gfortaine >>>>>> >>>>>> I have read with interest the discussion entitled "branches\devnut_m3n >>>>>> and STM32F2 devices" [0]. Given that there is an Ethernet design >>>>>> available around the STM32 F-2, >>>>>> I would greatly appreciate to know if you plan to port the Ethernut >>>>>> project to it, if possible, please : >>>>>> >>>>>> http://cgi.ebay.fr/ws/eBayISAPI.dll?ViewItem&item=190638488534 >>>>>> >>>>>> "ST Cortex M3 STM32F207 Development Board Ethernet USB Device/Host CAN" >>>>>> >>>>>> >>>>>> By the way, to quote [0] : >>>>>> >>>>>> "What I thought I do for now is to create an new subdir under >>>>>> branches\devnut_m3n\arch\cm3\dev called stm32f2 which temporarily >>>>>> holds the drivers I ported across from the stm directory. Once that >>>>>> becomes all stable and working I can work with the other STM32F1 >>>>>> developers to maybe merge those files into one driver set suitable for >>>>>> F1, F2 and maybe even F4 devices. I like to avoid as much code >>>>>> duplication as possible." >>>>>> >>>>>> >>>>>> Wouldn't it be better to leverage the libopencm3 project ? >>>>>> >>>>>> http://libopencm3.org/ >>>>>> >>>>>> "The libopencm3 project (previously known as libopenstm32) aims to >>>>>> create a free/libre/open-source (GPL v3, or later) firmware library >>>>>> for various ARM Cortex-M3 microcontrollers, including ST STM32, >>>>>> Toshiba TX03, Atmel SAM3U, NXP LPC1000 and others." >>>>>> >>>>>> >>>>>> I look forward to your answer, >>>>>> >>>>>> Best Regards, >>>>>> >>>>>> [0] >>>>>> >>>>>> http://lists.egnite.de/pipermail/en-nut-discussion/2011-December/013183.html >>>>>> >>>>>> -- >>>>>> Guillaume FORTAINE >>>>>> guillaume.fortaine at devopspace.com >>>>>> DevOpSpace >>>>>> http://www.devopspace.com >>>>>> +33(0)631.092.519 >>>>>> >>>>> >>> >> > _______________________________________________ > http://lists.egnite.de/mailman/listinfo/en-nut-discussion > From thiago.correa at gmail.com Tue Feb 14 15:52:41 2012 From: thiago.correa at gmail.com (=?ISO-8859-1?Q?Thiago_A=2E_Corr=EAa?=) Date: Tue, 14 Feb 2012 12:52:41 -0200 Subject: [En-Nut-Discussion] Atmega 2561with more than 128k code and Winavr In-Reply-To: <20281.36759.32008.174174@elektron.ikp.physik.tu-darmstadt.de> References: <4F397095.3020708@gmx.de> <20281.36759.32008.174174@elektron.ikp.physik.tu-darmstadt.de> Message-ID: Hi, On Mon, Feb 13, 2012 at 8:32 PM, Uwe Bonnes wrote: > > I think, gcc has problems with AVR and CODE bigger than 128 k. > There was a very ancient bug report in gcc's bugzilla that was open for several months about that, can't say if it was fixed or if it remains open. I thought I had a link in one of our own bug reports but I couldn't find it. Sorry can't offer more help, but I would check out latest AVR Studio (comes with compiler now) and try to build against that compiler. Maybe it got fixed. Kind Regards, Thiago A. Correa From guillaume.fortaine at devopspace.com Tue Feb 14 23:08:02 2012 From: guillaume.fortaine at devopspace.com (Guillaume Fortaine) Date: Tue, 14 Feb 2012 23:08:02 +0100 Subject: [En-Nut-Discussion] Fwd: Fwd: Nut/OS BSD License (was Re: branches\devnut_m3n and STM32F2 devices) In-Reply-To: <4F3AD354.2080108@ngi.it> References: <4F39E257.7000405@proconx.com> <4F3AD354.2080108@ngi.it> Message-ID: ---------- Forwarded message ---------- From: G.Di Sirio Date: Tue, Feb 14, 2012 at 10:34 PM Subject: Re: [En-Nut-Discussion] Fwd: Nut/OS BSD License (was Re: branches\devnut_m3n and STM32F2 devices) Hi Guillame, Interesting indeed, I agree that Linux and ChibiOS/Nut-OS/others-similar have different licensing issues. This is something that troubled me a lot when I decided to turn ChibiOS into an open source project. It is true that a BSD or similar license would offer the greatest freedom for users but that would mean for me to automatically surrender any right on the code. I also felt that releasing something, basically for free, under a BSD license could devalue it somehow. It is free, it can't be really good, right? It is also true that a GPL license makes a "linkable" OS unusable for commercial applications so I decided to offer it under GPL3 with a linking exception AND alternatively under a GPL-free proprietary license. Hobbyists, students and small commercial users don't have problems with GPL+exception, big corporate users usually don't want to be bound even by a watered down GPL. IMO GPL is actually an advantage if you want a project to remain truly open AND also try to be profitable. So far this GPL+exception solution proved to work pretty well, the project is growing nicely. ciao, Giovanni Il 14/02/2012 19.57, Guillaume Fortaine ha scritto: > Hello, > > This is an interesting debate. What do you think of it ? > > I look forward to your answer, > > Best Regards, > > Guillaume FORTAINE > > > On Tue, Feb 14, 2012 at 5:25 AM, Henrik Maier ?wrote: >> >> Hello Guillaume, >> >> In reference to the article you are referring to, the situation for an >> embedded OS which is linked is very different to an OS like Linux. It is >> possible to use GPLed Linux with closed source applications. But if >> Nut/OS would be GPL, it would not be possible to keep your application >> code closed source which some users may prefer for commercial reasons. >> >> I believe the reason that Nut/OS has a BSD license contributes to the >> fact that we have a large commercial user base. >> >> Henrik >> >> On 14/02/2012 1:15 PM, Guillaume Fortaine wrote: >>> >>> I would greatly appreciate to invite you to a further reading of the >>> article entitled "Opinion: License to FUD (comparing GPL and BSD)" : >>> >>> http://www.linuxfordevices.com/c/a/Linux-For-Devices-Articles/Opinion-License-to-FUD-comparing-GPL-and-BSD/ >>> >> _______________________________________________ >> http://lists.egnite.de/mailman/listinfo/en-nut-discussion From hmnews at proconx.com Wed Feb 15 10:43:31 2012 From: hmnews at proconx.com (Henrik Maier) Date: Wed, 15 Feb 2012 19:43:31 +1000 Subject: [En-Nut-Discussion] Fwd: Fwd: Nut/OS BSD License (was Re: branches\devnut_m3n and STM32F2 devices) In-Reply-To: References: <4F39E257.7000405@proconx.com> <4F3AD354.2080108@ngi.it> Message-ID: <4F3B7E43.1070508@proconx.com> Hello Guillaume, The original question from you to some of the Cortex M3 branch developers was why we don't use libopencm3 and we explained the drawbacks of a GPL license. Even a GPL Expeption license instead of a BSD license for the OS (as preferred by Giovanni from ChibiOS) would be incompatible with a pure GPL license, which means if you integrate as you suggested libopencm3 into your project, you have to disclose the complete source including your application as the GPL Exception license applies only to the OS but not to other GPLed code like libopencm3. Regards Henrik On 15/02/2012 8:08 AM, Guillaume Fortaine wrote: > ---------- Forwarded message ---------- > From: G.Di Sirio > Date: Tue, Feb 14, 2012 at 10:34 PM > Subject: Re: [En-Nut-Discussion] Fwd: Nut/OS BSD License (was Re: > branches\devnut_m3n and STM32F2 devices) > > > Hi Guillame, > > Interesting indeed, I agree that Linux and > ChibiOS/Nut-OS/others-similar have different licensing issues. > > This is something that troubled me a lot when I decided to turn > ChibiOS into an open source project. It is true that a BSD or similar > license would offer the greatest freedom for users but that would mean > for me to automatically surrender any right on the code. I also felt > that releasing something, basically for free, under a BSD license > could devalue it somehow. It is free, it can't be really good, right? > > It is also true that a GPL license makes a "linkable" OS unusable for > commercial applications so I decided to offer it under GPL3 with a > linking exception AND alternatively under a GPL-free proprietary > license. > > Hobbyists, students and small commercial users don't have problems > with GPL+exception, big corporate users usually don't want to be bound > even by a watered down GPL. IMO GPL is actually an advantage if you > want a project to remain truly open AND also try to be profitable. > > So far this GPL+exception solution proved to work pretty well, the > project is growing nicely. > > ciao, > Giovanni > > Il 14/02/2012 19.57, Guillaume Fortaine ha scritto: > >> Hello, >> >> This is an interesting debate. What do you think of it ? >> >> I look forward to your answer, >> >> Best Regards, >> >> Guillaume FORTAINE >> >> >> On Tue, Feb 14, 2012 at 5:25 AM, Henrik Maier wrote: >>> >>> Hello Guillaume, >>> >>> In reference to the article you are referring to, the situation for an >>> embedded OS which is linked is very different to an OS like Linux. It is >>> possible to use GPLed Linux with closed source applications. But if >>> Nut/OS would be GPL, it would not be possible to keep your application >>> code closed source which some users may prefer for commercial reasons. >>> >>> I believe the reason that Nut/OS has a BSD license contributes to the >>> fact that we have a large commercial user base. >>> >>> Henrik >>> >>> On 14/02/2012 1:15 PM, Guillaume Fortaine wrote: >>>> >>>> I would greatly appreciate to invite you to a further reading of the >>>> article entitled "Opinion: License to FUD (comparing GPL and BSD)" : >>>> >>>> http://www.linuxfordevices.com/c/a/Linux-For-Devices-Articles/Opinion-License-to-FUD-comparing-GPL-and-BSD/ >>>> >>> _______________________________________________ >>> http://lists.egnite.de/mailman/listinfo/en-nut-discussion > _______________________________________________ > http://lists.egnite.de/mailman/listinfo/en-nut-discussion > From ulrich.prinz at googlemail.com Wed Feb 15 10:51:51 2012 From: ulrich.prinz at googlemail.com (Ulrich Prinz) Date: Wed, 15 Feb 2012 10:51:51 +0100 Subject: [En-Nut-Discussion] Anybody on Embedded World 2012? In-Reply-To: <4F37FD03.7080309@googlemail.com> References: <1328174237.2086.12.camel@platon> <4F37FD03.7080309@googlemail.com> Message-ID: So what day do we take 28 or 29? Ulrich Am 12. Februar 2012 18:55 schrieb Ulrich Prinz : > Hi! > > Some of my colleagues and I plan to go there, but a date has not been > fixed. CeBit is right after that and we need to be prepared to show up > there shortly on request. > > So I will write a date when the car is ordered :) > > Ulrich > > Am 02.02.2012 10:17, schrieb Ole Reinhardt: >> Hi all, >> >> just to be the first, I'm curious if anybody (beside of Egnite :-) will >> be on the Embedded World this year. >> >> Perhaps we could meet again? >> >> Right now I plan to be there at 28.02 or 29.02.2012 >> >> Bye, >> >> Ole >> From joerg.wiegelmann at gmx.de Wed Feb 15 13:37:01 2012 From: joerg.wiegelmann at gmx.de (Joerg Wiegelmann) Date: Wed, 15 Feb 2012 13:37:01 +0100 Subject: [En-Nut-Discussion] Atmega 2561with more than 128k code and Winavr In-Reply-To: References: <4F397095.3020708@gmx.de> <20281.36759.32008.174174@elektron.ikp.physik.tu-darmstadt.de> Message-ID: <4F3BA6ED.5010503@gmx.de> Hi Thiago, thank you for your help. I do as you recommended and I got new errors: D:/nut/nutbld/lib\libnutcrt.a(fputs_p.o): In function `fputs_P': fputs_p.c:(.text+0xc): undefined reference to `__strlen_P' and the old errors again.... D:/nut/nutbld/lib\libnutcrt.a(vfprintf.o): In function `vfprintf': vfprintf.c:(.text+0xa): warning: internal error: out of range error vfprintf.c:(.text+0xc): warning: internal error: out of range error I'm really disappointed now and I'm thinking about a change to another hardware platform. Perhaps EIR or Arm with C# or so..... My intention was to maintain my home-automation-project over the years. But with a code size more than 128k it isn't possible any more to deal with Atmel. Thank you all for your help, any idea is welcome Joerg Am 14.02.2012 15:52, schrieb Thiago A. Corr?a ......, but I would check out latest AVR Studio (comes with compiler now) and try to build against that compiler. Maybe it got fixed. From c.bonnemayer at maastrichtuniversity.nl Wed Feb 15 16:19:05 2012 From: c.bonnemayer at maastrichtuniversity.nl (Bonnemayer C (PSYCHOLOGY)) Date: Wed, 15 Feb 2012 16:19:05 +0100 Subject: [En-Nut-Discussion] stammering audio playback on EIR/VS1053B Message-ID: Dear all, Being a starter with Nut/OS I tried some NutWiki examples to gain some knowledge about this OS. As a Nut/OS newbee I hope you can forgive me for possible stupid questions. With a slightly modified version of the NutWiki MMC MP3 player I tried to play .ogg and .flac files (the latter with the VS1053B patch v1.95) on my EIR board. It appears that when using high quality files (with low compression and/or high bitrates) the output is interrupted during playback. I.e. the file plays for a second or so, waits for half a second, and then continues where it has left, this happens intermittentally. I tried several audio formats and to me it seems that high bitrate files (mp3 > 192 kbps, ogg > 44.1KHz, 147kbps) have more problems than low bitrate files. I played around with some settings, but changing VSCODEC0_OUTPUT_BUFSIZ in audio.h doesn't help. Also, changing VSCODEC0_SPI_RATE has no effect. it looks like that the problem lies in the fact that the VS1053 codec shares the SPI bus with the MMC interface, so there's a lot of data trafic on this bus. Unfortunately I don't have a logic analyzer, so I can't verify this. Does anybody has any suggestions for further troubleshooting? Best regards, Charles Bonnemayer Hardware: EIR board with VS1053 audio codec software: Nut/OS 4.10.1, Yagarto with GCC-4.6.2 Win OS: Windows XP SP3 From bon at elektron.ikp.physik.tu-darmstadt.de Wed Feb 15 17:53:18 2012 From: bon at elektron.ikp.physik.tu-darmstadt.de (Uwe Bonnes) Date: Wed, 15 Feb 2012 17:53:18 +0100 Subject: [En-Nut-Discussion] Anybody on Embedded World 2012? In-Reply-To: References: <1328174237.2086.12.camel@platon> <4F37FD03.7080309@googlemail.com> Message-ID: <20283.58110.884872.85050@elektron.ikp.physik.tu-darmstadt.de> >>>>> "Ulrich" == Ulrich Prinz writes: Ulrich> So what day do we take 28 or 29? Ulrich I am planning for the 28. Probably however I will drive home by car with other people or train home at about 18.00. Bye -- Uwe Bonnes bon at elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- From harald.kipp at egnite.de Wed Feb 15 18:33:04 2012 From: harald.kipp at egnite.de (Harald Kipp) Date: Wed, 15 Feb 2012 18:33:04 +0100 Subject: [En-Nut-Discussion] stammering audio playback on EIR/VS1053B In-Reply-To: References: Message-ID: <4F3BEC50.3030109@egnite.de> Hi Charles, On 15.02.2012 16:19, Bonnemayer C (PSYCHOLOGY) wrote: > With a slightly modified version of the NutWiki MMC MP3 player I tried to play .ogg and .flac files (the latter with the VS1053B patch v1.95) on my EIR board. It appears that when using high quality files (with low compression and/or high bitrates) the output is interrupted during playback. I.e. the file plays for a second or so, waits for half a second, and then continues where it has left, this happens intermittentally. I tried several audio formats and to me it seems that high bitrate files (mp3 > 192 kbps, ogg > 44.1KHz, 147kbps) have more problems than low bitrate files. > I played around with some settings, but changing VSCODEC0_OUTPUT_BUFSIZ in audio.h doesn't help. Also, changing VSCODEC0_SPI_RATE has no effect. > > it looks like that the problem lies in the fact that the VS1053 codec shares the SPI bus with the MMC interface, so there's a lot of data trafic on this bus. Unfortunately I don't have a logic analyzer, so I can't verify this. When designing the EIR, I intentionally did not share the SPI bus between MMC and the codec. Instead, I connected the MMC to the SSC in the hope, that one day I may be able to mimic SPI with the SSC interface. A first attempt failed, so I decided to use software SPI (bit-banging) as a temporary solution. However, when trying to play audio files from MMC, I experienced the same problems that you described. The good news is, that I finally managed to make SPI working on the SSC hardware, even with DMA (Atmel term: PDC). The bad new is, that a minor hardware change is required. You must connect PA16(TK) Port A connector pin 17 with PA19(RK) Port A connector pin 20 The problem with SSC is, that you cannot stop the receiver. But you can stop the transmitter, so my idea was to feed the receiver clock from the transmitter clock. I created a new SPI buts driver based on SSC and... it works! :-) The bad news is, that we are, in general, not allowed to add new features to a stable version. Therefore this new driver is only available in the current beta 5.0. However, I'm almost sure, that the driver will work with version 4.10 too. If you do not want to modify the configuration scripts (which may not be trivial, because the directory structure was modified), then you can simply place the driver's code in your local app directory and add it to the app's Makefile. You can find the code here http://ethernut.svn.sourceforge.net/viewvc/ethernut/trunk/nut/arch/arm/dev/atmel/ Look out for spibus*at91ssc.c. There's also an include file required #include or, if locally used #include "spibus_ssc.h" If you are considering to upgrade to Nut/OS 5.0 (looks quite stable to me), then you may wait a bit. I'm currently building a new beta release. Here's the code to use this new driver: printf("Register memory card device..."); if (NutRegisterSpiDevice(&devSpiMmcGpio, &spiBus0Ssc, 0)) { puts("failed"); } else { puts("OK"); } printf("Register file system..."); if (NutRegisterDevice(&devPhat0, 0, 0)) { puts("failed"); } else { puts("OK"); } printf("Mounting memory card..."); volid = _open(DEV_MMCARD_NAME ":1/PHAT0", _O_RDWR | _O_BINARY); if (volid == -1) { printf("Error %d\n", errno); for (;;); } puts("OK"); So far I had no time to test its real performance, but playing and recording on MMC worked. I remember having had problems with recording 192kbps streams, probably because of MMC latencies. This may be solved by using larger buffers. I'm also aware, that the PHAT filesystem layer is somewhat slow. Best regards, Harald From harald.kipp at egnite.de Wed Feb 15 19:25:40 2012 From: harald.kipp at egnite.de (Harald Kipp) Date: Wed, 15 Feb 2012 19:25:40 +0100 Subject: [En-Nut-Discussion] Ethernut 5 + Eclipse tutorial In-Reply-To: References: <70E051BE-4CD4-48C1-81D3-8AEC4A889653@dr-clauss.de> <4F364D09.9020602@egnite.de> Message-ID: <4F3BF8A4.9020800@egnite.de> Just for the records: >>> But when I want to build the project, Eclipse puts out "Cannot run >>> program "make" ". I have no idea, what I've made wrong. The path- >>> variable for yargarto is set correctly. Markus found the problem: The C/C++ Plugin wasn't properly installed. Regards, Harald From harald.kipp at egnite.de Wed Feb 15 19:54:52 2012 From: harald.kipp at egnite.de (Harald Kipp) Date: Wed, 15 Feb 2012 19:54:52 +0100 Subject: [En-Nut-Discussion] xgSMTPC Bugs In-Reply-To: <4F035707.7090805@egnite.de> References: <000001ccc717$2dd94250$898bc6f0$@s.profanter.me> <4F035707.7090805@egnite.de> Message-ID: <4F3BFF7C.40502@egnite.de> > On 30.12.2011 18:19, Stefan Profanter wrote: >> You can rewiew the code changes here and maybe add it to the SVN-Repo: >> >> https://codereview.appspot.com/5505086/ Applied to trunk and branch 4.10. Thanks again, Harald From thiago.correa at gmail.com Wed Feb 15 20:38:12 2012 From: thiago.correa at gmail.com (=?ISO-8859-1?Q?Thiago_A=2E_Corr=EAa?=) Date: Wed, 15 Feb 2012 17:38:12 -0200 Subject: [En-Nut-Discussion] Feature Request: Create Application Directory" for (q)nutconf In-Reply-To: <4F37A2F1.1060302@googlemail.com> References: <1328712760.2167.51.camel@platon> <4F37A2F1.1060302@googlemail.com> Message-ID: Hi, I have been wondering for a while how we could have a "New Project with Nut/OS" kind of wizard, like visual studio, into qnutconf and how it would build you the basic makefiles. It's interesting to know how ppl actually use Nut/OS in their environment. In particular, I keep my nuts/os in c:\programming\ethernut and my projects as c:\programming\comm5\firmware\ Inside I create a makefile that references the sample makefiles like this: include /programming/ethernut/nutapp/Makedefs SRCS = mysource.c LIBS = $(LIBDIR)/nutinit.o -lnutos -lnutarch -lnutdev -lnutcrt -lnutc -lnutgorp OBJS = $(SRCS:.c=.o) TARG = $(PROJ).hex all: $(OBJS) $(TARG) $(ITARG) $(DTARG) dep: $(CC) -I$(top_srcdir)/include -M main.c include /programming/ethernut/nutapp/Makerules It's simple and shouldn't be hard to generate, yet I don't think it's simple enough for the beginner. I'm interested in opinions. Kind Regards, Thiago A. Correa On Sun, Feb 12, 2012 at 9:30 AM, Ulrich Prinz wrote: > Hi! > > At first the separation of directory and makefile generation from > creation of all examples would be very helpfull. > > To add an option that enables to export all libraries and headers and > creates a set of working application makefiles is very fine. > We often need to keep nut/os libraries synced with the application > source code to be able to reproduce avery single software release. > > So if we could export the libraries and headers in parallel with the > applications it would be very handy for checking them in to SVN or > GIT. > > Ulrich > > > Am 08.02.2012 15:52, schrieb Ole Reinhardt: >> Hi Ulrich, >> >>> But if you develop lots of your own projects you might not like to >>> have all the examples installed. >> >> Yes, I well know this problem. I personally prefer to have a >> pre-compiled Nut/OS and to use just a few simple makefiles with my >> application, not all this directory hirarchy. >> >> Especialy when deploying Nut/OS as development environment for a board >> your customers won't ever compile Nut/OS by their own but just use the >> ready build libraries. >> >> So what I would suggest is to add an "Install Nut/OS" which would build >> the libraries, install it into a folder and add the necessary makefiles >> (just the ones for your compiler setting) >> >> As an example see >> >> http://www.embedded-it.de/bsp-download/webserver_relais_demo.tar.gz >> >> (folder Nut/OS) >> >> I also modified the application standard makefiles to refer to the >> pre-installed ones. >> >> Another idea: >> >> This install button could also copy the header files so that one would >> not have to install the whole source tree too. >> >> Bye, >> >> Ole >> >> > _______________________________________________ > http://lists.egnite.de/mailman/listinfo/en-nut-discussion From klaus.kloos at gmx.de Thu Feb 16 07:58:59 2012 From: klaus.kloos at gmx.de (Klaus Kloos) Date: Thu, 16 Feb 2012 07:58:59 +0100 Subject: [En-Nut-Discussion] Strange newlib syscall dependencies / linker problems when using 64bit integers In-Reply-To: <20274.26791.136327.58886@elektron.ikp.physik.tu-darmstadt.de> References: <1328566767.2181.11.camel@platon> <20273.21491.975139.994432@elektron.ikp.physik.tu-darmstadt.de> <1328703310.2167.5.camel@platon> <20274.26791.136327.58886@elektron.ikp.physik.tu-darmstadt.de> Message-ID: <23491BEC-072A-446D-92B5-760C27D7CBF8@gmx.de> Hello Some days ago there have been problems with linking using 64bit integers and im not shure if a solution was found. I stumbled over the same problem and found the following solution for me (Ethernut 4.10, yagarto). the following: --- /* .ARM.exidx is sorted, so has to go in its own output section. kl for using long long*/ .ARM.exidx : { __exidx_start = .; *(.ARM.exidx* .gnu.linkonce.armexidx.*) __exidx_end = .; } >rom --- was added to my .ld file right after the .text segment Somewhere i had to create the empty functions: --- void _sbrk(void){ } void _getpid(void){ } void _kill(void){ } void _exit(int status){ while(1){;} } --- But dont ask me why ..... This was all. It wasnt necessary for me to remove the -fno-exceptions -fno-rtti flags like some other descriptions are telling. Now the int64 are working, i have only little doubts in what situations the _exit functions is called and freezes my prg. Greetings Klaus From klaus.kloos at gmx.de Thu Feb 16 08:22:36 2012 From: klaus.kloos at gmx.de (Klaus Kloos) Date: Thu, 16 Feb 2012 08:22:36 +0100 Subject: [En-Nut-Discussion] SPI in IRQ Message-ID: <67F1A9B8-D367-4DB9-8EED-0519FE1687C0@gmx.de> Hello I have to work with an 24bit ADC AD7767 with 32kSPS. The values can be read between two finished conversions from the device using SPI. There are ca. 30us left for this when using the 32kSPS. My first though was to get the 'value ready' signal by IRQ, inform a thread by NutEventPostFromIrq() and get the value by SPI in a separate thread. But that is much to slow. Im not able to guaranty a context switch in this short time. The second approach was to get the SPI-value in the IRQ by bitbanging. This is a little to slow and very ugly. I will have to code this part in assembler..... So I tried to use the NutOS functions. (*spiBus1At91.bus_alloc) and (*spiBus1At91.bus_release) are called outside the IRQ, (*spiBus1At91.bus_transfer) is called at IRQ time. The transfer of the 3 bytes last ca. 12us using 10MHz SPI. It is working, but unreliable. Sometimes my device freezes. Im almost sure that the SPI-functions are not designed to be used like this. What are my possibilities? Is there a recommended way to solve such time-critical SPI-requests? Can I get the Nut/OS functions IRQ save somehow? Thanks in advance for any hint. Greetings Klaus Ingenieurb?ro Kloos Soft+Hardware Entwicklung Haus Heyden Strasse 111 52134 Herzogenrath Tel.: 02407/918376 Handy.: 0176/20925123 From harald.kipp at egnite.de Thu Feb 16 10:29:34 2012 From: harald.kipp at egnite.de (Harald Kipp) Date: Thu, 16 Feb 2012 10:29:34 +0100 Subject: [En-Nut-Discussion] SPI in IRQ In-Reply-To: <67F1A9B8-D367-4DB9-8EED-0519FE1687C0@gmx.de> References: <67F1A9B8-D367-4DB9-8EED-0519FE1687C0@gmx.de> Message-ID: <4F3CCC7E.5090804@egnite.de> Hi Klaus, On 16.02.2012 08:22, Klaus Kloos wrote: > So I tried to use the NutOS functions. (*spiBus1At91.bus_alloc) and (*spiBus1At91.bus_release) are called outside the IRQ, (*spiBus1At91.bus_transfer) is called at IRQ time. > The transfer of the 3 bytes last ca. 12us using 10MHz SPI. It is working, but unreliable. Sometimes my device freezes. Probably. In general, it is not allowed to call API functions in interrupt context, except NutEventPostFromIrq(). As a special exception it is possible to use stdio functions on a polling device, usually devDebug. > What are my possibilities? Is there a recommended way to solve such time-critical SPI-requests? > Can I get the Nut/OS functions IRQ save somehow? Nut/OS allows to use native interrupt handlers. For the AT91 you can use static void MySpiIrqHandler(void) __attribute__ ((naked)); void MySpiIrqHandler(void) { IRQ_ENTRY(); ...your code here... IRQ_EXIT(); } In your main code you need to write the address of the handler into the related AIC service routine register. outr(AIC_SVR(SPI0_ID), (unsigned int) MySpiIrqHandler); And...not to forget...it is always a good idea to check the datasheet. ;-) Regards, Harald From info at pragmalab.nl Thu Feb 16 10:54:49 2012 From: info at pragmalab.nl (PragmaLab (Rob van Lieshout)) Date: Thu, 16 Feb 2012 10:54:49 +0100 Subject: [En-Nut-Discussion] 2561with more than 128k code and Winavr In-Reply-To: References: Message-ID: <001c01ccec91$056a7e20$103f7a60$@nl> Hi Joerg >I'm really disappointed now and I'm thinking about a change to another >hardware platform. Perhaps EIR or Arm with C# or so..... >My intention was to maintain my home-automation-project over the years. >But with a code size more than 128k it isn't possible any more to deal >with Atmel. Codesize > 128K for the ATMega256 and WinAVR shouldn't be a problem at all. First WinAVR version that dealt correctly with the 128k boundary was 20070525. We still use that one for our (commercial) product (almost 256K used now). Not sure what the problem can be exactly, but if you wish I could send you my makefile. WinAVR 20100110 can be used as well. At the time (must be more then 4 years now), we had lots of problems when we ported our code to the Mega256, but one by one the problems were solved. Regards, Rob From klaus.kloos at gmx.de Thu Feb 16 12:04:28 2012 From: klaus.kloos at gmx.de (Klaus Kloos) Date: Thu, 16 Feb 2012 12:04:28 +0100 Subject: [En-Nut-Discussion] SPI in IRQ In-Reply-To: <4F3CCC7E.5090804@egnite.de> References: <67F1A9B8-D367-4DB9-8EED-0519FE1687C0@gmx.de> <4F3CCC7E.5090804@egnite.de> Message-ID: <5021F9A0-B4B6-479A-8589-9364E7DDD0AA@gmx.de> Hello Harald Thanks for your fast answer. > On 16.02.2012 08:22, Klaus Kloos wrote: >> So I tried to use the NutOS functions. (*spiBus1At91.bus_alloc) and (*spiBus1At91.bus_release) are called outside the IRQ, (*spiBus1At91.bus_transfer) is called at IRQ time. >> The transfer of the 3 bytes last ca. 12us using 10MHz SPI. It is working, but unreliable. Sometimes my device freezes. > > Probably. In general, it is not allowed to call API functions in > interrupt context, except NutEventPostFromIrq(). As a special exception > it is possible to use stdio functions on a polling device, usually devDebug. > ok, i was aware that this is not the right way. It was only a test and it gave me a 'near to working' result :-) My hope was to get bus-transfer() IRQ save somehow...... What is necessary to make a function IRQ save? >> What are my possibilities? Is there a recommended way to solve such time-critical SPI-requests? >> Can I get the Nut/OS functions IRQ save somehow? > > Nut/OS allows to use native interrupt handlers. For the AT91 you can use > > static void MySpiIrqHandler(void) __attribute__ ((naked)); > void MySpiIrqHandler(void) > { > IRQ_ENTRY(); > ...your code here... > IRQ_EXIT(); > } > > In your main code you need to write the address of the handler into the > related AIC service routine register. > > outr(AIC_SVR(SPI0_ID), (unsigned int) MySpiIrqHandler); > Interesting, this might give me back the 1us which I loose between an IRQ and the calling of my IRQ-routine using the NutOS way. But that's not the main problem. How do I get the SPI-Value in my 30us slot? I see these ways: Is there a way to generate a fast context-switch from IRQ to the thread which is allowed to call bus_transfer()? Can this be done reliable in ca. 10us? Then I can use the NutOS SPI routines. An other way is the read the data in the IRQ. But then I have to code a function like bus_transfer() by myself (?). Not a nice chance... A simple solution would be working without an IRQ and do everything in a thread without allowing a context-switch. So the sam7 will freeze for up to 50ms (i have to read 1000 values). > And...not to forget...it is always a good idea to check the datasheet. ;-) > Not that I have completely memorized it, but Ive read it several times. The problem seems clear. Im too slow. There is also a 128kSPS variant of the chip available. Then the time slot is less than 8us. Im happy that Im not forced to solve this problem.... Greetings Klaus From ulrich.prinz at googlemail.com Thu Feb 16 15:25:58 2012 From: ulrich.prinz at googlemail.com (Ulrich Prinz) Date: Thu, 16 Feb 2012 15:25:58 +0100 Subject: [En-Nut-Discussion] SPI in IRQ In-Reply-To: <5021F9A0-B4B6-479A-8589-9364E7DDD0AA@gmx.de> References: <67F1A9B8-D367-4DB9-8EED-0519FE1687C0@gmx.de> <4F3CCC7E.5090804@egnite.de> <5021F9A0-B4B6-479A-8589-9364E7DDD0AA@gmx.de> Message-ID: Hi Klaus, If I understand the datasheet of the ADC correctly it serves you with /DRDY signal every time a sample is complete. So if you write a GPIO IRQ handler that reads the SPI at this time, you are done with the first part. For reading SPI you need to throw out dummy bytes that just trigger SCK so the ADC can write via MISO to your AT91. To get more free CPU time, you should think about using DMA transfer for SPI. So you set up a dummy region of RAM that hold a fixed pattern of control words and dummy bytes. Then you set up another region to store the read values into. Then you setup and start DMA with completion interrupt set. The DMA completion interrupt then shows your application that there is a new value available. If you need several values at a time, you can expand the regions of dummy and reception values and setup the DMA to transfer this bigger regions. The DMA Interrupt then only counts down the number of samples per block and calls your application after counter has reached 0. To be more flexible and gather some additional time: You can set the AT91 DMA to work with separate pages. So if a DMA is completed you can flip to a nother page where it continues to work right away. So after you sampled one page, you have time to decode and move the date from there, while the DMA continues to write into the second page. After the second page is completed the DMA flips back to the first page or even a third page. If I remeber my last AT91 devel over a year ago, it should be possible to implement you ADC routines with just DMA and a single DMA interrupt handler. In general: You should keep a state variable in you code, that shows if your sampling is active. If not active, you can use normal nut/os SPI functions to setup / program your ADC. After activating your sampling, the variable should state that no normal nut/os function should trigger SPI. You did not state the reason for this construction but in general I would suppose to use the I2S interface of an AT91 or STM32 and use the special features of this interface that automates constant time sampling and delivery of data with very low software overhead including multi buffer handling ( work in one while the other is filled, then switch) I2S is just a derivate of SPI... Ulrich Am 16. Februar 2012 12:04 schrieb Klaus Kloos : > Hello Harald > > Thanks for your fast answer. > >> On 16.02.2012 08:22, Klaus Kloos wrote: >>> So I tried to use the NutOS functions. (*spiBus1At91.bus_alloc) and (*spiBus1At91.bus_release) are called outside the IRQ, ?(*spiBus1At91.bus_transfer) is called at IRQ time. >>> The transfer of the 3 bytes last ca. 12us using 10MHz SPI. It is working, but unreliable. Sometimes my device freezes. >> >> Probably. In general, it is not allowed to call API functions in >> interrupt context, except NutEventPostFromIrq(). As a special exception >> it is possible to use stdio functions on a polling device, usually devDebug. >> > ok, i was aware that this is not the right way. It was only a test and it gave me a 'near to working' result :-) My hope was to get bus-transfer() IRQ save somehow...... > What is necessary to make a function IRQ save? > >>> What are my possibilities? Is there a recommended way to solve such time-critical SPI-requests? >>> Can I get the Nut/OS functions IRQ save somehow? >> >> Nut/OS allows to use native interrupt handlers. For the AT91 you can use >> >> static void MySpiIrqHandler(void) __attribute__ ((naked)); >> void MySpiIrqHandler(void) >> { >> ? ?IRQ_ENTRY(); >> ...your code here... >> ? ?IRQ_EXIT(); >> } >> >> In your main code you need to write the address of the handler into the >> related AIC service routine register. >> >> outr(AIC_SVR(SPI0_ID), (unsigned int) MySpiIrqHandler); >> > Interesting, this might give me back the 1us which I loose between an IRQ and the calling of my IRQ-routine using the NutOS way. > > But that's not the main problem. How do I get the SPI-Value in my 30us slot? I see these ways: > Is there a way to generate a fast context-switch from IRQ to the thread which is allowed to call bus_transfer()? Can this be done reliable in ca. 10us? > Then I can use the NutOS SPI routines. > > An other way is the read the data in the IRQ. But then I have to code a function like bus_transfer() by myself (?). Not a nice chance... > > A simple solution would be working without an IRQ and do everything in a thread without allowing a context-switch. So the sam7 will freeze for up to 50ms (i have to read 1000 values). > >> And...not to forget...it is always a good idea to check the datasheet. ;-) >> > Not that I have completely memorized it, but Ive read it several times. The problem seems clear. Im too slow. > There is also a 128kSPS variant of the chip available. Then the time slot is less than 8us. Im happy that Im not forced to solve this problem.... > > Greetings Klaus > _______________________________________________ > http://lists.egnite.de/mailman/listinfo/en-nut-discussion From ulrich.prinz at googlemail.com Thu Feb 16 16:00:35 2012 From: ulrich.prinz at googlemail.com (Ulrich Prinz) Date: Thu, 16 Feb 2012 16:00:35 +0100 Subject: [En-Nut-Discussion] Feature Request: Create Application Directory" for (q)nutconf In-Reply-To: References: <1328712760.2167.51.camel@platon> <4F37A2F1.1060302@googlemail.com> Message-ID: Hi Thiago, Im an not sure if it is wise to only keep one nut/os for several different projects... In commercial programming you need to be able to restore every release of your software and sometimes you must restore an old state that has generates an identical md5sum of the binry output. So if you in the meantime have improved nut/os with some things, you cannot restore the project to an identical checksum as the libraries have changed. What we do is to keep the following structure under version control: project-x/nut project-x/nutapp-arch-gcc project-x/nutapp-arch-gcc/bootloader project-x/nutapp-arch-gcc/device-a project-x/nutapp-arch-gcc/device-b project-x/nutapp-arch-gcc/device-c So if a new person joins development, - he checks out project-x - starts qnutconf with the project-x.conf file - builds nut/os - build application If a new project is started you can either switch / branch to it from an existing constellation or you could export your current projext-x/nut to a new porject-y. - run qnutconf with a most matching existing conf, modify it and do an initial checkin. - build nut/os, create sample directory - add your new device-f or copy/rename a matching demo code (mostly uart demo :) ) - delete all unneeded demo directories. - check in the device With that procedure you can keep the nut/os and application / device sources und strict version control. It is even possible to switch achitecture in the evaluation phase of a project and keeping both architectures side by side to see what is most efficient. So for me it is really helpfull to be able to create and (important) update that nutapp-arch-xyz directory including all Makefiles but excluding all demos. What we did in the past was to take nut/os from sourceforge and our applications from our own version control system. But it showed up that this was not working as there is no link between the application software version and the nut/os software version. You either need to check in nut/os in an unclean state to have a fixed revision number or you have to track all differencs to the last checkout. Any other way will lead to the situation where the last generated binary file for a device cannot be reproduced anymore. Best regards Ulrich Am 15. Februar 2012 20:38 schrieb Thiago A. Corr?a : > Hi, > > > I have been wondering for a while how we could have a "New Project > with Nut/OS" kind of wizard, like visual studio, into qnutconf and how > it would build you the basic makefiles. It's interesting to know how > ppl actually use Nut/OS in their environment. > > In particular, I keep my nuts/os in c:\programming\ethernut and my > projects as c:\programming\comm5\firmware\ > Inside I create a makefile that references the sample > makefiles like this: > > include /programming/ethernut/nutapp/Makedefs > > SRCS = ?mysource.c > LIBS = ?$(LIBDIR)/nutinit.o -lnutos -lnutarch -lnutdev -lnutcrt -lnutc -lnutgorp > OBJS = ?$(SRCS:.c=.o) > TARG = ?$(PROJ).hex > > all: $(OBJS) $(TARG) $(ITARG) $(DTARG) > > dep: > ? ? ? ?$(CC) -I$(top_srcdir)/include -M main.c > > > include /programming/ethernut/nutapp/Makerules > > > It's simple and shouldn't be hard to generate, yet I don't think it's > simple enough for the beginner. I'm interested in opinions. > > > Kind Regards, > ? ?Thiago A. Correa > > On Sun, Feb 12, 2012 at 9:30 AM, Ulrich Prinz > wrote: >> Hi! >> >> At first the separation of directory and makefile generation from >> creation of all examples would be very helpfull. >> >> To add an option that enables to export all libraries and headers and >> creates a set of working application makefiles is very fine. >> We often need to keep nut/os libraries synced with the application >> source code to be able to reproduce avery single software release. >> >> So if we could export the libraries and headers in parallel with the >> applications it would be very handy for checking them in to SVN or >> GIT. >> >> Ulrich >> >> >> Am 08.02.2012 15:52, schrieb Ole Reinhardt: >>> Hi Ulrich, >>> >>>> But if you develop lots of your own projects you might not like to >>>> have all the examples installed. >>> >>> Yes, I well know this problem. I personally prefer to have a >>> pre-compiled Nut/OS and to use just a few simple makefiles with my >>> application, not all this directory hirarchy. >>> >>> Especialy when deploying Nut/OS as development environment for a board >>> your customers won't ever compile Nut/OS by their own but just use the >>> ready build libraries. >>> >>> So what I would suggest is to add an "Install Nut/OS" which would build >>> the libraries, install it into a folder and add the necessary makefiles >>> (just the ones for your compiler setting) >>> >>> As an example see >>> >>> http://www.embedded-it.de/bsp-download/webserver_relais_demo.tar.gz >>> >>> (folder Nut/OS) >>> >>> I also modified the application standard makefiles to refer to the >>> pre-installed ones. >>> >>> Another idea: >>> >>> This install button could also copy the header files so that one would >>> not have to install the whole source tree too. >>> >>> Bye, >>> >>> Ole >>> >>> >> _______________________________________________ >> http://lists.egnite.de/mailman/listinfo/en-nut-discussion > _______________________________________________ > http://lists.egnite.de/mailman/listinfo/en-nut-discussion From ulrich.prinz at googlemail.com Thu Feb 16 16:19:00 2012 From: ulrich.prinz at googlemail.com (Ulrich Prinz) Date: Thu, 16 Feb 2012 16:19:00 +0100 Subject: [En-Nut-Discussion] Anybody on Embedded World 2012? In-Reply-To: <20283.58110.884872.85050@elektron.ikp.physik.tu-darmstadt.de> References: <1328174237.2086.12.camel@platon> <4F37FD03.7080309@googlemail.com> <20283.58110.884872.85050@elektron.ikp.physik.tu-darmstadt.de> Message-ID: Hi! I thought about having lunch together in the town near by after 18:00 as we drive by car and don't like get into the usual traffic jams in the evening. Ulrich Am 15. Februar 2012 17:53 schrieb Uwe Bonnes : >>>>>> "Ulrich" == Ulrich Prinz writes: > > ? ?Ulrich> So what day do we take 28 or 29? ?Ulrich > > I am planning for the 28. Probably however I will drive home by car with > other people or train home ?at about 18.00. > > Bye > -- > Uwe Bonnes ? ? ? ? ? ? ? ?bon at elektron.ikp.physik.tu-darmstadt.de > > Institut fuer Kernphysik ?Schlossgartenstrasse 9 ?64289 Darmstadt > --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- > _______________________________________________ > http://lists.egnite.de/mailman/listinfo/en-nut-discussion From guillaume.fortaine at devopspace.com Thu Feb 16 23:51:12 2012 From: guillaume.fortaine at devopspace.com (Guillaume Fortaine) Date: Thu, 16 Feb 2012 23:51:12 +0100 Subject: [En-Nut-Discussion] Mini C library, for small embedded MCU Message-ID: Hello, For your information : http://code.google.com/p/minilib-c/ "A small C library, based on newlib library, but more compact and with fewer functions" Best Regards, Guillaume FORTAINE From bon at elektron.ikp.physik.tu-darmstadt.de Fri Feb 17 11:17:52 2012 From: bon at elektron.ikp.physik.tu-darmstadt.de (Uwe Bonnes) Date: Fri, 17 Feb 2012 11:17:52 +0100 Subject: [En-Nut-Discussion] Anybody on Embedded World 2012? In-Reply-To: References: <1328174237.2086.12.camel@platon> <4F37FD03.7080309@googlemail.com> <20283.58110.884872.85050@elektron.ikp.physik.tu-darmstadt.de> Message-ID: <20286.10576.571167.651853@elektron.ikp.physik.tu-darmstadt.de> >>>>> "Ulrich" == Ulrich Prinz writes: Ulrich> Hi! I thought about having lunch together in the town near by Ulrich> after 18:00 as we drive by car and don't like get into the usual Ulrich> traffic jams in the evening. Getting back by train after 18.00 is taking longer. I now have booked a ticket for the 28.2. to arrive at the fair at 10:30 and I have to leave 17:30. If you go the 28.2 too, perhaps we can meet for lunch or a coffee, or even only a talk in some of the meeting points. Bye -- Uwe Bonnes bon at elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- From ulrich.prinz at googlemail.com Fri Feb 17 12:42:25 2012 From: ulrich.prinz at googlemail.com (Ulrich Prinz) Date: Fri, 17 Feb 2012 12:42:25 +0100 Subject: [En-Nut-Discussion] Anybody on Embedded World 2012? In-Reply-To: <20286.10576.571167.651853@elektron.ikp.physik.tu-darmstadt.de> References: <1328174237.2086.12.camel@platon> <4F37FD03.7080309@googlemail.com> <20283.58110.884872.85050@elektron.ikp.physik.tu-darmstadt.de> <20286.10576.571167.651853@elektron.ikp.physik.tu-darmstadt.de> Message-ID: Hi! We had to change to 29th cause of some meetings on 28th... Sorry Regards Ulrich Am 17. Februar 2012 11:17 schrieb Uwe Bonnes : >>>>>> "Ulrich" == Ulrich Prinz writes: > > ? ?Ulrich> Hi! ?I thought about having lunch together in the town near by > ? ?Ulrich> after 18:00 as we drive by car and don't like get into the usual > ? ?Ulrich> traffic jams in the evening. > > Getting back by train after 18.00 is taking longer. > > I now have booked a ticket for the 28.2. to arrive at the fair at 10:30 and > I have to leave 17:30. If you go the 28.2 too, perhaps we can meet for lunch > or a coffee, or even only a talk in some of the meeting points. > > Bye > > -- > Uwe Bonnes ? ? ? ? ? ? ? ?bon at elektron.ikp.physik.tu-darmstadt.de > > Institut fuer Kernphysik ?Schlossgartenstrasse 9 ?64289 Darmstadt > --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- > _______________________________________________ > http://lists.egnite.de/mailman/listinfo/en-nut-discussion From markus.dost at dr-clauss.de Mon Feb 20 08:22:17 2012 From: markus.dost at dr-clauss.de (Markus Dost) Date: Mon, 20 Feb 2012 08:22:17 +0100 Subject: [En-Nut-Discussion] Ethernut 5 + Eclipse tutorial In-Reply-To: <4F3BF8A4.9020800@egnite.de> References: <70E051BE-4CD4-48C1-81D3-8AEC4A889653@dr-clauss.de> <4F364D09.9020602@egnite.de> <4F3BF8A4.9020800@egnite.de> Message-ID: <74F54EEB-B219-4776-91AC-C2CEC862D94F@dr-clauss.de> Hi, I try to debug the Ethernut 5 board with the turtelizer2 and Eclipse. After starting OpenOCD, I want to run the debugging and the console puts out: "Info: accepting 'gdb' connection from 3333" But then the progress stops and this error message appears: "Error in final launch sequence Failed to execute MI command: -target-select remote localhost:3333 Error message from debugger back end: Malformed response to offset query, timeout Malformed response to offset query, timeout" Does anybody know what I've made wrong? Best regards, Markus From harald.kipp at egnite.de Mon Feb 20 09:28:44 2012 From: harald.kipp at egnite.de (Harald Kipp) Date: Mon, 20 Feb 2012 09:28:44 +0100 Subject: [En-Nut-Discussion] Ethernut 5 + Eclipse tutorial In-Reply-To: <74F54EEB-B219-4776-91AC-C2CEC862D94F@dr-clauss.de> References: <70E051BE-4CD4-48C1-81D3-8AEC4A889653@dr-clauss.de> <4F364D09.9020602@egnite.de> <4F3BF8A4.9020800@egnite.de> <74F54EEB-B219-4776-91AC-C2CEC862D94F@dr-clauss.de> Message-ID: <4F42043C.8000608@egnite.de> Hi Markus, On 20.02.2012 08:22, Markus Dost wrote: > But then the progress stops and this error message appears: > "Error in final launch sequence > Failed to execute MI command: > -target-select remote localhost:3333 > > Error message from debugger back end: > Malformed response to offset query, timeout > Malformed response to offset query, timeout" Are you sure that you selected "Standard GDB Hardware Debugging Launcher" http://www.ethernut.de/img/indigo-debug-config-main.png If not, click on "Select other...". May be you should first make sure that the OpenOCD - Turtelizer - Ethernut chain is working. http://www.ethernut.de/en/hardware/enut5/openocd.html Regards, Harald From markus.dost at dr-clauss.de Mon Feb 20 11:17:12 2012 From: markus.dost at dr-clauss.de (Markus Dost) Date: Mon, 20 Feb 2012 11:17:12 +0100 Subject: [En-Nut-Discussion] Ethernut 5 + Eclipse tutorial In-Reply-To: <4F42043C.8000608@egnite.de> References: <70E051BE-4CD4-48C1-81D3-8AEC4A889653@dr-clauss.de> <4F364D09.9020602@egnite.de> <4F3BF8A4.9020800@egnite.de> <74F54EEB-B219-4776-91AC-C2CEC862D94F@dr-clauss.de> <4F42043C.8000608@egnite.de> Message-ID: Hi Harald, Am 20.02.2012 um 09:28 schrieb Harald Kipp: > Are you sure that you selected "Standard GDB Hardware Debugging > Launcher" > Right, I forgot it. But now I get the following error: "symbol-file C:\\ethernut-4.10\\nutapp\\events\\events.elf Ignoring packet error, continuing ... warning: unrecognized item "timeout" in "qSupported" response Ignoring packet error, continuing ... Ignoring packet error, continuing ... Ignoring packet error, continuing ... Ignoring packet error, continuing ... Ignoring packet error, continuing ... load C:\\ethernut-4.10\\nutapp\\events\\events.elf You can't do that when your target is 'None'" The settings for the debugger are the same as in the tutorial. Is it necessary to start a GDB-server? I'm very new at this stuff ... > May be you should first make sure that the OpenOCD - Turtelizer - > Ethernut chain is working. I would say the chain is working. I can load .bin-Files to the board and execute them. Regards, Markus From harald.kipp at egnite.de Mon Feb 20 20:05:55 2012 From: harald.kipp at egnite.de (Harald Kipp) Date: Mon, 20 Feb 2012 20:05:55 +0100 Subject: [En-Nut-Discussion] Ethernut 5 + Eclipse tutorial In-Reply-To: References: <70E051BE-4CD4-48C1-81D3-8AEC4A889653@dr-clauss.de> <4F364D09.9020602@egnite.de> <4F3BF8A4.9020800@egnite.de> <74F54EEB-B219-4776-91AC-C2CEC862D94F@dr-clauss.de> <4F42043C.8000608@egnite.de> Message-ID: <4F429993.3000803@egnite.de> Hi Markus, On 20.02.2012 11:17, Markus Dost wrote: > warning: unrecognized item "timeout" in "qSupported" response > Ignoring packet error, continuing ... > Ignoring packet error, continuing ... > Ignoring packet error, continuing ... > Ignoring packet error, continuing ... > Ignoring packet error, continuing ... > load C:\\ethernut-4.10\\nutapp\\events\\events.elf > You can't do that when your target is 'None'" > > The settings for the debugger are the same as in the tutorial. Is it > necessary to start a GDB-server? I'm very new at this stuff ... OpenOCD works as a GDB server in this case and yes, it needs to be started, either manually or from within OpenOCD. http://www.ethernut.de/en/tools/eclipse/confdebug.html (Near the end of that page) The tricky part may be how to start it. You may set the SDRAM Configuration in Eclipse http://www.ethernut.de/en/hardware/enut5/enut50scd43.png but I prefer the command line version openocd -d3 -s ../../nut/tools/turtelizer2 -c "source [find interface/turtelizer2.cfg]" -c "source [find board/ethernut5.cfg]" -c init -c "reset init" -c halt as done here http://www.ethernut.de/img/indigo-debug-tools.png In this case you don't need to specify any montior commands http://www.ethernut.de/img/indigo-debug-config-startup.png (Textarea below "Halt" is left empty) Best regards, Harald From ole.reinhardt at embedded-it.de Mon Feb 20 21:28:57 2012 From: ole.reinhardt at embedded-it.de (Ole Reinhardt) Date: Mon, 20 Feb 2012 21:28:57 +0100 Subject: [En-Nut-Discussion] Strange newlib syscall dependencies / linker problems when using 64bit integers In-Reply-To: <23491BEC-072A-446D-92B5-760C27D7CBF8@gmx.de> References: <1328566767.2181.11.camel@platon> <20273.21491.975139.994432@elektron.ikp.physik.tu-darmstadt.de> <1328703310.2167.5.camel@platon> <20274.26791.136327.58886@elektron.ikp.physik.tu-darmstadt.de> <23491BEC-072A-446D-92B5-760C27D7CBF8@gmx.de> Message-ID: <1329769737.2299.3.camel@platon> Hi all, I've been on a business trip for the last week, so sorry for the late answer. > Some days ago there have been problems with linking using 64bit integers and im not shure if a solution was found. I stumbled over the same problem and found the following solution for me (Ethernut 4.10, yagarto). > the following: > --- > /* .ARM.exidx is sorted, so has to go in its own output section. kl for using long long*/ > .ARM.exidx : { > __exidx_start = .; > *(.ARM.exidx* .gnu.linkonce.armexidx.*) > __exidx_end = .; > } >rom > --- > was added to my .ld file right after the .text segment > > Somewhere i had to create the empty functions: > --- > void _sbrk(void){ > } > > void _getpid(void){ > } > > void _kill(void){ > } > > void _exit(int status){ > while(1){;} > } Yes this is the solution. I decided to go another way and to use only 32bit integers after a redesign of my algorithm. The mentioned function stubs are the needed "syscall" stubs for Newlib. In fact they hopefully won't ever be used. The _exit() function will only be called in case of a "software exeption" like a division by zero. Bye, Ole -- Thermotemp GmbH, Embedded-IT Embedded Hard-/ Software and Open Source Development, Integration and Consulting http://www.embedded-it.de Gesch?ftsstelle Siegen - Steinstra?e 67 - D-57072 Siegen - tel +49 (0)271 5513597, +49 (0)271-73681 - fax +49 (0)271 736 97 Hauptsitz - Hademarscher Weg 7 - 13503 Berlin Tel +49 (0)30 4315205 - Fax +49 (0)30 43665002 Gesch?ftsf?hrer: J?rg Friedrichs, Ole Reinhardt Handelsregister Berlin Charlottenburg HRB 45978 UstID DE 156329280 From ole.reinhardt at embedded-it.de Mon Feb 20 21:31:54 2012 From: ole.reinhardt at embedded-it.de (Ole Reinhardt) Date: Mon, 20 Feb 2012 21:31:54 +0100 Subject: [En-Nut-Discussion] Anybody on Embedded World 2012? In-Reply-To: <20286.10576.571167.651853@elektron.ikp.physik.tu-darmstadt.de> References: <1328174237.2086.12.camel@platon> <4F37FD03.7080309@googlemail.com> <20283.58110.884872.85050@elektron.ikp.physik.tu-darmstadt.de> <20286.10576.571167.651853@elektron.ikp.physik.tu-darmstadt.de> Message-ID: <1329769914.2299.5.camel@platon> Hi all, > Getting back by train after 18.00 is taking longer. I'll be there at the 28.02. too. Let's exchange phone numbers before or agree on a meeting point / time :) Bye, Ole -- Thermotemp GmbH, Embedded-IT Embedded Hard-/ Software and Open Source Development, Integration and Consulting http://www.embedded-it.de Gesch?ftsstelle Siegen - Steinstra?e 67 - D-57072 Siegen - tel +49 (0)271 5513597, +49 (0)271-73681 - fax +49 (0)271 736 97 Hauptsitz - Hademarscher Weg 7 - 13503 Berlin Tel +49 (0)30 4315205 - Fax +49 (0)30 43665002 Gesch?ftsf?hrer: J?rg Friedrichs, Ole Reinhardt Handelsregister Berlin Charlottenburg HRB 45978 UstID DE 156329280 From markus.dost at dr-clauss.de Tue Feb 21 08:09:02 2012 From: markus.dost at dr-clauss.de (Markus Dost) Date: Tue, 21 Feb 2012 08:09:02 +0100 Subject: [En-Nut-Discussion] Ethernut 5 + Eclipse tutorial In-Reply-To: <4F429993.3000803@egnite.de> References: <70E051BE-4CD4-48C1-81D3-8AEC4A889653@dr-clauss.de> <4F364D09.9020602@egnite.de> <4F3BF8A4.9020800@egnite.de> <74F54EEB-B219-4776-91AC-C2CEC862D94F@dr-clauss.de> <4F42043C.8000608@egnite.de> <4F429993.3000803@egnite.de> Message-ID: Hi Harald Am 20.02.2012 um 20:05 schrieb Harald Kipp: > OpenOCD works as a GDB server in this case and yes, it needs to be > started, either manually or from within OpenOCD. > > http://www.ethernut.de/en/tools/eclipse/confdebug.html > (Near the end of that page) > > The tricky part may be how to start it. You may set the SDRAM > Configuration in Eclipse > > http://www.ethernut.de/en/hardware/enut5/enut50scd43.png > > but I prefer the command line version > > openocd -d3 -s ../../nut/tools/turtelizer2 -c "source [find > interface/turtelizer2.cfg]" -c "source [find board/ethernut5.cfg]" - > c init -c "reset init" -c halt > > as done here > > http://www.ethernut.de/img/indigo-debug-tools.png > > In this case you don't need to specify any montior commands > > http://www.ethernut.de/img/indigo-debug-config-startup.png > (Textarea below "Halt" is left empty) Thank your for your help but my settings for OpenOCD and the debug configuration are exactly what you've written here. Here are the console outputs after starting OpenOCD: Open On-Chip Debugger 0.5.0 (2011-11-23-10:33) Licensed under GNU GPL v2 For bug reports, read http://openocd.berlios.de/doc/doxygen/bugs.html Info : only one transport option; autoselect 'jtag' trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain adapter_nsrst_delay: 300 jtag_ntrst_delay: 200 RCLK - adaptive srst_only separate srst_gates_jtag srst_open_drain Info : device: 4 "2232C" Info : deviceID: 67354056 Info : SerialNumber: TLV6QNFFA Info : Description: Turtelizer JTAG/RS232 Adapter A Info : RCLK (adaptive clock speed) not supported - fallback to 3 kHz Info : JTAG tap: at91sam9260.cpu tap/device found: 0x0792603f (mfg: 0x01f, part: 0x7926, ver: 0x0) Info : Embedded ICE version 6 Info : at91sam9260.cpu: hardware has 2 breakpoint/watchpoint units RCLK not supported - fallback to 5 kHz target state: halted target halted in ARM state due to debug-request, current mode: Supervisor cpsr: 0x400000d3 pc: 0x27f72084 MMU: disabled, D-Cache: disabled, I-Cache: enabled Info : JTAG tap: at91sam9260.cpu tap/device found: 0x0792603f (mfg: 0x01f, part: 0x7926, ver: 0x0) target state: halted target halted in ARM state due to breakpoint, current mode: Supervisor cpsr: 0x000000d3 pc: 0x00000000 MMU: disabled, D-Cache: disabled, I-Cache: disabled RCLK not supported - fallback to 3000 kHz dcc downloads are enabled Warn : NOTE! Severe performance degradation without fast memory access enabled. Type 'help fast'. Info : accepting 'gdb' connection from 3333 and the arm-none-eabi-gdb.exe: symbol-file C:\\ethernut-4.10\\nutapp\\events\\events.elf Ignoring packet error, continuing... warning: unrecognized item "timeout" in "qSupported" response Ignoring packet error, continuing... Ignoring packet error, continuing... Ignoring packet error, continuing... Ignoring packet error, continuing... Ignoring packet error, continuing... Ignoring packet error, continuing... load C:\\ethernut-4.10\\nutapp\\events\\events.elf You can't do that when your target is `None' set $pc=0x20000000 No registers. tbreak main Cannot access memory at address 0x200002a4 continue The program is not being run. For me it seems that the arm-none-eabi-gdb.exe has problems to access the controller. Regards, Markus From harald.kipp at egnite.de Tue Feb 21 12:48:50 2012 From: harald.kipp at egnite.de (Harald Kipp) Date: Tue, 21 Feb 2012 12:48:50 +0100 Subject: [En-Nut-Discussion] Ethernut 5 + Eclipse tutorial In-Reply-To: References: <70E051BE-4CD4-48C1-81D3-8AEC4A889653@dr-clauss.de> <4F364D09.9020602@egnite.de> <4F3BF8A4.9020800@egnite.de> <74F54EEB-B219-4776-91AC-C2CEC862D94F@dr-clauss.de> <4F42043C.8000608@egnite.de> <4F429993.3000803@egnite.de> Message-ID: <4F4384A2.9010204@egnite.de> Hi Markus, On 21.02.2012 08:09, Markus Dost wrote: > and the arm-none-eabi-gdb.exe: > > symbol-file C:\\ethernut-4.10\\nutapp\\events\\events.elf > Ignoring packet error, continuing... > warning: unrecognized item "timeout" in "qSupported" response > Ignoring packet error, continuing... > Ignoring packet error, continuing... > Ignoring packet error, continuing... > Ignoring packet error, continuing... > Ignoring packet error, continuing... > Ignoring packet error, continuing... > load C:\\ethernut-4.10\\nutapp\\events\\events.elf > You can't do that when your target is `None' > set $pc=0x20000000 > No registers. > tbreak main > Cannot access memory at address 0x200002a4 > continue > The program is not being run. > > For me it seems that the arm-none-eabi-gdb.exe has problems to access > the controller. Mh...no idea right now. I've updated the webpage http://www.ethernut.de/en/tools/eclipse/confdebug.html Here's my ethernut5.cfg ======================================================================= # We add to the minimal configuration. source [find target/at91sam9260.cfg] # If DCC downloads are enabled, we need a work area. # The configuration line below is intentionally commented, # because this option may fail when code is directly loaded # into internal SRAM. In this case you may provide another # area, a few kB will do. The configuration below will occupy # the complete SRAM. #$_TARGETNAME configure -work-area-phys 0x00300000 -work-area-size 0x8000 $_TARGETNAME configure -event reset-start { # At reset CPU runs at 32.768 kHz. # JTAG Frequency must be 6 times slower if RCLK is not supported. jtag_rclk 5 # For memory access we must halt the CPU halt wait_halt # Optionally enable DCC downloads. If enabled, # a work area must be provided too (see above). # arm7_9 dcc_downloads enable ;# Enable faster DCC downloads # RSTC_MR : enable user reset, MMU may be enabled... use physical address mww phys 0xfffffd08 0xa5000501 } $_TARGETNAME configure -event reset-init { mww 0xfffffd44 0x00008000 ;# WDT_MR : disable watchdog mww 0xfffffc20 0x00004001 ;# CKGR_MOR : enable the main oscillator sleep 20 ;# wait 20 ms mww 0xfffffc30 0x00000001 ;# PMC_MCKR : switch to main oscillator sleep 10 ;# wait 10 ms mww 0xfffffc28 0x2060bf09 ;# CKGR_PLLAR: Set PLLA Register for 198.656 MHz sleep 20 ;# wait 20 ms mww 0xfffffc30 0x00000101 ;# PMC_MCKR : Select prescaler (divide by 2) sleep 10 ;# wait 10 ms mww 0xfffffc30 0x00000102 ;# PMC_MCKR : Clock from PLLA is selected (99.328 MHz) sleep 10 ;# wait 10 ms # Increase JTAG Speed to 6 MHz if RCLK is not supported jtag_rclk 5000 # Fast memory access may fail, when the CPU is running # in slow clock mode. Intentionally disabled by default. # arm7_9 fast_memory_access enable mww 0xfffff870 0xffff0000 ;# PIO_ASR : Select peripheral function for D15..D31 mww 0xfffff804 0xffff0000 ;# PIO_PDR : Disable PIO function for D15..D31 mww 0xffffef1c 0x00010002 ;# EBI_CSA : Assign EBI Chip Select 1 to SDRAM, VDDIOMSEL set for +3V3 memory mww 0xffffea08 0x85227259 ;# SDRAMC_CR : Configure SDRAM (2 x Micron MT48LC16M16A2 : 4M x 16Bit x 4 Banks) mww 0xffffea00 0x1 ;# SDRAMC_MR : issue a NOP command mww 0x20000000 0 mww 0xffffea00 0x2 ;# SDRAMC_MR : issue an 'All Banks Precharge' command mww 0x20000000 0 mww 0xffffea00 0x4 ;# SDRAMC_MR : issue 8 x 'Auto-Refresh' Command mww 0x20000000 0 mww 0xffffea00 0x4 mww 0x20000000 0 mww 0xffffea00 0x4 mww 0x20000000 0 mww 0xffffea00 0x4 mww 0x20000000 0 mww 0xffffea00 0x4 mww 0x20000000 0 mww 0xffffea00 0x4 mww 0x20000000 0 mww 0xffffea00 0x4 mww 0x20000000 0 mww 0xffffea00 0x4 mww 0x20000000 0 mww 0xffffea00 0x3 ;# SDRAMC_MR : issue a 'Load Mode Register' command mww 0x20000000 0 mww 0xffffea00 0x0 ;# SDRAMC_MR : normal mode mww 0x20000000 0 mww 0xffffea04 0x2b6 ;# SDRAMC_TR : Set refresh timer count to 7us # mww 0xFFFFEF00 0x00000003 ;# MATRIX_MRCR : Remap internal SRAM to address 0 } ======================================================================= Here is the at91sam9260.cfg ======================================================================= ###################################### # Target: Atmel AT91SAM9260 ###################################### if { [info exists CHIPNAME] } { set _CHIPNAME $CHIPNAME } else { set _CHIPNAME at91sam9260 } if { [info exists ENDIAN] } { set _ENDIAN $ENDIAN } else { set _ENDIAN little } if { [info exists CPUTAPID ] } { set _CPUTAPID $CPUTAPID } else { # force an error till we get a good number set _CPUTAPID 0x0792603f } reset_config trst_and_srst separate trst_push_pull srst_open_drain # jtag newtap $_CHIPNAME cpu -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id $_CPUTAPID jtag_nsrst_delay 300 jtag_ntrst_delay 200 jtag_rclk 3 ###################### # Target configuration ###################### set _TARGETNAME $_CHIPNAME.cpu target create $_TARGETNAME arm926ejs -endian $_ENDIAN -chain-position $_TARGETNAME -variant arm926ejs # Internal sram1 memory $_TARGETNAME configure -work-area-phys 0x00300000 -work-area-size 0x1000 -work-area-backup 1 ======================================================================= and finally the turtelizer2.cfg ======================================================================= # # egnite Turtelizer 2 # # http://www.ethernut.de/en/hardware/turtelizer/index.html # interface turtle ft2232_device_desc "Turtelizer JTAG/RS232 Adapter" ft2232_layout turtelizer2 ft2232_vid_pid 0x0403 0xbdc8 reset_config srst_only ======================================================================= One thing you may try is to reduce jtag_rclk 5000 to mmmmhhhh... jtag_rclk 1000 Just in case that there are cable problems. Btw. are you using the original red JTAG adapter board with the four header connectors? Regards, Harald From hs at ehse.de Tue Feb 21 14:18:05 2012 From: hs at ehse.de (Hermann Schulz) Date: Tue, 21 Feb 2012 14:18:05 +0100 Subject: [En-Nut-Discussion] En-Nut-Discussion Digest, Vol 100, Issue 14 In-Reply-To: References: Message-ID: <4F2A84D399A34099B82156600364CF41@buerorechner> Hello Rob, have you documented the problems? We also have an interest in our application to upgrade the ATMEGA256 Can you give us some hints? Best Regards Hermann Today's Topics: 1. Re: 2561with more than 128k code and Winavr (PragmaLab (Rob van Lieshout)) Codesize > 128K for the ATMega256 and WinAVR shouldn't be a problem at all. First WinAVR version that dealt correctly with the 128k boundary was 20070525. We still use that one for our (commercial) product (almost 256K used now). Not sure what the problem can be exactly, but if you wish I could send you my makefile. WinAVR 20100110 can be used as well. At the time (must be more then 4 years now), we had lots of problems when we ported our code to the Mega256, but one by one the problems were solved. Regards, Rob From markus.dost at dr-clauss.de Tue Feb 21 14:27:26 2012 From: markus.dost at dr-clauss.de (Markus Dost) Date: Tue, 21 Feb 2012 14:27:26 +0100 Subject: [En-Nut-Discussion] Ethernut 5 + Eclipse tutorial In-Reply-To: <4F4384A2.9010204@egnite.de> References: <70E051BE-4CD4-48C1-81D3-8AEC4A889653@dr-clauss.de> <4F364D09.9020602@egnite.de> <4F3BF8A4.9020800@egnite.de> <74F54EEB-B219-4776-91AC-C2CEC862D94F@dr-clauss.de> <4F42043C.8000608@egnite.de> <4F429993.3000803@egnite.de> <4F4384A2.9010204@egnite.de> Message-ID: <77065E5F-1EC9-4C31-9D12-C99129F17842@dr-clauss.de> Hi Harald, there were some differences between my ethernut5.cfg- and turtelizer2.cfg-files and yours. Mainly in the ethernut5.cfg. But when I use your files the debugging works :-) . Only the console of OpenOCD displays some warnings after starting it: Warn : NOTE! DCC downloads have not been enabled, defaulting to slow memory writes. Type 'help dcc'. Warn : NOTE! Severe performance degradation without fast memory access enabled. Type 'help fast'. And after starting the debugging it puts out: Warn : acknowledgment received, but no packet pending Do I have to worry about these? Thank you very much for your help. Best regards, Markus From harald.kipp at egnite.de Tue Feb 21 14:51:48 2012 From: harald.kipp at egnite.de (Harald Kipp) Date: Tue, 21 Feb 2012 14:51:48 +0100 Subject: [En-Nut-Discussion] Ethernut 5 + Eclipse tutorial In-Reply-To: <77065E5F-1EC9-4C31-9D12-C99129F17842@dr-clauss.de> References: <70E051BE-4CD4-48C1-81D3-8AEC4A889653@dr-clauss.de> <4F364D09.9020602@egnite.de> <4F3BF8A4.9020800@egnite.de> <74F54EEB-B219-4776-91AC-C2CEC862D94F@dr-clauss.de> <4F42043C.8000608@egnite.de> <4F429993.3000803@egnite.de> <4F4384A2.9010204@egnite.de> <77065E5F-1EC9-4C31-9D12-C99129F17842@dr-clauss.de> Message-ID: <4F43A174.5020907@egnite.de> Hi Markus, I further enhanced the debugging page http://www.ethernut.de/en/tools/eclipse/confdebug.html with a new chapter "Solving OpenOCD and GDB Problems" On 21.02.2012 14:27, Markus Dost wrote: > there were some differences between my ethernut5.cfg- and > turtelizer2.cfg-files and yours. Mainly in the ethernut5.cfg. But when > I use your files the debugging works :-) . Mh...may be the Turtelizer/OpenOCD package needs to be updated. In any case http://www.ethernut.de/en/hardware/enut5/openocd.html should help to understand what is going on. > Only the console of OpenOCD displays some warnings after starting it: > > Warn : NOTE! DCC downloads have not been enabled, defaulting to slow > memory writes. Type 'help dcc'. Warn : NOTE! Severe performance > degradation without fast memory access enabled. Type 'help fast'. This is explained on that page in chapter "Optimizing Binary Downloads". > And after starting the debugging it puts out: > > Warn : acknowledgment received, but no packet pending > > Do I have to worry about these? Same here, no idea. Seems to be harmless. > Thank you very much for your help. Thank _you_ for your patience. Sometimes the OpenOCD/GDB/Eclipse combo is a bullheaded bastard, that drives me crazy. But over the time I understand more details and found, that actually everything is running quite well. Anyway, my writing is behind and the documents still need some polishing. Regards, Harald From bon at elektron.ikp.physik.tu-darmstadt.de Tue Feb 21 16:18:09 2012 From: bon at elektron.ikp.physik.tu-darmstadt.de (Uwe Bonnes) Date: Tue, 21 Feb 2012 16:18:09 +0100 Subject: [En-Nut-Discussion] node_cs definition in NUTSPINODE Message-ID: <20291.46513.680158.931408@elektron.ikp.physik.tu-darmstadt.de> Hello, if I understand right, node_cs in the NUTSPINODE structure is a symbolic number that later in xxxSpiChipSelect() gets decoded from a fixed list of possibilities into port/pin and an access to that port/pin combination. Why don't we use both a node_port and node_pin entry in the NUTSPINODE structure and xxxSpiChipSelect() does the access direct on the resulting port/pin combination, at the cost of a NUTSPINODE structure 4 to 7 bytes larger. 4 Bytes larger if the compiler aligns the NUTSPINODE structure at 4 byte, 7 bytes with no alignment in the NUTSPINODE structure. If structure size is an issue, we could also encode port and pin via ((symbolic port number)& 0x0f) << 4 | (pin & 0x0f), in a microsoft like attitude : Nobody will ever use more then 16 ports with 16 pins each :-) or as uint16_t with ((symbolic port number) & 0xff) << 8 | (pin & 0xff) That way, users can have SPI CS on arbitrary pins without the need to change NUTOS. On cm3 node_cs could also be the 32 bit bit-band adress to the GPIOx_BSRR of that port/bit. To set CS high, we would write 1 to that address, to set CS low we would write 1 to the address 64 bytes above. In that light I propose to make node_cs a 32 bits entitie. Bye -- Uwe Bonnes bon at elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- From harald.kipp at egnite.de Tue Feb 21 19:57:21 2012 From: harald.kipp at egnite.de (Harald Kipp) Date: Tue, 21 Feb 2012 19:57:21 +0100 Subject: [En-Nut-Discussion] node_cs definition in NUTSPINODE In-Reply-To: <20291.46513.680158.931408@elektron.ikp.physik.tu-darmstadt.de> References: <20291.46513.680158.931408@elektron.ikp.physik.tu-darmstadt.de> Message-ID: <4F43E911.6090203@egnite.de> Hello Uwe, On 21.02.2012 16:18, Uwe Bonnes wrote: > if I understand right, node_cs in the NUTSPINODE structure is a symbolic > number that later in xxxSpiChipSelect() gets decoded from a fixed list of > possibilities into port/pin and an access to that port/pin combination. That's right. The "fixed" list is configurable, of course. > That way, users can have SPI CS on arbitrary pins without the need to change > NUTOS. After finishing the code, I discovered that passing the chip select number from application code via int NutRegisterSpiDevice(NUTDEVICE * dev, NUTSPIBUS * bus, int cs); was not a good idea. In practice you will configure Nut/OS for a specific board once and never change it. Furthermore, Nut/OS doesn't currently allow to re-use a device. If you got 4 DataFlash chips, you'll need devSpiAt45d0 to devSpiAt45d3. Each SPI bus device has a fixed hardware chip select. > In that light I propose > to make node_cs a 32 bits entitie. My proposal would be to remove the cs parameter and configure the chip select in the device driver. I'm open to arguments, of course. Regards, Harald From ulrich.prinz at googlemail.com Wed Feb 22 17:26:08 2012 From: ulrich.prinz at googlemail.com (Ulrich Prinz) Date: Wed, 22 Feb 2012 17:26:08 +0100 Subject: [En-Nut-Discussion] node_cs definition in NUTSPINODE In-Reply-To: <4F43E911.6090203@egnite.de> References: <20291.46513.680158.931408@elektron.ikp.physik.tu-darmstadt.de> <4F43E911.6090203@egnite.de> Message-ID: Hi! > > was not a good idea. In practice you will configure Nut/OS for a > specific board once and never change it. I fully agree :) > > Furthermore, Nut/OS doesn't currently allow to re-use a device. If you > got 4 DataFlash chips, you'll need devSpiAt45d0 to devSpiAt45d3. Each > SPI bus device has a fixed hardware chip select. > Right, there must be one ICB per used ChipSelect even the SPI bus itself is reused. > >> In that light I propose >> to make node_cs a 32 bits entitie. > > My proposal would be to remove the cs parameter and configure the chip > select in the device driver. > I fully agree, as it is more convenient to do hardware-configuration by qnutconf instead doing some here, some there, some... > I'm open to arguments, of course. Here you got mine :) Ulrich From guillaume.fortaine at devopspace.com Wed Feb 22 22:40:16 2012 From: guillaume.fortaine at devopspace.com (Guillaume Fortaine) Date: Wed, 22 Feb 2012 22:40:16 +0100 Subject: [En-Nut-Discussion] mbed RTOS In-Reply-To: References: Message-ID: Hello, For your information : http://mbed.org/handbook/RTOS#c2681 "Hi Jim, All, FYI, we're now also starting an "official" networking code stack too; we really wanted to have an RTOS in place to allow networking to use a sockets-like interface without the need for polling. Now that is in place, we're on it! More soon... Simon" Best Regards, Guillaume FORTAINE From jose.vallet at aalto.fi Thu Feb 23 07:44:52 2012 From: jose.vallet at aalto.fi (Jose) Date: Thu, 23 Feb 2012 08:44:52 +0200 Subject: [En-Nut-Discussion] node_cs definition in NUTSPINODE In-Reply-To: References: <20291.46513.680158.931408@elektron.ikp.physik.tu-darmstadt.de> <4F43E911.6090203@egnite.de> Message-ID: <4F45E064.9010708@aalto.fi> Hello. Now that you mention CS lines of SPI drivers, one comment. A while ago, before the new SPI drivers (in the 4.6 version), we could not fully use NutOS SPI drivers in our boards because, to our best knowledge, there was not support for decoders in CS lines. That is, we wanted 16 chip select lines from up to 4 pins from the microcontroller. Thus we had to make our own. Let me abuse your knowledge here, so I don't have to check the source code myself(I' a bit rusty ;)): do the new SPI drivers support decoders for the CS lines? If not, it would be a nice feature to have, IMHO. BR Jose On 02/22/2012 06:26 PM, Ulrich Prinz wrote: > Hi! > >> >> was not a good idea. In practice you will configure Nut/OS for a >> specific board once and never change it. > > I fully agree :) >> >> Furthermore, Nut/OS doesn't currently allow to re-use a device. If you >> got 4 DataFlash chips, you'll need devSpiAt45d0 to devSpiAt45d3. Each >> SPI bus device has a fixed hardware chip select. >> > Right, there must be one ICB per used ChipSelect even the SPI bus > itself is reused. >> >>> In that light I propose >>> to make node_cs a 32 bits entitie. >> >> My proposal would be to remove the cs parameter and configure the chip >> select in the device driver. >> > I fully agree, as it is more convenient to do hardware-configuration > by qnutconf instead doing some here, some there, some... > >> I'm open to arguments, of course. > > Here you got mine :) > > Ulrich > _______________________________________________ > http://lists.egnite.de/mailman/listinfo/en-nut-discussion From markus.dost at dr-clauss.de Thu Feb 23 11:20:01 2012 From: markus.dost at dr-clauss.de (Markus Dost) Date: Thu, 23 Feb 2012 11:20:01 +0100 Subject: [En-Nut-Discussion] Ethernut 5: Problem with MMC mounting Message-ID: <296AEE26-B9E4-46B8-9377-DE96FA79B9D9@dr-clauss.de> Hi, I want to use a SD-Card on my Ethernut5-Board and try to mount it with the following code: #ifdef USE_MMCSD int mmc_volume; printf("\nRegister PHAT..."); if (NutRegisterDevice(&devPhat0, 0, 0)){ puts("failed"); } else { puts("OK"); printf("Register %s...", DEV_MMCARD0_NAME); if (NutRegisterDevice(&DEV_MMCARD0, 0, 0)){ puts("failed"); } else { puts("OK"); printf("Mounting MMC-/SD-Card..."); NutThreadYield(); //enable Interrupts mmc_volume = _open(DEV_MMCARD0_NAME ":1/PHAT0", _O_RDWR | _O_BINARY); if (mmc_volume == -1){ printf("failed: error %d\n", errno); } else { puts("OK"); } } } #endif /* USE_MMCSD */ The registrations of the PHAT file system and the MMC-/SD-Card driver work. But the command _open() cannot access my card and fails with the error code 19 (ENODEV). The Nut/OS-Version is 4.10.1 and the card is a Canon SDC-32M with 32 MB. Does anybody have an idea what I've made wrong? Best regards, Markus From bon at elektron.ikp.physik.tu-darmstadt.de Thu Feb 23 11:27:48 2012 From: bon at elektron.ikp.physik.tu-darmstadt.de (Uwe Bonnes) Date: Thu, 23 Feb 2012 11:27:48 +0100 Subject: [En-Nut-Discussion] node_cs definition in NUTSPINODE In-Reply-To: References: <20291.46513.680158.931408@elektron.ikp.physik.tu-darmstadt.de> <4F43E911.6090203@egnite.de> Message-ID: <20294.5284.128644.29814@elektron.ikp.physik.tu-darmstadt.de> >>>>> "Ulrich" == Ulrich Prinz writes: Ulrich> Hi! >> was not a good idea. In practice you will configure Nut/OS for a >> specific board once and never change it. Ulrich> I fully agree :) I disagree: With adrino-like board or the STM32 discovery boards, you have ample pin headers and on a jumper board people would like to connect external SPI devices with their CS_N connected to some arbitray GPIO. But probably in that situation they don't like to do an extra branch of their NUTOS library. And with Jose's question for decoded chip selects even more requirements arise. What if the User could provide his own Stm32SpiChipSelect() function, perhaps by making the Stm32SpiChipSelect() definition in the library __weak__? And with an 32 bit argument to encode the GPIO Pin! >> Furthermore, Nut/OS doesn't currently allow to re-use a device. If >> you got 4 DataFlash chips, you'll need devSpiAt45d0 to >> devSpiAt45d3. Each SPI bus device has a fixed hardware chip select. >> Ulrich> Right, there must be one ICB per used ChipSelect even the SPI Ulrich> bus itself is reused. Think also about the zillion of SPI devices where we don't have a NUTOS driver. Users should be able to use these devices too, even on the same SPI bus as e.g. devSpiAt45d0 with only a diffent CS. Bye -- Uwe Bonnes bon at elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- From ulrich.prinz at googlemail.com Fri Feb 24 11:09:48 2012 From: ulrich.prinz at googlemail.com (Ulrich Prinz) Date: Fri, 24 Feb 2012 11:09:48 +0100 Subject: [En-Nut-Discussion] node_cs definition in NUTSPINODE In-Reply-To: <20294.5284.128644.29814@elektron.ikp.physik.tu-darmstadt.de> References: <20291.46513.680158.931408@elektron.ikp.physik.tu-darmstadt.de> <4F43E911.6090203@egnite.de> <20294.5284.128644.29814@elektron.ikp.physik.tu-darmstadt.de> Message-ID: Hi Uwe, one could see it like this or like that... The problem is that we have to find a compromize between the different options a CPU provides. On some we have GPIO-CS only, on others we have fixed hardware CS and on the third we have not only optional hardware-CS but diffferent modes of it too. I think we have to keep the basic setup features inside qnutconf as these decide the parts of the low level driver that are to be compiled into the library. Then we could make the registration function more Nut/OS standard alike so we provide port and pin as an option instead of a 32bit value that no one knows of how to provide. But then we must add some traps, at least for the debug version of the libraries: If you use an AT91SAM and enable hardware-CS, we must trap a registration to illegal port/pin combinations as only a few pins are provided for CS by this chips. I hope this is a good compromize. Ulrich Am 23. Februar 2012 11:27 schrieb Uwe Bonnes : >>>>>> "Ulrich" == Ulrich Prinz writes: > > ? ?Ulrich> Hi! > ? ?>> ?was not a good idea. In practice you will configure Nut/OS for a > ? ?>> specific board once and never change it. > > ? ?Ulrich> I fully agree :) > > I disagree: > > With adrino-like board or the STM32 discovery boards, you have ample pin > headers and on a jumper board people would like to connect external SPI > devices with their CS_N connected to some arbitray GPIO. But probably in > that situation they don't like to do an extra branch of their NUTOS library. > > And with Jose's question for decoded chip selects even more requirements > arise. What if the User could provide his own Stm32SpiChipSelect() function, > perhaps by making the Stm32SpiChipSelect() definition in the library > __weak__? And with an 32 bit argument to encode the GPIO Pin! > > ? ?>> ?Furthermore, Nut/OS doesn't currently allow to re-use a device. If > ? ?>> you got 4 DataFlash chips, you'll need devSpiAt45d0 to > ? ?>> devSpiAt45d3. Each SPI bus device has a fixed hardware chip select. > ? ?>> > ? ?Ulrich> Right, there must be one ICB per used ChipSelect even the SPI > ? ?Ulrich> bus itself is reused. > > Think also about the zillion of SPI devices where we don't have a NUTOS > driver. Users should be able to use these devices too, even on the same SPI > bus as e.g. devSpiAt45d0 with only a diffent CS. > > Bye > -- > Uwe Bonnes ? ? ? ? ? ? ? ?bon at elektron.ikp.physik.tu-darmstadt.de > > Institut fuer Kernphysik ?Schlossgartenstrasse 9 ?64289 Darmstadt > --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- > _______________________________________________ > http://lists.egnite.de/mailman/listinfo/en-nut-discussion From bon at elektron.ikp.physik.tu-darmstadt.de Sun Feb 26 10:42:28 2012 From: bon at elektron.ikp.physik.tu-darmstadt.de (Uwe Bonnes) Date: Sun, 26 Feb 2012 10:42:28 +0100 Subject: [En-Nut-Discussion] node_cs definition in NUTSPINODE In-Reply-To: References: <20291.46513.680158.931408@elektron.ikp.physik.tu-darmstadt.de> <4F43E911.6090203@egnite.de> <20294.5284.128644.29814@elektron.ikp.physik.tu-darmstadt.de> Message-ID: <20297.65156.609884.709229@elektron.ikp.physik.tu-darmstadt.de> >>>>> "Ulrich" == Ulrich Prinz writes: Ulrich> Hi Uwe, one could see it like this or like that... Ulrich> The problem is that we have to find a compromize between the Ulrich> different options a CPU provides. On some we have GPIO-CS only, Ulrich> on others we have fixed hardware CS and on the third we have not Ulrich> only optional hardware-CS but diffferent modes of it too. Wouldn't a __weak__ linking definition of the NUTOS Stm32SpiChipSelect() function be a good compromise? -- Uwe Bonnes bon at elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- From ulrich.prinz at googlemail.com Mon Feb 27 12:06:46 2012 From: ulrich.prinz at googlemail.com (Ulrich Prinz) Date: Mon, 27 Feb 2012 12:06:46 +0100 Subject: [En-Nut-Discussion] node_cs definition in NUTSPINODE In-Reply-To: <20297.65156.609884.709229@elektron.ikp.physik.tu-darmstadt.de> References: <20291.46513.680158.931408@elektron.ikp.physik.tu-darmstadt.de> <4F43E911.6090203@egnite.de> <20294.5284.128644.29814@elektron.ikp.physik.tu-darmstadt.de> <20297.65156.609884.709229@elektron.ikp.physik.tu-darmstadt.de> Message-ID: I am not sure if that really solves the problems. Ok, in emac we started to implement a cross weak linking. So the emac code provides read and write to phy and the phy provides init and status requests. This is simple as regardless of emac or phy these functions are standarized. With SPI building a standard is difficult as the IPs on the silicons are sometimes totally different. On AVR jou have no CS but have to use manual GPIO. On ARM/Cortex every chip is different. So on SAM7 you can use GPIO, you can use the shadow SPI so you have 4 dedicated and hardware supported CS lines or you can use 1 out of 16 without shadow if you set a decoder behind the 4 CS lines. On STM32 you again have to use GPIO Oh, now I see what you think of! we provide some standarized functions in the main spi driver routine and provide separate CS drivers. Dependant on the nutconf setting the one or the others are linked. I am not sure if that will work as the core spi handling might differ and connect much closer to the CS handling than we expect. Nevertheless we need to provide a cs setup that correspands to our termes. What we have to keep in mind too ist that the SPI bus configuration is highly device dependent. I mean the chip connected on the other end. So setting up the bus is fairly only activating the SPI system, provide clocks to it and select the right alternate pin setups. The real setup is device dependent. So speed, mode, delays whatever is a separate thing. So Stm32SpiChipSelect()... May be we should provide something like this: NutSpiRegister( SPI_BUS); NutSpiAssignDevice( SOME_DEVICE, cs_port, cs_pin, spi_mode, spi_speed); And SOME_DEVICE can be a device that we already provide, but it may be an empty framework that provides a simple read and write functionality too. So one could either use this simple device to work with any SPI slave that he likes in the application code or he might copy that framework and add a new driver that provides more functionality. All that looks more easy to me than uint32_t spi_port = (NUTGPIO_PORTA << 8) | NUT_GPIO_PIN7; int mode = SPI_MODE3; NutSpiRegister( SPI_BUS, &spi_port); _ioctl(SPI_BUS, SPI_SET_MODE, &mode); mode = 100000; _ioctl(SPI_BUS, SPI_SET_SPEED, &mode); and now youre lost as you need to provide a device driver. Ulrich Am 26. Februar 2012 10:42 schrieb Uwe Bonnes : >>>>>> "Ulrich" == Ulrich Prinz writes: > > ? ?Ulrich> Hi Uwe, one could see it like this or like that... > > ? ?Ulrich> The problem is that we have to find a compromize between the > ? ?Ulrich> different options a CPU provides. ?On some we have GPIO-CS only, > ? ?Ulrich> on others we have fixed hardware CS and on the third we have not > ? ?Ulrich> only optional hardware-CS but diffferent modes of it too. > > Wouldn't a __weak__ linking definition of the NUTOS Stm32SpiChipSelect() > function be a good compromise? > > > -- > Uwe Bonnes ? ? ? ? ? ? ? ?bon at elektron.ikp.physik.tu-darmstadt.de > > Institut fuer Kernphysik ?Schlossgartenstrasse 9 ?64289 Darmstadt > --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- > _______________________________________________ > http://lists.egnite.de/mailman/listinfo/en-nut-discussion From bon at elektron.ikp.physik.tu-darmstadt.de Mon Feb 27 15:24:53 2012 From: bon at elektron.ikp.physik.tu-darmstadt.de (Uwe Bonnes) Date: Mon, 27 Feb 2012 15:24:53 +0100 Subject: [En-Nut-Discussion] DEVNUT_M3N: Added board directory for CM3 arch Message-ID: <20299.37429.660346.837110@elektron.ikp.physik.tu-darmstadt.de> Ole, what is the reason to add this directory? ------------------------------------------------------------------------ r3908 | olereinhardt | 2012-02-25 18:23:13 +0100 (Sa, 25. Feb 2012) | 2 Zeilen Added board directory for CM3 arch Don't board specific definitions go into nut/include/arch/[subarch/]board/ ? Or what definitions do go intend to put into nut/arch/cm3/board/ Bye -- Uwe Bonnes bon at elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- From bon at elektron.ikp.physik.tu-darmstadt.de Mon Feb 27 16:07:32 2012 From: bon at elektron.ikp.physik.tu-darmstadt.de (Uwe Bonnes) Date: Mon, 27 Feb 2012 16:07:32 +0100 Subject: [En-Nut-Discussion] Devnut_m3n: Local GIT tree pushed to SVN Message-ID: <20299.39988.561872.265081@elektron.ikp.physik.tu-darmstadt.de> Hello, I just pushed my local Devnut_m3n Git tree to SVN. Areas of work where the extention of Nikolays and Ulrichs work for F1 to STM32L1/STM32F2 and STM32F4 and consolidation of that work. I have tested GPIO/UART/SPI/TWI and small aspects of OTG on different boards. On the F4 Discovery board, I couldn't get the I2C device CS43L22 to acknowledge the I2C address, but on another F4 board with another I2C device I receievd an acknowledge, so this may be F4 Discovery board related. For OTG I only substitued the hardware time used for the UART TX flush by a NUTOS timer. OTG is still picky about the sequence of things happening. E.g. writing to the device while enumeration is still in progress with stall the device. Ulrich, please have a look at how the more flexible L1/F2/F4 remap configuration is implemented and how devices for the different families are handled in general. Some L1/F2/F4 GPIO properities are not mapped yet ( Pull-down, 4 speed option versus 3 speed options on F1). Ole has already a definition for Pull-down for NXP CM3, for the speed option I propose someting like SPEED_SLOW, SPEED_MEDIUM, SPEED_FAST and SPEED_FASTEST with SPEED_SLOW mapped on F1 to SPEED_MEDIUM. Perhaps this is something for Ole and Ulrich to talk about when they perhaps meet on embedded world. Bye -- Uwe Bonnes bon at elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- From ole.reinhardt at embedded-it.de Mon Feb 27 17:59:34 2012 From: ole.reinhardt at embedded-it.de (Ole Reinhardt) Date: Mon, 27 Feb 2012 17:59:34 +0100 Subject: [En-Nut-Discussion] DEVNUT_M3N: Added board directory for CM3 arch In-Reply-To: <20299.37429.660346.837110@elektron.ikp.physik.tu-darmstadt.de> References: <20299.37429.660346.837110@elektron.ikp.physik.tu-darmstadt.de> Message-ID: <1330361974.2153.27.camel@platon> Hi Uwe, > what is the reason to add this directory? > > ------------------------------------------------------------------------ > r3908 | olereinhardt | 2012-02-25 18:23:13 +0100 (Sa, 25. Feb 2012) | 2 Zeilen > > Added board directory for CM3 arch > > > Don't board specific definitions go into > nut/include/arch/[subarch/]board/ > ? > Or what definitions do go intend to put into > nut/arch/cm3/board/ As an example see nut/arch/arm/board/*.c (from trunk) You can put board specific init code in here which will be automaticaly selected during compile time according to the PLATFORM variable configured in the configurator. I need this e.g. to initialise the SDRAM controller and configure board specific I/O pin settings. bye, Ole -- Thermotemp GmbH, Embedded-IT Embedded Hard-/ Software and Open Source Development, Integration and Consulting http://www.embedded-it.de Gesch?ftsstelle Siegen - Steinstra?e 67 - D-57072 Siegen - tel +49 (0)271 5513597, +49 (0)271-73681 - fax +49 (0)271 736 97 Hauptsitz - Hademarscher Weg 7 - 13503 Berlin Tel +49 (0)30 4315205 - Fax +49 (0)30 43665002 Gesch?ftsf?hrer: J?rg Friedrichs, Ole Reinhardt Handelsregister Berlin Charlottenburg HRB 45978 UstID DE 156329280 From guillaume.fortaine at devopspace.com Tue Feb 28 03:29:27 2012 From: guillaume.fortaine at devopspace.com (Guillaume Fortaine) Date: Tue, 28 Feb 2012 03:29:27 +0100 Subject: [En-Nut-Discussion] Webduino In-Reply-To: References: Message-ID: Hello, For your information : https://github.com/sirleech/Webduino "This is an Arduino-based Web Server library, originally developed for a class at NYC Resistor. It's called Webduino, and it's an extensible web server library for the Arduino using the Wiznet-based Ethernet shields. It's released under the MIT license allowing all sorts of reuse. *Features : -URL parameter parsing -Handle the following HTTP Methods: GET, HEAD, POST, PUT, DELETE, PATCH -Web Forms -Images -JSON/RESTful interface -HTTP Basic Authentication" Best Regards, Guillaume FORTAINE From ulrich.prinz at googlemail.com Tue Feb 28 17:02:21 2012 From: ulrich.prinz at googlemail.com (Ulrich Prinz) Date: Tue, 28 Feb 2012 17:02:21 +0100 Subject: [En-Nut-Discussion] Webduino In-Reply-To: References: Message-ID: Hi Guillaume, would you mind stop flooding the mailinglist with this type of 'SPAM'. Most of us are well informed about what's going on in the world of embedded systems, from AVR to CortexA15. We are not living in our own world here and if we need solutions that do not exist in Nut/OS, we ask here... ... and then we might be pleased by receiving links to other sites that present a solution. This is a support request and feature discussion list for Nut/OS, not an embedded world newsletter. Hope, this is ok for you, so thank you for understanding. Ulrich Am 28. Februar 2012 03:29 schrieb Guillaume Fortaine : > Hello, > > For your information : > > https://github.com/sirleech/Webduino > > "This is an Arduino-based Web Server library, originally developed for > a class at NYC Resistor. It's called Webduino, and it's an extensible > web server library for the Arduino using the Wiznet-based Ethernet > shields. It's released under the MIT license allowing all sorts of > reuse. > > *Features : > > -URL parameter parsing > -Handle the following HTTP Methods: GET, HEAD, POST, PUT, DELETE, PATCH > -Web Forms > -Images > -JSON/RESTful interface > -HTTP Basic Authentication" > > Best Regards, > > Guillaume FORTAINE > _______________________________________________ > http://lists.egnite.de/mailman/listinfo/en-nut-discussion