[Mike Fiore]

Hi Shankar,
We’re about to release new dotbox firmware that supports AT commands. The documentation is up on multitech.net and quick start guides have already been written, which is why you might be confused.

When the firmware is released, it will be available on the multitech.net downloads page. It should be coming in the next week or two.

Cheers,
Mike

[Mike Fiore]

Glad that worked out! Let us know if you have any other questions!

Cheers,
Mike

[Mike Fiore]

Does you USB-to-Serial cable require any additional drivers to be installed?

You could take a look at your device manager in Windows and see if there are any unidentified USB devices or COM ports, etc.

[Mike Fiore]

Hi Sabrine,
Two things:

1) The AT firmware uses the external serial port on the UDK2 for AT commands, not the virtual port coming over USB. You’ll need either a serial port on your PC or a USB-to-Serial adapter to connect your PC to the external port.

2) To use the virtual port over USB with a windows PC, you need to install an additional driver first. See this mbed page for more information.

https://developer.mbed.org/handbook/SerialPC

Cheers,
Mike

[Mike Fiore]

That is the next thing I was going to suggest! Glad you got it figured out!

-Mike

[Mike Fiore]

Yusuf,
Can you try downloading a fresh copy of the library tarball? Maybe something got corrupted at some point and is causing the build to fail.

Here’s the MD5 from the copy I extracted and successfully built with, along with file sizes and permissions:

md5sum libmDot-0.0.9-1-ge7286ba-GCC_ARM.tar.gz
cab21380f486c9313f60b425a221fe35 libmDot-0.0.9-1-ge7286ba-GCC_ARM.tar.gz

ls -lh libmDot-0.0.9-1-ge7286ba-GCC_ARM.tar.gz
-rw-rw-r– 1 mfiore mfiore 124K Jan 22 12:04 libmDot-0.0.9-1-ge7286ba-GCC_ARM.tar.gz

