[Ovmsdev] python 2 / pyserial 3

Michael Balzer dexter at expeedo.de
Sun Feb 25 03:51:50 HKT 2018


Stephen,

today I've learned something about python… ;)

My distribution (openSuSE 42.3) still uses python2 as the base version, and python3 is also installed to enable transition.

I thought I had installed pyserial-3.4 by doing "pip install --uprade pyserial" -- because it told me I had done so:

leela:~ # pip install --upgrade pyserial
Collecting pyserial
  Using cached pyserial-3.4-py2.py3-none-any.whl
Installing collected packages: pyserial
    Uninstalling pyserial-2.7:
      Successfully uninstalled pyserial-2.7
Successfully installed pyserial-3.4

But it now turned out it only installed the update for the python3 environment, while python2 still used pyserial 2.7. Apparently "pip" is only installed for
the python3 environment.

After doing a manual update on the python2 pyserial package, the script now works. So for anyone with a similar setup/issue, do this:

- download the tar.gz from https://pypi.python.org/pypi/pyserial
- tar xzf pyserial-3.4.tar.gz
- cd pyserial-3.4
- python setup.py install

"make monitor" now also works.

Btw: according to…
  https://stackoverflow.com/questions/6908143/should-i-put-shebang-in-python-scripts-and-what-form-should-it-take
…the shebang "#!/usr/bin/env python" should not be used.

Regards,
Michael


