@livius said in boot.py iterpreted or precompiled?: but with whole code you got nothing ont the uart I ran your code on my LoPy and I don't get any output after the two dhcp start lines. I guess this is a bug in the firmware that PyCom should look at though I'd argue they have bigger things to do right now. :)

OK. So I updated the firmware using the same FTDI cable attached to P0 (RX) and P1 (TX), with jumper for safe mode. Am now at release 0.9.3.b2, version d78a5a3 2016-11-05. uart shows up as 0 at 115200, which is the REPL port. Was able to hook the FTDI cable up to P3 (TX) and P4 (RX) and create a uart1 object using uart1=UART(1, baudrate=115200). I was able to send characters to the port and receive from it. What I really wanted was the REPL port though, so I switched the FTDI cable back to P0 and P1 and it is working as expected.

I did it, check this: https://github.com/micropython/micropython-lib/issues/115

I've had a look at the code... Timers are not yet implemented so this code will not yet work. Also your init should use correct pin names, example: 'P5', 'P6' etc.

Not that I can see from looking at the current documentation.

@abilio said in WIPy 2.0 arrived- can't see it on MacBook Pro running Mavericks: Can you try a Windows 10 machine, or a linux machine (even in virtualbox will be ok) in order to dismiss the last option?. We just need to see if the board is detected or not. I'll try installing the FTDI USB driver manually. I've mentioned in another post that I was able to update the FW using a Windows machine. So, we know that the hardware on the Wipy is working. BTW- Do I also need the G23-GND jumper on the Mac? If so, then I didn't have that installed when I plugged the WiPy in before. I'm sorry I cannot try it myself, but we don't have any Mavericks computer available at our offices. I'll be waiting for your feedback. Can you try installing Mavericks in a VM?

@abilio I can confirm that my boot.py survives rebooting and that I'm running the most recent version of the firmware. Indeed, it appears that my boot.py is running, and that I had a syntax error on the line: server = Server(login=('user', 'password'), timeout=60) where I had specified a new user/pwd pair. I had thought that my boot.py wasn't running because the device came up with a server running with uid, pwd = 'micro', 'python', the default. Strange.

Yeah @arikb, you're certainly right that the feedback from the script is actually valuable. In future versions we will try to make it appear in the results.

@abilio I've tried the update again (on Windows),, it worked this time. I think there was a sequencing issue the first few times, because I didn't understand the process. How can we get in touch with the developers? They really should have a jumper on the board for doing the FW updates. It's too risky connecting a jumper manually each time. There is plenty of room for additional jumpers on the board. Thanks for your help!

It doesn't work on Mavericks. When I double click on the app, the GUI never appears. :(

@littlebat said in Which firmware update to use for WiPy?: The first one is for wipy v1.0 and the second one is for wipy v2.0. Different hardware. Thanks. I wish the websites would be clearer about this.

Fringe benefit of the flash bug & full update means I can now run the wipy firmware successfully on the devkitc board, just had to change to dio flash mode.

@Xykon Is that 20161104 or 20160411 ? Only joking but ISO format dates are always less confusing than other number formats when the day of the month and the month number can be confused.