ls -lh mdot/*
-rw-rw-r– 1 mfiore mfiore 331K Jan 22 12:04 mdot/libmDot-0.0.9-1-ge7286ba-GCC_ARM.a
-rw-rw-r– 1 mfiore mfiore 30K Jan 22 12:04 mdot/mDot.h

mdot/MTS-Utils:
total 20K
-rw-rw-r– 1 mfiore mfiore 5.9K Jan 22 12:04 MTSCircularBuffer.h
-rw-rw-r– 1 mfiore mfiore 3.4K Jan 22 12:04 MTSLog.h
-rw-rw-r– 1 mfiore mfiore 3.1K Jan 22 12:04 MTSText.h
-rw-rw-r– 1 mfiore mfiore 1.1K Jan 22 12:04 Utils.h

Hope this is helpful!

Cheers,
Mike

• This reply was modified 8 years, 10 months ago by Mike Fiore.

[Mike Fiore]

Can you elaborate on the problem with private settings? I’ve never had to use sudo to run the python scripts, so I’m not sure if that would have any adverse affects or not.

Also, what toolchain are you using?

[Mike Fiore]

Ok, if you just copied and pasted that code, that should be fine.

A couple other things:

1) You’re running the build.py script before make.py, right?
2) Why are you using sudo with make.py? I’m wondering if that might be causing issues.
3) What are the file permissions on the library files? Can you do a ls -l in your source directory?

Cheers,
Mike

[Mike Fiore]

Yusuf,
You shouldn’t have to rename the archive, but it shouldn’t break anything as long as the file type (.a) stays the same.

I don’t see any reason why your build would fail based on what you’ve shared so far. Can you share the contents of main.cpp?

Cheers,
Mike

[Mike Fiore]

Yusuf,
It looks like you’re missing the mDot library (libmDot). You need to download the offline version of the mdot library from the downloads page on this site, extract the tarball, and put the library and headers into your source folder.

Cheers,
Mike

[Mike Fiore]

The two version of GCC linked from the wiki page are builds for Windows or Linux, so you would grab whichever one is appropriate for your OS.

Unfortunately, the short answer is that we don’t support the EmBitz toolchain right now. If you want to use an IDE environment for your development, I suggest using the mbed online compiler.

-Mike

[Mike Fiore]

Hi Howard,
I don’t know much about the EmBitz toolchain, but I don’t think it’s likely to work at the moment. The only toolchains we’re officially supporting right now are the mbed online compiler (which uses ARMCC), and the offline mbed SDK (ARMCC or GCC_ARM). We have a wiki page about using the offline mbed sdk for your reference:

https://developer.mbed.org/teams/MultiTech/wiki/Using-the-mbed-SDK-for-mDot-development

Cheers,
Mike

[Mike Fiore]

Howard,
All of our mDot library examples are linked to from our mDot platform page on mbed:

https://developer.mbed.org/platforms/MTS-mDot-F411/

Cheers,
Mike

[Mike Fiore]

Anthony,
Take a look at this page on the developer site:

Conduit mLinux: LoRa Communication

It has examples of sending and receiving packets to and from the mDot and an example node.js application.

Cheers,
Mike

[Mike Fiore]

Neil,
Brandon has updated documentation. The mbed SDK is not ultimately under our control. You can open an issue or make a pull request on the mbed SDK Github page.

https://github.com/mbedmicro/mbed

Cheers,
Mike

[Mike Fiore]

Andrew,
One clarification: if you’re building your application with the mbed online compiler or the mbed SDK, the bootloader is automatically built into your application. So, while flashing in a new application will technically wipe out the bootloader, your new application contains a copy of the bootloader, so you don’t lose it.

Cheers,
Mike

[Mike Fiore]

Hi,
The bootloader hasn’t been tested with docklight. The bootloader is compatible with TeraTerm on Windows or Minicom on Ubuntu. We suggest using one of those terminal emulators to transfer new firmware.

Make sure your terminal program is set to 115200 baud as well.

The following image shows an example of the bootloader prompt and the bootloader help.

Cheers,
Mike

• This reply was modified 9 years, 1 month ago by Mike Fiore.
• This reply was modified 9 years, 1 month ago by Mike Fiore.

[Mike Fiore]

Andrew,
A preliminary version of the mDot developer guide is available on the MultiTech website: http://www.multitech.com/manuals/s000612_x.pdf

Hope that helps!
-Mike

[Mike Fiore]

Mr. Godinez,
We do have a GitHub page, but it currently only contains our fork of the MBED SDK.

https://github.com/MultiTechSystems

We will have to see if we can get more put up there in the future.

-Mike

[Mike Fiore]

Hi David,
Tagged releases are well-tested and stable. I’d stick with those for your production setup.

You can also download release tarballs instead from the Downloads page on this site instead of cloning from the Git repository.

Cheers,
Mike

• This reply was modified 9 years, 6 months ago by Mike Fiore.

[Mike Fiore]

Hi Jun,
Your PC must be connected to your PC via an ethernet connection, and it must be on the same subnet as the device in order for you to use ssh or scp. If you run “ifconfig eth0” on your Putty serial connection, you should see the device’s IP address. The default should be 192.168.2.1

You need to either move your PC to the subnet of the MTCDP or move the MTCDP to your PC’s subnet.

For example:

MTCDP ip = 192.168.2.1
PC ip = 192.168.50.155

Either the MTCDP must have a 192.168.50.xxx IP address, or your PC must have a 192.168.2.xxx IP address in order for them to find each other.

Cheers,
Mike

[Mike Fiore]

Hi Tim,
We don’t have any work planned to update u-boot at the moment. You could try patching a newer u-boot; compare the board file in our u-boot recipe against the board file in the vanilla u-boot version you choose. I don’t think there should be too many changes/customizations.

A couple things to keep in mind:
– make sure the nand configuration is correct (you should be building for at91sam9g20ek_nandflash_config)
– the vanilla u-boot may be using a different ethernet configuration (mii vs rmii), but that shouldn’t cause u-boot to hang

If you continue to have issues, pasting any console debug output will help us assist you in debugging the issue.

Cheers,
Mike

[Mike Fiore]

Hi Lewis,
The documentation on this site should help to point you in the right direction. Here are a few links…

http://www.multitech.net/developer/products/multiconnect-ocg/development/creating-a-custom-image/

http://www.multitech.net/developer/products/multiconnect-ocg/development/writing-bitbake-recipes/

http://www.multitech.net/developer/products/multiconnect-ocg/development/customizing-bitbake-recipes/

http://www.multitech.net/developer/products/multiconnect-ocg/development/working-with-a-single-recipe/

Basically, you would write a recipe to build, configure, and install your application or files. Then, when you build your custom image that includes that recipe, your application or files will be on the device after flashing the new image.

Don’t hesitate to post back if you have more questions or if something was unclear!

Cheers,
Mike

[Mike Fiore]

Lewis,
As far as I know, this issue with OE-Classic hasn’t been resolved. OE-Classic is no longer being maintained at this point. We are hoping to release a version of CoreCDP that is compatible with OE-Core in the future, but that release date is still TBD.

It may be possible to take a Python 2.7 recipe from OE-Core and port it back to OE-Classic for the time being. Depending on the recipe, this can, but is not guaranteed to be, a fairly easy process.

Cheers,
Mike Fiore

[Mike Fiore]

Joseph,
I tested BT’s solution in the above post and did not encounter any errors. I ran openvpn without any arguments and saw the application’s usage message printed to the terminal as expected.

Did you put openvpn on your OCG as part of a bitbake image, or did you obtain it somewhere else?

-Mike

[Mike Fiore]

Hi Joseph,
How recent is this Debian install? Has it been upgraded from an older version of Debian? Have you added any non-standard repositories to your apt-get sources list?

You could try running

apt-get update
apt-get upgrade

and then try running the dependency script again.

Cheers,
Mike

[Mike Fiore]

Alexey,
I’m not sure what you mean by “compiling python directly on the device”. Your OCG should have shipped with corecdp-full-image on it, which includes Python. There is also a smaller image, corecdp-python-image, that also includes Python. The Python version is 2.6.6 in both cases, so if you’re able to use 2.6.6, you should be able to run your application on the OCG without building a custom image.
Thanks,
Mike

[Mike Fiore]

Hi Alexey,
I’ve been trying to get Python 2.7.1 working here at the office and it hasn’t been a fun process so far. I finally got Python compiling and installing, but running it on an OCG still failed. There were modules mising that 2.7.1 required. I copied over those modules (they were in the build directory, just hadn’t been installed by default), but even then, I still saw an error when trying to invoke Python.

It seems like there are some pretty serious issues with the recipe and the resulting Python installation. My guess is that it was half-baked to begin with and probably never maintained or improved because of the general shift to oe-core.

One thing you could try is taking a Python recipe form oe-core and back-porting it to oe-classic. Sometimes, if the recipes are similar to begin with, this isn’t too much work. I won’t make any guarantees, however. 🙂

If you want the dirty details of what I did to get where I did with Python 2.7.1, let me know. I unfortunately can’t put any more time into this right now. If you end up getting something working, please share your results!

Cheers,
Mike

[Mike Fiore]

Alexey,
It looks like there is a separate .inc file for Python 2.7. The existence of that file indicates that the build process for earlier Python versions probably isn’t the same as the process for 2.7. I would suggest reverting the changes you made to python.inc and instead setting

PREFERRED_VERSION_python = "2.7.1"

in multitech/conf/distro/corecdp.conf. This will cause 2.7.1 to be built as the default Python version.

Cheers,
Mike

[Mike Fiore]

Shoot! My links didn’t make it through

First link: https://github.com/pypa/virtualenv/issues/76

Second link: http://blog.hugeaim.com/2012/06/09/no-module-named-_weakrefset-in-linux-mint/

Cheers!
Mike

[Author]

Posts