Am 24.02.2018 um 17:58 schrieb Stephen Casner:
> Michael,
>
> I hope you have figured out your python version.  Indeed the
> findcp2102.py code has a dependency on version 3, but since there was
> a check elsewhere in the esp-idf make process already I figured this
> was safe.
>
>                                                         -- Steve
>
> On Sat, 24 Feb 2018, Michael Balzer wrote:
>
>> Something's wrong with my python setup. The documentation says pyserial changed from tuples to objects in version 3, I've got 3.4 and apparently still get tuples.
>>
>> I remember doing an update on pyserial in order to get miniterm running. The update didn't help but seemed to be successfull. I now think it actually wasn't.
>>
>> Time for a reinstall...
>>
>>
>> Am 24.02.2018 um 10:45 schrieb Michael Balzer:
>>> Is there a specific requirement for the findcp2102 tool?
>>>
>>> balzer at leela:~/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3> make
>>> Traceback (most recent call last):
>>>   File "/home/balzer/esp/esp-idf/tools/findcp2102.py", line 47, in <module>
>>>     pl.sort(key=lambda x: x.location, reverse=False)
>>>   File "/home/balzer/esp/esp-idf/tools/findcp2102.py", line 47, in <lambda>
>>>     pl.sort(key=lambda x: x.location, reverse=False)
>>> AttributeError: 'tuple' object has no attribute 'location'
>>>
>>> balzer at leela:~/esp/esp-idf> python -m serial.tools.list_ports -v "USB VID:PID=10c4:ea60"
>>> Filtered list with regexp: 'USB VID:PID=10c4:ea60'
>>> /dev/ttyUSB0
>>>     desc: Silicon Labs CP2102 USB to UART Bridge Controller 0001
>>>     hwid: USB VID:PID=10c4:ea60 SNR=0001
>>> 1 ports found
>>>
>>> balzer at leela:~/esp/esp-idf> python --version
>>> Python 2.7.12
>>>
>>> leela:~ # pip freeze | grep -i serial
>>> pyserial==3.4
>>>
>>> I've tried running it with python3.4, but that throws syntax errors.
>>>
>>> Michael
>>>
>>>
>>> Am 24.02.2018 um 09:10 schrieb Stephen Casner:
>>>> OK, I have merged the latest commits from espressif/esp-idf/master
>>>> into our fork openvehicles/esp-idf/master and merged the corresponding
>>>> update to ovms_module to match the changed API for getting per-task
>>>> heap info.
>>>>
>>>> This means developers need to update both ESP IDF and OVMS v3 source
>>>> trees (borrowing the lines from Mark's message about mDNS update):
>>>>
>>>> cd  ~/esp/esp-idf                                                                        git pull
>>>> git submodule update
>>>>
>>>> cd ~/ovms/vehicle/OVMS.V3
>>>> git pull
>>>> make
>>>>
>>>> (changing paths as appropriate)
>>>>
>>>> Also included is a fix for the "module tasks" command to show the
>>>> stack size correctly again.  That breakage was apparently caused by a
>>>> change in the compiler behavior when espressif recently updated the
>>>> toolchain for the esp-idf.
>>>>
>>>>                                                         -- Steve
>>>>
>>>>
>>>> On Sat, 24 Feb 2018, Mark Webb-Johnson wrote:
>>>>
>>>>> Ok. Got for it.
>>>>>
>>>>> Regards, Mark
>>>>>
>>>>>> On 24 Feb 2018, at 8:40 AM, Stephen Casner <casner at acm.org> wrote:
>>>>>>
>>>>>> My PR for heap task tracking has now been merged into espressif/esp-idf/master.
>>>>>> Shall I merge to openvehicles/esp-idf/master and merge the corresponding update
>>>>>> to ovms_module?
>>>>>>
>>>>>> Also, I have pushed a little cleanup commit.  I assume that need not be
>>>>>> mentioned in the changes.txt file.
>>>>>>
>>>>>>                                                        -- Steve
>>>>>>
>>>>>>> On Tue, 20 Feb 2018, Stephen Casner wrote:
>>>>>>>
>>>>>>> I can wait on these things.  Tonight my PR got the "changes approved"
>>>>>>> checkmark.
>>>>>>>
>>>>>>> https://github.com/espressif/esp-idf/pull/1498#pullrequestreview-88994221
>>>>>>>
>>>>>>>                                                        -- Steve
>>>>>>>
>>>>>>> On Wed, 21 Feb 2018, Mark Webb-Johnson wrote:
>>>>>>>
>>>>>>>>> Would you like me to merge the code to openvehicles/esp-idf and
>>>>>>>>> openvehicles/Open-Vehicle-Monitoring-System-3 now?
>>>>>>>> I don't think we are in a hurry for this. What we have now works (since I updated our clone to latest espressif master and brought in their latest SPI RAM fixes).
>>>>>>>>
>>>>>>>> Can we just wait until it is accepted, and then deal with the merge then?
>>>>>>>>
>>>>>>>>> Also, I have not done anything to add (optional) immediate sending
>>>>>>>>> back into Mongoose.
>>>>>>>> That (mongoose) is on my list for moving to SPI RAM. That should reduce the impact of this.
>>>>>>>>
>>>>>>>> Not sure if we still need the immediate sending option. What do you think? If we do, it can be made to our clone of mongoose.
>>>>>>>>
>>>>>>>> Regards, Mark.
>>>>>>>>
>>>>>>>>> On 21 Feb 2018, at 10:52 AM, Stephen Casner <casner at acm.org> wrote:
>>>>>>>>>
>>>>>>>>> Mark,
>>>>>>>>>
>>>>>>>>> As I mentioned in an earlier email, the API for the function call to
>>>>>>>>> gather per-task heap allocation information has changed as part of the
>>>>>>>>> process of getting the feature added to the mainline.  That change
>>>>>>>>> currently sits in the "review & merge queue" which is also subject to
>>>>>>>>> delay due to Chinese New Year.
>>>>>>>>>
>>>>>>>>> Would you like me to merge the code to openvehicles/esp-idf and
>>>>>>>>> openvehicles/Open-Vehicle-Monitoring-System-3 now?
>>>>>>>>>
>>>>>>>>> Presuming that the code is accepted after review and merged, I'm not
>>>>>>>>> sure what will happen when we merge that change in from the mainline
>>>>>>>>> at a future date.  Angus said he "cherry-picked this and squashed the
>>>>>>>>> commits with a couple of minor tweaks for compilation warnings in
>>>>>>>>> certain configurations."  This the merge might not go automatically.
>>>>>>>>>
>>>>>>>>> Also, I have not done anything to add (optional) immediate sending
>>>>>>>>> back into Mongoose.  I have not heard of anyone hitting out-of-memory
>>>>>>>>> crashes when using SSH with a large burst of output, which is the
>>>>>>>>> concern that led me to make the change before when I hit the problem
>>>>>>>>> during debugging.  Maybe with SPIRAM it is not an issue. SCP is
>>>>>>>>> already safe because it does one buffer at a time.
>>>>>>>>>
>>>>>>>>>                                                       -- Steve
>>>>>>>>>
>>>>>>>>>> On Wed, 21 Feb 2018, Mark Webb-Johnson wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> My v3.1 test board seems stable, and we are ready for hardware production. I'm ordering the components with relatively long lead times (weeks) now, and the production order will go in as soon as China comes back from holiday (next week). First hardware batch will be available during March. I know lots of people are waiting for this, but I have to balance that against risk (should some hardware issue be found during wider real-world testing). I currently plan to order 120 modules (including 60 USA 3G modems, and 60 EU 3G modems) for the first batch. 100 will go to FastTech (for general ordering), and 20 to me (for special cases). As with OVMS v1, we'll clearly say these are early units for 'technically capable' people, and the firmware still has a way to go.
>>>>>>>>>>
>>>>>>>>>> On the firmware side, we need to move to a production style release cycle, and I will need to provide the first 'factory' firmware around the second week of March. Accordingly, I'm setting up some clean build environments and OTA release repositories (so I can cleanly build v3.0 and v3.1 firmware and have it available for OTA download).
>>>>>>>>>>
>>>>>>>>>> I have created a changes.txt log file in the root of the project. I would appreciate it if those with commit access to master could update that file when they merge/commit changes to the project. The top of the file will contain an entry for the 'next' version, so the change text just needs to be added below that. When the version is ready to go, I will update changes.txt with the date and name, commit it, tag it, and then build OTA versions for release. Please only use tags for OTA versions - or just don't tag at all for the moment and let me maintain this.
>>>>>>>>>>
>>>>>>>>>> The last list of things I have for this build are:
>>>>>>>>>>
>>>>>>>>>> OTA via HTTP. SD CARD firmware updates seems to work fine today, as does serial flashing. I've still got to make the changes to HTTP firmware updates to use mongoose and support the new ESP IDF v2.1+ firmware arrangement of putting the checksum at the end of the firmware file.
>>>>>>>>>>
>>>>>>>>>> We need some simple high-level configs for auto-starting things. Stuff like vehicle type, whether the v2 server should auto-run, etc. Make it simpler for people to configure, without having to use scripts. This can be mapped to v2 protocol parameters/features.
>>>>>>>>>>
>>>>>>>>>> SPI RAM support and stability for v3.1 hardware (as well as compatibility with v3.0 hardware).
>>>>>>>>>>
>>>>>>>>>> Finalise the partition sizes. I think we can squeeze a bit more (maybe 3x 5MB firmwares, plus 512KB store?).
>>>>>>>>>>
>>>>>>>>>> End-User Documentation.
>>>>>>>>>>
>>>>>>>>>> Real-world stability (in cars).
>>>>>>>>>>
>>>>>>>>>> My concern is to have a relatively stable firmware that is usable for technically capable end-users in their cars, but also to have a way for them to simply update the firmware to keep pace with the fast release cycle we expect (at least in the coming months).
>>>>>>>>>>
>>>>>>>>>> Anything I've missed?
>>>>>>>>>>
>>>>>>>>>> Regards, Mark.
>>>>>>> _______________________________________________
>>>>>>> OvmsDev mailing list
>>>>>>> OvmsDev at lists.teslaclub.hk
>>>>>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>>>>>>>
>>>>>>>
>>>>>> _______________________________________________
>>>>>> OvmsDev mailing list
>>>>>> OvmsDev at lists.teslaclub.hk
>>>>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>>>>> _______________________________________________
>>>>> OvmsDev mailing list
>>>>> OvmsDev at lists.teslaclub.hk
>>>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>>>>>
>>>>>
>>>> _______________________________________________
>>>> OvmsDev mailing list
>>>> OvmsDev at lists.teslaclub.hk
>>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>> --
>> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
>> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>>
>>
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.teslaclub.hk
>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>>
>>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

-- 
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26




More information about the OvmsDev mailing list