micropython and sys.implementation- different on XIAO SAMD21 and XIAO RP2040 - micropython

I was working with micropython on a SEEED XIAO (SAMD21) using version 1.18, and wanted to use 'compiled' libraries (.mpy) to conserve space. I had mpy-cross for version 5 which worked okay for me. I also wanted to have floating point so I built a new micropython with that option- from the latest (20220302) github version- and noticed that mpy-cross had updated to version 6. I thought I would check to see which versions of .mpy were used The micropython documentation suggests some code to check the version of .mpy using the sys.implementation object. I noticed a variety of sys.implementation implementations.
Version 1.18- released by micropython 20220117 on the XIAO SAMD21 gave the following results:
MicroPython v1.18 on 2022-01-17; Seeed Xiao with SAMD21G18A
Type "help()" for more information.
>>> import sys
>>> sys.implementation
('micropython', (1, 18, 0))
>>> type(sys.implementation)
<class 'tuple'>
>>>
This returned a tuple with 2 items- the name and a tuple with the version info. But no information on the mpy version.
I then tried the released 1.18 version for the RP2040 NANO (and ran it on my XIAO RP2040):
MPY: soft reboot
MicroPython v1.18 on 2022-01-17; Raspberry Pi Pico with RP2040
Type "help()" for more information.
>>> import sys
>>> sys.implementation
(name='micropython', version=(1, 18, 0), mpy=5637)
>>> type(sys.implementation)
<class 'tuple'>
>>>
Here the result returned is tuple with 3 attributes- named attributes- and a mpy version (5637 & 0xff = 5). I then recompiled micropython using the #define MICROPY_PERSISTENT_CODE_LOAD (1) option to try and match the RP2040 output:
MPY: soft reboot
MicroPython v1.18-169-g665f0e2a6-dirty on 2022-03-02; Seeed Xiao with SAMD21G18A
Type "help()" for more information.
>>> import sys
>>> sys.implementation
('micropython', (1, 18, 0), 6)
>>> type(sys.implementation)
<class 'tuple'>
>>>
Now a tuple with 3 items is returned with the mpy version (6), but not a named tuple, and no extra data with the mpy version.
My question is how can I get consistent results in my XIAO SAMD2 implementation? Which option should I include or exclude? Or should I not worry it? I am studying whether to switch to Python or stay with C(++) for this small processor - leaning to C(++).
Thank you

If you want to use precompiled/bytecode .mpy files then you will need to
Decide to use either bytecode or compile to native code for your mcu platforms.
For bytecode you will need to distribute a bytecode version that matches the runtime firmware, 1.12-1.18 == 5, next version will increase
For native code you'll need to distribute versions for each platform that you want to support.
An esp32c3 cannot run stm32 native code and vice-versa
Also the different ports/board will indeed have differences in some of the stdlib APIs. Your code must be robust enough to handle these differences.

Related

No library found for processing.io error error when running Processing code in raspberrypi

