[Jesse Gilles]

Looks like the expat download was bad.

gzip: stdin: invalid compressed data–crc error

Try deleting it and rebuilding. The easiest way to clean up the recipe and any downloaded source code is to run the “distclean” task on it.

bitbake expat -c distclean

[Jesse Gilles]

You mistyped the image name.

[Jesse Gilles]

I noticed you are doing the build outside of your home directory…do you have full permissions to /corecdp-2.0.0?

Check to make sure there is a build sub directory. Bitbake puts all of it’s files in build/tmp under the top directory (/corecdp-2.0.0/build/tmp in your case). Make sure that your entire directory structure is writable by you and that the build dir exists.

[Jesse Gilles]

Mariano,

CoreCDP 2 has not beeen released yet, so there is no more detailed guide than what is provided. When CoreCDP 2.0 is released, the multitech.net website will be updated accordingly.

Please remember you are using unreleased, unsupported code.

To summarize the steps, here is what you should do after you’ve cloned the repo. You can skip checking out a specific tag or branch since there isn’t any release tags yet, only the master branch.

cd corecdp-2 (or wherever you cloned to)

./setup.sh

source env-oe.sh

bitbake corecdp-openjdk-image

Thanks,

Jesse

[Jesse Gilles]

No, sorry, you can’t send commands from your PC directly to the cellular modem. But you can ssh to the MTCDP and then run microcom to send AT commands to the modem.

[Jesse Gilles]

You could also use a serial cable and connect it to your PC, run terminal software on both ends and send characters back and forth.

[Jesse Gilles]

I think it would be helpful for you to do some research on using gcc in general if you are not familiar with it. If the program compiles successfully, it doesnt print anything out. It only prints messages if there are errors. You specified the -o option to gcc, which told it to put the output as a file named “mymodbuscomm”. If you ran it successfully as you mentioned, then you should have a compiled program called “mymodbuscomm” and you should be able to run it on the MTCDP if the libmodbus library is installed.

You shouldn’t set the path in your Makefile. Bitbake will setup all the paths needed and you should only need to invoke the compiler using the right variables like you had in your recipe in the first place.

$(CC) $(CFLAGS) $(LDFLAGS) mymodbuscomm.c -o mymodbuscomm

If you building the recipe then the paths and variables will be set. They will also be set if you open a devshell. If you don’t do either of those, then you don’t have any special paths set and you have to set them yourself or specify the full path to the compiler when you run it.

[Jesse Gilles]

JM,

I think some of your difficulty is arising from the fact the application needs to be cross compiled, not built for your Linux workstation. This means you have to use a different compiler and that headers and libraries are installed in a non-standard location.

When you are cross-compiling, you can’t just call “gcc” since that will be the compiler for your workstation, not the embedded device. Also, for the same reason, you can’t use includes from /usr/include and libs from /usr/lib because those are also for your workstation.

When you open up the devshell, print out your env (just run “env”) and look at the environment variables defined and you’ll see where the cross-compiler located, etc.

When you run the cross-compiler, it will have the includes and libs for the target system already in its default search paths, so if the libmodbus recipe installed the headers and libs in the right spot, you shouldn’t need to add the -I and -L options to your compile command. But you will need to add ‘-lmodbus’ so it knows to link against.

The compiler is located at:

$OETREE/build/tmp/cross/armv5te/bin

The headers dir that is search by default is:

$OETREE/build/tmp/staging/armv5te-corecdp-linux-gnueabi/usr/include

And libs are in:

$OETREE/build/tmp/staging/armv5te-corecdp-linux-gnueabi/usr/lib

$OETREE is the top of your corecdp directory structure.

[Jesse Gilles]

Hi JM,

A couple of things:

1. Adding “libmodbus” to DEPENDS doesn’t make your application link against it. It makes bitbake know that in order to build your recipe, it needs to build libmodbus first and put the needed files in the sysroot (so your recipe can find the headers and libs). You’ll need to tell GCC that you want to link against the libmodbus library, it doesn’t know about it automatically.

2. You can certainly compile your application right in the bitbake recipe, but it might be easier to manage if you were to write a Makefile to compile it. Then you can actively develop your application by just running make until you get it building. Once you have it building, then you can resume running the bitbake recipe to package it up.

You can open up a development shell with all of the environment variables set for cross-compiling (CC, CFLAGS, LDFLAGS, etc) by running:

bitbake modbuscomm -c devshell

Then you can run make or run $CC and you can fix your build and then go back to running the bitbake recipe again. Also, if you switch to using a Makefile, then your do_compile task goes away and the compiling happens in the make file. You can also do the same thing for do_install if you want.

Hope that helps,

Jesse

[Jesse Gilles]

No, you shouldn’t need to modify anything in the sshd config, it should be listening on all network interfaces by default.

If you have some iptables rules defined, I would try clearing them out all temporarily and then try it again. Without any iptables rules, all traffic should be allowed and you should be able to ssh to the unit if you have a public IP address.

[Jesse Gilles]

Message received. I am reorganizing the new release into a bitbake layer rather than a custom branch, so it will be in a new repository completely. I am planning to move the current internal git repo onto git.multitech.net soon. We are still doing testing internally so it’s not release ready quite yet.

You can be assured the development platform is definitely not going stale 🙂

Jesse

[Jesse Gilles]

Try the libmodbus recipes in the master branch of the OpenEmbedded git repository.

You can view them here:

http://git.openembedded.org/cgit.cgi/openembedded/tree/recipes/libmodbus

[Jesse Gilles]

See my post on your other thread. If you built and installed the library in /usr/local, I’m guessing it didn’t get cross-compiled to run on the CDP, but instead was compiled to run on your Linux workstation, which isn’t an ARM platform.

Jesse

[Jesse Gilles]

< I have come across this modbus library, ‘libmodbus’. I have compiled and installed it on my system.

It looks like there are bitbake recipes to build libmodbus in the OpenEmbedded git repository. I would suggest copying those into your tree and building libmodbus with bitbake.

Jesse

[Jesse Gilles]

This should not be an issue and would not reduce the life of the flash. The flash life is only affected by erase/write cycles and powering the device up and down should not affect it.

Jesse

[Jesse Gilles]

The device could be powered from a vehicle, but currently it can’t be put into suspend mode, it would simply be powered off if the vehicle is off. Also, the mts_io driver doesn’t support interrupt driven GPIO at this point — it exposes a sysfs interface which allows reading and writing of pins from userspace.

Jesse

[Jesse Gilles]

Ken,

Yes, there are plans and work is currently in progress to release a new CoreCDP version based off a new OE snapshot (currently will be based off the 2011.03 branch).

Also, source code is mirrored on multitech.net:

http://www.multitech.net/corecdp/sources/

The build process is supposed to fall back on this as a source when other locations fail, but if you get a new file with a different MD5 sum, it obviously doesn’t help.

Jesse

[Jesse Gilles]

Whoops, yeah, I meant to have the –in-file option in there, sorry.

[Jesse Gilles]

My suspicion would be that the php executable is getting created with debug info and isn’t getting stripped for some reason, though I can’t say why off hand.

[Jesse Gilles]

Brandon,

mts-id-eeprom is the application you want, but you have to give it the path to the eeprom (which you already also found).

mts-id-eeprom --help will give command-line options.

Running:

mts-id-eeprom /sys/devices/platform/i2c-gpio/i2c-0/0-0056/eeprom

will produce yaml output that you can parse.

Jesse

[Jesse Gilles]

You can either add it to a custom image and reflash the device:

http://www.multitech.net/developer/products/cellular-development-platform/development/creating-a-custom-image/

Or, you can build just the venus-gps package using bitbake and install it on the device:

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

[Jesse Gilles]

You can fix the port name by writing udev rules that match the device and create a symlink with a specific name.

A google search yielded this as an example:

http://hintshop.ludvig.co.nz/show/persistent-names-usb-serial-devices/

[Jesse Gilles]

The external RS232 port is setup to be a DCE port, so the RX and TX lines are swapped compared to your PC serial port (DTE). You’ll need to use a null modem adapter when you’re connecting the serial device to the CDP since the CDP is DCE and your external device is also DCE.

[Jesse Gilles]

The /dev/ttyGS0 is the port for the gadget serial driver, which is operating on the USB device port. The ftdi driver will give you a new tty device to use. Run ‘dmesg’ after you attach the device to see the tty assigned to it.

[Jesse Gilles]

JM,

You don’t need to use minicom to talk to the modem. Linux treats the serial port for the modem (/dev/ttyUSB0) as a file, so you can do reads and writes as if it were a regular file in your C application. There are also C calls you can make to configure the serial port (baud rate, etc).

Here is a page that has some examples, take a look at the section labeled “termios”.

http://en.wikibooks.org/wiki/Serial_Programming/Serial_Linux

You are also free to look at and use the source code for the sms-utils application, which is written in C.

http://git.multitech.net/

Jesse

[Jesse Gilles]

Sorry I didn’t realize this earlier — the sms-utils packages doesn’t currently support the EV2 radio. You can still send/receive SMS with it, but at the moment you’d have to write a utility to do it using the AT commands documented in the manual for the radio. We are hoping to update the sms-utils to support the EV2 in the future.

http://www.multitech.net/developer/products/cellular-development-platform/references/

[Jesse Gilles]

Noah,

The sms utility needs to know which device port to talk to since the various CDP models have different cellular radios in them and therefore can have different device ports.

Just for future reference, an overview of the ports per model is here:

http://www.multitech.net/developer/products/cellular-development-platform/hardware/accessing-hardware-interfaces/

As Bryan mentioned, the H4 model has /dev/ttyUSB3 that you can send AT commands to, it also has /dev/ttyUSB4 as well. This allows you to have a ppp link up on /dev/ttyUSB4 and still issues AT commands (sms, etc) on /dev/ttyUSB3.

Thanks,

Jesse

[Jesse Gilles]

If you are running as root on the CDP, then the .smsconfig should be in /home/root/.smsconfig, so you can just copy the file over using scp and then try it or edit on the box with vi or nano. If that is still giving issues, try passing the –device option on the command line when you run the app. If you run ‘sms’ with no options, it should print out a usage.

[Jesse Gilles]

Good, glad you got it working.

Did you edit your $HOME/.smsconfig file to use the correct port for your modem? You need to edit the “device:” line to use the right port depending on which model of CDP you have. Otherwise, you can set the device using the command line options.

http://www.multitech.net/developer/products/cellular-development-platform/applications/sms-utils/

[Jesse Gilles]

You don’t need to specify the port and IRQ, you should just need to use /dev/ttyS2 (it is already configured with the correct hardware info). I would recommend running microcom on the port with the correct baud rate and confirm that you can send data back and forth?

[Author]

Posts