CC3K: Not working since merge #885

thomasvnl · 2014-09-30T11:35:29Z

Since the master branch got merged with the the iabdalkader-cc3k-update CC3K is no longer working the way it did before. I have enabled CC3K in mpconfigport.mk but that didn't do much good. I tried replacing MICROPY_HW_ENABLE_CC3K with MICROPY_PY_CC3K in stmhal/pybwlan.c but that too failed the moment it tried to import the first item of the required headers in stmhal/pybwlan.c. Anyone have any thougts on this?

thomasvnl · 2014-09-30T11:45:49Z

I want to mention that I found the import cc3k CC3k (why the small k, extremely confusing) which isn't mentioned anywhere except in a previous issue. Could you please add this kind of documentation so that people who aren't that acquainted with github still know what changed / and hopefully what they are doing :) ( a PIN out for the CC3K would be nice I suppose).

dpgeorge · 2014-09-30T11:54:26Z

The internet modules (cc3k and wiznet) are still work in progress, pending a decision in #876. Their initialisation will be easier and documented, and binaries will be available with these driver compiled in.

Re naming: all classes are named using camel case, but acronyms make this a bit tricky sometimes. The class would have been CC3000, but it's also supposed to support CC3100 (eventually). CC3k was chosen since it encompases both. Think of 3000 as a word, which in camel case has the 3 upper and the 000 lower, hence it becomes 3k :) I also don't like typing it, but I have no better ideas that keep consistency. We can make it CC3K if people prefer.

thomasvnl · 2014-09-30T12:24:22Z

Okay, then I suppose we're just going to wait on continuing our IoT project with the Micro Python board. That's probably going to save us from a lot of hassle :P Thanks for the quick reply and happy coding.

dpgeorge · 2014-09-30T13:05:37Z

Keeping this issue open because it is a real issue that needs to be solved.

thomasvnl · 2014-09-30T14:47:08Z

Alright, if anything changes I'll know, receiving updates from this repository from now on ;)

dpgeorge · 2014-09-30T23:27:29Z

CC3000 and WIZ820io support are now "working" on master branch, and firmware binaries will be available each night at micropython.org/download. There is a separate firmware with network drivers included.

Quick example:

import pyb
import network
cc3k = network.CC3k(pyb.SPI(1), pyb.Pin('X5'), pyb.Pin('X4'), pyb.Pin('X3'))
cc3k.connect('ssid', 'password')

That sets up the network. You need to have the CC3000 connected on pins X3 through X8: X3=IRQ, X4=EN, X5=CS, X6=SCK, X7=MISO, X8=MOSI.

Wait for an IP address (call cc3k.is_connected()) then use socket as you normally would:

import socket
addr = socket.getaddrinfo('micropython.org', 80)
s = socket.socket()
s.connect(addr[0][-1])
s.send('GET /\r\n\r\n')
s.recv(1024)
s.close()

pfalcon · 2014-10-02T08:39:11Z

import socket

So, is it "socket" or "usocket" after all?

dpgeorge · 2014-10-02T09:57:11Z

So, is it "socket" or "usocket" after all?

Haha, a loaded question :)

It's actually available as both socket and usocket. I have an idea that I was testing and wanted to discuss: prefix all uPy builtin modules with u (uos, usys, utime, ...) and then provied a weak reference to them with the corresponding non-u name (nothing to do with CPython weakref modul, but rather link-editor-style weakref). The weak reference can be overridden by providing your own version of the module (as a file), if wanted. Without overridding, eg, import os will resolve to uos and then uos is a decent enough substitution (a micro substitution) for a full os module.

This way: 1) we are free to provide micro implementations of all modules, unencumbered by any CPython bloat, but with the broad aim that the u-module can be used in place of the non-u-module in >90% of cases; 2) users don't need to change their habits or code and can just use, eg, import os; 3) users can easily install a full (or more full) module by having the corresponding module.py script in their sys.path, and this module overrides the weakref to the u-module.

The main issue with this is efficiency. At the moment, all builtin modules (eg sys) are returned straight away from the import machinery, without searching the filesystem. To implement weakref imports, one needs first to search the filesystem for any overrides, and only if not found is the weakref followed.

thomasvnl · 2014-10-03T11:09:58Z

Thanks for fixing and closing the issue. Looks like a straightforward way to do this so good job on that!

dpgeorge · 2014-10-03T11:24:01Z

@thomasvnl : let me know how it goes for you. There are probably a few bugs and things to tidy up in the interface, but otherwise it should work ok (as well as the CC3k hardware will allow!).

thomasvnl · 2014-10-03T11:24:55Z

Will do

roger- · 2014-10-04T21:33:59Z

@dpgeorge