I am trying to run a Sketch program using Processing 4.0. The code is from FreeNove raspberrypi kit.
I am getting this error
No library found for processing.io
No library found for processing.io
No library found for processing.io
Libraries must be installed in a folder named 'libraries' inside the sketchbook folder (see the Preferences window).
The package “processing.io” does not exist. You might be missing a library.
The code is snippt which seem to include processing.io is
/*****************************************************
* Filename : Sketch_09_1_1_Motor
* Description : Control speed and direction of the motor
* auther : www.freenove.com
* modification: 2016/08/22
*****************************************************/
import processing.io.*;
int motorPin1 = 17; //connect to the L293D
int motorPin2 = 27;
int enablePin = 22;
final int borderSize = 45; //border size
Strange, normally Processing ARM should ship with the processing.io library.
If the install method the Freenove manual provides (curl https://processing.org/download/install-arm.sh | sudo sh) doesn't work,
I recommend trying the official Download page and selecting the Raspberry PI CPU architecture that fits (32 or 64 bit).
In the past I had success using the Processing 3 Raspberry PI Image (which has Processing preinstalled): this could be a backup plan if you have spare microSD card (or don't mind flashing over you're existing one).
Even though it's Processing 3, hopefully the same processing.io features you need will be available.

OpenModelica IBPSA example error spatialDistribution

I'm quite new to Modelica and I'm trying to understand some basic examples. I'm looking at the example IBPSA.Fluid.FixedResistances.Examples.PlugFlowPipe and checking this model gives me the following error
Number of classes to check: 2
Checking: model IBPSA.Fluid.FixedResistances.Examples.PlugFlowPipe... 0.2350000000001273 seconds -> FAILED!
Error String:
Error Buffer:
Warning: Requested package Modelica of version 3.2.2, but this package was already loaded with version 3.2.3. You might experience problems if these versions are incompatible.
[C:/Program Files/OpenModelica1.14.0-64bit/lib/omlibrary/IBPSA 3.0.0/Fluid/FixedResistances/BaseClasses/PlugFlowTransportDelay.mo:49:3-55:44:writable] Error: Function argument initialValues={time + pip.cor.timDel.t_in_start, time + pip.cor.timDel.t_out_start} in call to spatialDistribution has variability continuous which is not a parameter expression.
#[-], 0.2350000000001273, IBPSA.Fluid.FixedResistances.Examples.PlugFlowPipe
-------------------------------------------------------------------------
Checking skipped: package IBPSA.Fluid.FixedResistances.Examples.PlugFlowPipe.Medium...
[2] 11:48:12 Scripting Notification
Number of classes checked / failed: 2/1
It seems that the module pip.cor.timDel uses the function spatialDistributuon. My guess is that there is something wrong with pip.cor.timDel.t_in_start or pip.cor.timDel.t_out_start? It would be greatly appreciated if someone could help me with this.
P.S. I'm using OMEdit v1.14.0 on windows 10 with Modelica library v3.2.3
OpenModelica does not support the function spatialDistribution yet, i opened a ticket on Trac where you can follow for the current development status.

crash on the GPU with {inc,set}_subtensor and broadcasting the value

I am fine-tuning vgg16 network with keras 2.0.2 and theano 0.9.0 as backend on Windows10 64bit Anaconda 2 as this blog:https://blog.keras.io/building-powerful-image-classification-models-using-very-little-data.html
I find someone else had the same issue in the pull requests and it was fixed by changing a few lines of code (link: https://github.com/Theano/Theano/pull/2075). However , that's an old version of theano.(the pr was in 2014) . Theano 0.9.0 have already change the code and I still have this problem
every time I run the last line(i.e. model .fit_generator) , it shows that everything works fine until the last of first epoch. That's when exactly GPU always crash
model.fit_generator(
train_generator,
samples_per_epoch=2000,
nb_epoch=50,
validation_data=validation_generator,
nb_val_samples=400)
And here is the error message:
CudaNdarray_CopyFromCudaNdarray: need same dimensions for dim 0,
destination=32, source=16Apply node that caused the error:
GpuIncSubtensor{Set;::, ::, int64:int64:,
int64:int64:}(GpuAlloc{memset_0=True}.0,
GpuElemwise{mul,no_inplace}.0, Constant{1}, Constant{225},
Constant{1}, Constant{225})Toposort index: 143

pyusb - [Error 5] on Linux, but not Windows

I'm trying to communicate with an AD9913 evaluation board (Analog Devices), which has a Cypress FX-2 USB controller. I wrote a fully functional Python library which works flawlessly on Windows 7 (using a driver generated through libusb-win32-1.2.6.0's inf-wizard.exe), but now I try to run the same software from a Raspberry Pi 3 with Raspbian Jessie and cannot seem to write or read.
The following minimal example works on Windows 7:
import os
os.environ['PYUSB_DEBUG'] = 'debug'
import usb.core
print "usb.core file:", usb.core.__file__
# get device
dev = usb.core.find(idVendor=0x0456, idProduct=0xEE25)
if dev is None:
raise ValueError("Device not found")
dev.set_configuration()
# get the firmware version
print "Write: ", dev.write(0x01, [0x00])
print "Read: ", dev.read(0x81, 7)
The ouput here is:
usb.core file: C:\Python27\lib\site-packages\usb\core.pyc
Write: 1
Read: array('B', [1, 0])
However, on the Raspberry several problems occur. First, the product ID is 0xEE24 (which I found out through dmesg), and second, the code example above gives
usb.core file: /usr/local/lib/python2.7/dist-packages/usb/core.pyc
Write:
Traceback (most recent call last):
File "usbtesting_minimal_linux.py", line 29, in <module>
print "Write: ", dev.write(0x01, [0x00])
File "/usr/local/lib/python2.7/dist-packages/usb/core.py", line 948, in write
self.__get_timeout(timeout)
File "/usr/local/lib/python2.7/dist-packages/usb/backend/libusb1.py", line 824, in bulk_write
timeout)
File "/usr/local/lib/python2.7/dist-packages/usb/backend/libusb1.py", line 920, in __write
_check(retval)
File "/usr/local/lib/python2.7/dist-packages/usb/backend/libusb1.py", line 595, in _check
raise USBError(_strerror(ret), ret, _libusb_errno[ret])
usb.core.USBError: [Errno 5] Input/Output Error
I'm executing the script by calling sudo python minimal_example.py, otherwise (as expected) I get usb.core.USBError: [Errno 13] Access denied (insufficient permissions). (For the testing described above, I removed the udev rules I added to allow access to my regular user account, and rebooted and replugged the device afterwards.)
I also noticed that on Windows, Configuration 1 (which is the only configuration) as revealed by adding
cfg = dev.get_active_configuration()
to aforementioned example script, has only one Interface 0, where as on Linux Interface 0 has no endpoints, but there are additional interfaces Interface 0, 1, Interface 0, 2 and Interface 0,3, the first of which is identical to the sole interface shown by Windows.
Detaching kernel drivers as described in this post -- which given my current understanding as a USB novice should not be necessary here -- does not resolve the problem.
I suspect that the issue stems from a difference between the Windows/libusb and Linux implementation/backend of the USB communication (already hinted at by the fact that the productID shown is different for the very same piece of hardware attached), which might require some changes to the way I'm writing to the USB endpoint.
I'm happy to provide more information if needed and welcome all hints and suggestions.
Most likely, this error caused by the firmware is not uploaded. Usually speaking, FX-2 USB controller does not save the firmware.
Although I still cannot communicate with the device on the Raspberry Pi, the Error 5 problem is resolved by explicitly selecting a suitable alternate setting with proper endpoints, e.g.
dev.set_interface_altsetting(interface = 0, alternate_setting = 1)
Then read/write requests no longer fail with Error 5, but with a timeout error (which is Error 110 for libusb1 and None for libusb0).
I now suspect that there is a problem with how the device is detected by the operating system, since not only the productID changes between Windows and Linux, but also wMaxPacketSize for the endpoints I'm interested in is given as 64 bytes on Windows and 512 bytes on Linux.
Once I'm further along in my troubleshooting, I will either open a new question and add the link as a comment to this answer (or post the whole solution here in case I can solve everything right away).

