Hi, Yes, I noticed myself when this morning that most packets disappear somewhere, the software answers only occaisionally. I even suspected that it wouldn't work at all. DI haven't had a chance to really test it myself, but will continue later today, when I'll arrive back at Otaniemi. Anyway, the faulty functionality is somehow due to the refactorings (we still don't have a proper covering test suite), and most probably some small bug somewhere. --Pekka On 2014–05–29, at 16:54 , Olli Vanhoja <olli.vanhoja@xxxxxxxxxxx> wrote: > Hi, > > Is there any changes to ARP in your branch? I'm asking because ARP in the > branch I'm currently using works quite poorly. > > Another issue is that some times responses get delayed by one message and it > doesn't seem to catch up on that. i'm not sure where this happen but I > suspect it happens somewhere in the ethernet library. > > BR, > Olli Vanhoja > > On May 29, 2014 7:13:40 AM EEST, Pekka Nikander <pekka.nikander@xxxxxx> wrote: > I managed to fix the compilation problem in the latest version of CoAP on my > Mac. > > I have now pushed the commit to the feature-coap-temp branch: > > https://github.com/Ell-i/Runtime/commit/1389b8a33b42275e07b71060b3c15268bda224ce > > To compile this version, check it out and then > > cd stm32/libraries > make > cd ../tests > make > > You should get a binary like the following: > > -rw-r--r--+ 1 pnr staff 15237 May 29 06:53 > test_CoAP_no_threads/test_CoAP_no_threads.hex > > That should run on an Ellduino board, with the instructions from here: > > //www.freelists.org/post/ell-i-developers/Outline-and-guide-for-IPUDP-testing > > Please note however that ARP *does* (should :-) work, so ! > you > don't need to configure a static ARP address. > > > See you in about an hour there in Otaniemi; I may come a little bit after > eight, depending on the kids. > > Mostly for those who followed my second tutorial yesterday, the problem was > that the compiler constant propagation failed (without any obvious reason) > for two statically allocated C++ objects in the SPI library. I fixed that > more-or-less temporarily with renaming > stm32/libraries/SPI/src/SPIInitSTM32F0.cpp to > stm32/libraries/SPI/src/SPIInitSTM32F0.cppinc, and then including that into > stm32/libraries/SPI/src/ellduino_spi.cpp instead of compiling them as two > separate objects and using the linker to fix the symbols. > > (I also needed to split off the SpiMaps into a separate compilation unit. > They are used only in the Arduion C++ API. Hence, it is likely that if you > try to use the Arduino C++ API, you will get linking errors. That remains to > be fixed later on.) > > --Pekka > > PS. F! > eel free > to forward this message to those people who were interested but may not be on > the mailing list. I didn't get their names; my apologies. > > > PPS. You can follow commits at the twitter channel @Ell_i_dev > >
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