I have an idea that I was testing and wanted to discuss: prefix all uPy builtin modules with u (uos, usys, utime, ...)

Great idea :)

provied a weak reference to them with the corresponding non-u name

I think it's better to do that only if the module is complete and compatible with CPython, otherwise people are gonna keep expecting functionality that just isn't there.

pfalcon · 2014-10-11T13:35:56Z

It's actually available as both socket and usocket.

I see, so currently for stmhal you have:

    { MP_OBJ_NEW_QSTR(MP_QSTR_usocket), (mp_obj_t)&mp_module_usocket }, \
    { MP_OBJ_NEW_QSTR(MP_QSTR_socket), (mp_obj_t)&mp_module_usocket }, \

prefix all uPy builtin modules with u (uos, usys, utime, ...)

Well, I'm in favor of this, to let them be overriden by (more) complete Python implementation, I even proposed to rename stmhal's os to _os.

and then provied a weak reference to them with the corresponding non-u name. The weak reference can be overridden by providing your own version of the module (as a file), if wanted.

Yeah, but how to implement that? For it to work automagically, as you say, it would first need to scan filesystem. As you say, it's drop in efficiency. It's also unclear how exactly to implement it - in some adhoc, hardcoded way? That will at least cost us minimum amount of bytes, but adhoc stuff in import code won't be too beautiful. More generic solution is to add some kind of "import hooks" or whatever CPython has, but that will cost even more bytes (and I kinda start to worry that with all such additions we'll stop being "micro" soon).

So, I don't know, let me be skeptical on this one ;-). I think we can at least start with having non-complete builtin modules be named differently, but not worry that people will need to use these different names if they want highest efficiency. Of course, this outlook is based on "unix" port needs, not on "stmhal" one, so I understand if you don't agree.

dpgeorge · 2014-10-11T18:13:41Z

I even proposed to rename stmhal's os to _os.

Or uos? _os should be reserved for a full CPython _os module :) For us, we should use _uos if we implement a cut down uos to be augmented by a uos.py script. But already the philisophy is to have uos a micro version of os, that is usable without any wrapper.

As you say, it's drop in efficiency.

Yes, but then users can import os and it'll just work (using uos as a fallback). They can do import uos if they want efficiency. There's no way (that I see) to have efficiency (no scanning filesystem), extensibility (can override module with script), and ease of use (ability to import os without having os.py in the filesystem).

It's also unclear how exactly to implement it - in some adhoc, hardcoded way?

It can be an option in the core: if enabled, just need 1 other dict of weak refs (mp_builtin_weak_module_dict_obj, that is provided by a given port) which is scanned only if a search of the filesystem fails.

I think we can at least start with having non-complete builtin modules be named differently, but not worry that people will need to use these different names if they want highest efficiency.

Right, and if they don't care about efficiency, weak ref is there to allow them to import os and it'll just work.

On pyboard, a scan of the internal filesystem is pretty cheap (since fs is in ROM).

By having the weak ref as a port option, we can use it only in stmhal, and have unix use scripts (eg os.py) in a library directory to provide non-u modules.

The weak ref thing is really not that ad-hoc if you think of it this way: there is a (hidden) path in the import search path that is very last, and it is simply a (fake) directory of (virtual) wrapper scripts like os.py than do from uos import *.

pfalcon · 2014-10-12T12:46:54Z

I even proposed to rename stmhal's os to _os.
Or uos? _os should be reserved for a full CPython _os module :)

I guess then it's worth to discuss policy for "" vs "u" prefix too. "" policy is essentially laid out in CPython - if a module is not intended for direct user use, it has "" prefix. So, all "" modules are internal and it's implementation-dependent which are available, and what's inside. CPython3 for example doesn't have _os. uPy has _collections, which implements just a particular collection class (the rest are intended to be implemented in Python). Unix port has _os, which has just a single function.

On the other hand, "u" modules are intended for direct use, and thus all stmhal modules indeed should have "u" prefix.

dpgeorge · 2014-10-12T13:01:28Z

Agreed with all points made in above comment. Then it's up to the port to follow this policy (_ for internal, u for direct use) and to make a decision for each specific module it provides.

rev E feather M4 express; remove named AREF pins

thomasvnl closed this as completed Sep 30, 2014

dpgeorge reopened this Sep 30, 2014

dpgeorge closed this as completed Sep 30, 2014

tannewt added a commit to tannewt/circuitpython that referenced this issue Jun 1, 2018

Merge pull request micropython#885 from dhalbert/feather_m4_reve

0950415

rev E feather M4 express; remove named AREF pins

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!

CC3K: Not working since merge #885

CC3K: Not working since merge #885

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

CC3K: Not working since merge #885

CC3K: Not working since merge #885

Comments

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!