Can I register event callbacks using the libvirt Python module with a QEMU backend?

I would like to write some code to monitor events for domains running under QEMU, managed by libvirt. However, trying to register an event handler yields the following error:
>>> import libvirt
>>> conn = libvirt.openReadOnly('qemu:///system')
>>> conn.domainEventRegister(callback, None)
libvir: Remote error : this function is not supported by the connection driver: no event support
("callback" in this case is a stub function that simply prints its arguments.)
The examples I've been able to find regarding libvirt's event handling don't seem to be specific as to which backend hypervisors support which features. Is this expected to work for QEMU backends?
I'm running a Fedora 16 system, which includes libvirt 0.9.6 and qemu-kvm 0.15.1.
For folks finding themselves here via <searchengine>:
UPDATE 2013-10-04
Many months and a few Fedora releases later, the event-test.py code in the libvirt git repository runs correctly on Fedora 19.
Make sure you have registered in the libvirt event loop (or set up your own) before registering for events.
There is a nice example of event handling shipped with the libvirt source (file is called event-test.py). I'm attaching an example based on that code;
import libvirt
import time
import threading
def callback(conn, dom, event, detail, opaque):
print "EVENT: Domain %s(%s) %s %s" % (dom.name(),
dom.ID(),
event,
detail)
eventLoopThread = None
def virEventLoopNativeRun():
while True:
libvirt.virEventRunDefaultImpl()
def virEventLoopNativeStart():
global eventLoopThread
libvirt.virEventRegisterDefaultImpl()
eventLoopThread = threading.Thread(target=virEventLoopNativeRun,
name="libvirtEventLoop")
eventLoopThread.setDaemon(True)
eventLoopThread.start()
if __name__ == '__main__':
virEventLoopNativeStart()
conn = libvirt.openReadOnly('qemu:///system')
conn.domainEventRegister(callback, None)
conn.setKeepAlive(5, 3)
while conn.isAlive() == 1:
time.sleep(1)
Good luck!
//Seto