There is a PR scheduled for 5.6.0 that should improve Ethernet on the P2/Photon 2.
2 Likes
You can test the fix here!
nice!
what is the best way to compile and flash our code with these?
thanks
frank
How long until 5.6.0 is released please?
@rickkas7 can you throw in the compile from source instructions? i'm afk
@armor current timeline is nov 27 for 5.6
The easiest way is to use the custom Device OS build option in Workbench. The PR mentioned earlier has been merged into develop so you can just follow the instructions to use that branch. When you use Configure: Project for device be sure to select DeviceOS@source. Also use the Particle: Flash application & DeviceOS (local).
hi @rickkas7
the repository that custom device os build refers to is not accessible?
thanks
frank
frank@Aussimento particle % git clone git@github.com:particle-iot/device-os.git
Cloning into 'device-os'...
git@github.com: Permission denied (publickey).
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
frank@Aussimento particle %
It's public; I think it's just that clone URL format no longer works. Try this instead:
git clone https://github.com/particle-iot/device-os
thanks @rickkas7, also updating the documentation
all seems to build/flash well. but initial quick test does not show any improvement: how can i be sure i am running "the fix"? (System.version() still is "5.5.0")
thanks
frank
hi @marekparticle, @rickkas7,
if i compiled&flashed correctly (let me know how i can check) then "the fix" will not connect per ethernet (unify network). see repository for code and logging
(it still does connect per ethernet shared from my mac)
thanks
frank
btw: using Particle.connect() instead of our connectivity library (based on @rickkas7's) gives the same results - never connects
Can you validate that you flashed the enclosed system part 1 binary -- that's actually all you need here to test. If that's confirmed, I'll bring this back to our engineering team.
@avtolstoy just a note about the above ^.
@marekparticle @rickkas7 @avtolstoy @no1089
second try: here is what i did (see below also):
- flash device-os as delivered by @marekparticle using device-os-flash
- flash our test application (only) using visual studio: Particle: flash application (local)
what i see now is that eventually eth will connect but still much slower than e.g. argon. it takes from half a minute to 2 minutes
see logging (serial-2.log and console-2.log) in the repository
thanks
frank
device-os-flash:
frank@Aussimento release % pwd
/Users/frank/Downloads/particle_device-os@fix-p2-eth-perf-fef71d2bb/p2/release
frank@Aussimento release % device-os-flash --all-devices .
Initializing module cache
Initializing flash interface
Enumerating local devices
Flashing target devices
Target devices:
1. 0a10aced202194944a005484 (P2)
[Device 1] Skipping p2-prebootloader-mbr@fix-p2-eth-perf-fef71d2bb.bin. It's required to be encrypted
[Device 1] Preparing device for flashing
[Device 1] Flashing p2-system-part1@fix-p2-eth-perf-fef71d2bb.bin
[Device 1] Flashing p2-tinker@fix-p2-eth-perf-fef71d2bb.bin
[Device 1] Resetting device
[Device 1] Using control requests to flash remaining modules
[Device 1] Preparing device for flashing
[Device 1] Not allowed
[Device 1] Flashing p2-prebootloader-part1@fix-p2-eth-perf-fef71d2bb.bin
[Device 1] Preparing device for flashing
[Device 1] Not allowed
[Device 1] Flashing p2-bootloader@fix-p2-eth-perf-fef71d2bb.bin
[Device 1] Flashed successfully
Done
frank@Aussimento release %
visual studio:
* Executing task: make -f '/Users/frank/.particle/toolchains/buildscripts/1.13.0/Makefile' flash-user -s
:::: PUTTING DEVICE INTO DFU MODE
Done.
:::: FLASHING APPLICATION
Creating /Users/frank/Code/edge-site-network-test/target/source/p2/memory_platform_user.ld ...
Creating /Users/frank/Code/edge-site-network-test/target/source/p2/memory_platform_user.ld ...
text data bss dec hex filename
20318 124 542 20984 51f8 /Users/frank/Code/edge-site-network-test/target/source/p2/edge-site-network-test.elf
dfu-suffix (dfu-util) 0.9
Copyright 2011-2012 Stefan Schmidt, 2013-2014 Tormod Volden
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/
Suffix successfully added to file
Serial device PARTICLE_SERIAL_DEV : not available
Flashing using dfu:
dfu-util 0.9
Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/
Opening DFU capable USB device...
ID 2b04:d020
Run-time device DFU version 011a
Claiming USB DFU Interface...
Setting Alternate Setting #0 ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 011a
Device returned transfer size 4096
DfuSe interface name: "Internal Flash "
Downloading to address = 0x085fb000, size = 20480
Download [=========================] 100% 20480 bytes
Download done.
File downloaded successfully
Transitioning to dfuMANIFEST state
*** FLASHED SUCCESSFULLY ***
* Press any key to close the terminal.
@boddeke -- are you able to reproduce in another environment? we're unable to -- for example, can you try using a laptop + eth and sharing laptop internet connection? the fact that the DTLS handshake is taking so long (20 seconds!) points to some high packet loss which could be WAN or LAN issue -- but it doesn't look like a DeviceOS problem.
these are the results (see repository):
- serial-2.log: connected to unify switch: takes half minute up to 2 minutes
- serial-argon.log: same but with argon: takes less than 6s
- serial-mac.log: connected to eth-dongle mac with internet sharing: takes less than 20s
my conclusion:
- same code on argon works well (as does any other wired device on the network) -- network is fine
- same hardware on different lan works well (still slow though) -- hardware is fine
maybe @armor and/or others can test as well?
@marekparticle @rickkas7 @avtolstoy @no1089
we do need to know this issue will be fixed. we must have reliable ethernet with whatever netwerk our users plug into (well, as long as there is internet connectivity)
we experimented quite a bit with the argon and that worked very reliable. we did not have any trouble with any network we tested it on and do expect this from the p2 as well
we now get a bit the feeling that it will not get fixed?!
@no1089 - let's speak about this in Triage today.
@boddeke - unfortunately we cannot reproduce the phenomenon you are describing, though the logs are very helpful. As I mentioned in the other thread, it might be useful to set up a call.