Posts made by huxflux

Ah, you're right, seems like it's a stripped down version of fdisk. You could try opkg list | grep -i fdisk and try one of those and see if they're closer to the normal version of fdisk. Remember to opkg update first.. if you haven't done already

1. fdisk /dev/sdb
2. d <enter> - Delete every other partition you might have with multiple d <enter> - This 'd'eletes your partition(s)
3. n <enter> - Tell fdisk you want to add a 'n'ew partition
4. p <enter> - We'll add a 'p'rimary partition
5. <enter> x 3 - We want to use all space on the one partition we just added
6. t <enter> - In case it didn't choose linux partition 't'ype, lets make sure
7. 83 <enter> - The code for linux partition type
8. w <enter> - 'w'rite the changes to your device

Now you have /dev/sdb1 .. then just run mkfs.ext4 /dev/sdb1 and afterwards mount /dev/sdb1 <random directory> where <random directory> could be /mnt/usb

For fdisk, remember m for menu.. hope this works out for you!

Hehe, you need to read about fdisk on how to make new partitions

You could use fdisk. fdisk /dev/sdb

Add a partition to /dev/sdb .. then you'll get /dev/sdb1 .. and you can mkfs.ext4 /dev/sdb1

Did you try to mount /dev/sdb /mnt/sdb?

Sounds very strange. What channel does the Onion Omega AP use? https://en.wikipedia.org/wiki/List_of_WLAN_channels ..

That's the only thing I can see. If Onion Omega Wi-fi uses a channel your router don't check.

EDIT: And if there are only 5GHZ wi-fi networks around you, your Onion Omega will probably not detect those. But it's very rare that everyone is on the 5GHZ range hehe. And if your router is on the 5GHZ range, I don't know if it can find the 2.4GHZ ones. This is stuff that probably can be googled.

Thinking of it.. is your wi-fi router on the 5GHZ range?

EDIT2: Some errors here, this is stuff I don't know too much about. Of course when you scan with your PC it is your wifi-chip that does the job..

Thanks for the explanation. Never heard of PWM until now. New to electronics.

Very nice!

And very interesting too.. "new-expled - a program that uses GPIO pin access to control expansion dock led similar to the Omega supplied expled script" .. I know the GPIO's can only be set to 0 and 1.. but.. wondered how they could send in 0x0 - 0xFF.

EDIT: Just started reading from your sourcecode. Do you use their 'expled' binary to do your stuff?

Hi, I've been playing around with C and GCC on the Onion Omega for some days now. I just made some functions for manipulating the GPIO using C and have pushed it up to github. Remember you need gcc and Expansion Dock for this, and probably need to compile and link it on the Onion Omega itself.

https://github.com/huxflux/onion_omega_gpio

main.c is just testing the LEDs on the Expansion Dock to showcase that the functions are working. Nothing pretty, just chaotic.

All done on the Onion Omega.

Next is to find out how expled is done, since you can give values for each LED between 0x0 - 0xFF. Anyone know how he/she/they did it?

@Theodore-Borromeo That's what I thought, but it's not the case. Using -rpath options together with their libonionspi.so did nothing. I'm not sure what's going on.

Anyway, I was doing this for fun, and to prove a point. It is possible to compile and link on the Onion Omega using gcc. If you have the diskspace, since gcc is about 22MB.

Cloud compiling is coming soon. No need for this stuff.

@Theodore-Borromeo That is exactly what I'm thinking. They're not including the header-files in their libonionspi and liboniondebug packages. But even when I've downloaded the headers from their github, they still don't work as I think they should. I'm no expert on these matters. Far from it.

I did manage to do something though. This is all on the Onion Omega. I downloaded onion-debug.c, onion-spi.c, onion-debug.h and onion-spi.h from github. I moved onion-debug.h and onion-spi.h to /usr/include. I then executed these commands:
gcc -Wall -fPIC -c onion-spi.c onion-debug.c
gcc -shared -Wl,-soname,libctest.so.1 -o libctest.so.1.0 onion-spi.o onion-debug.o
ln -sf libctest.so.1.0 libctest.so.1
ln -sf libctest.so.1.0 libctest.so

We just made a dynamic library out of onion-spi.c.

Next step is to make a simple code for trying out the functions in the library. Lets call it main.c

#include <stdio.h>
#include <onion-spi.h>

int main(int argc, char *argv[])
{
struct spiParams params;
spiParamInit(&params);
return 0;
}

gcc main.c -L/root/coding/spi -Wl,-rpath,/root/coding/spi -lctest and voila! It works. Of course you'll have to change the paths to the correct places.

It is possible to build dynamic libraries from their code. It's also possible to compile and link using those dynamic libraries. And all this can be done on the Onion Omega itself.

I'll try to see if I can put all these files into the correct directories and see if the compiling and linking gets easier. Eg. gcc main.c -lonionspi.

EDIT: And that works out too. I can now compile with gcc main.c -lonionspi. Just change the name of libctest to libonionspi and mv libonionspi.so.1.0 /usr/lib/. Then just cd /usr/lib and make the symbolic links.

Well, I did learn a thing or two from this experience. Worth!

I now have onion-spi.h from https://github.com/OnionIoT/spi-gpio-driver/ and onion-debug.h from https://github.com/OnionIoT/i2c-exp-driver and moved them to /usr/include. I execute gcc main.c -L /usr/lib -loniondebug -lonionspi and get this errormessage: http://pastebin.com/2K3eX8x4

Basically the same as post #4

@Lazar-Demin Check out post #4 in this thread. I'll try with -L /usr/lib

Btw, minor detail. When I include onion-spi.h, that file also includes onion-debug.h. Which is not found at https://github.com/OnionIoT/spi-gpio-driver/ but found at https://github.com/OnionIoT/i2c-exp-driver

@Lazar-Demin Yes, this is what I execute gcc main.c -loniondebug -lonionspi
Here's the testfile for compiling http://pastebin.com/gj8QT1k1. I also have libonionspi.so and liboniondebug.so in /usr/lib/.

@Theodore-Borromeo Yes it fixes the dependency so I'm able to compile it, but not link it. undefined reference to one or more of the functions.

Cloud Compile sounds fancy schmancy

@Kit Bishop I tried compiling using only the .h-files with gcc main.c -loniondebug -lonionspi. The linker complains about not finding the reference to one of the functions. If I edit libonionspi.so I can see the name of the function is there. So I'm at loss to what's going on here. It compiles, but doesn't link.

Hehe yes, makes sense. Thank you! I'll just set this as [resolved].

When I execute opkg update the files are downloaded and put in /var/opkg-lists/. Now, /var points to /tmp/ .. and I'm pretty sure /tmp/ doesn't get saved when you reboot.

I find it strange we have a symbolic link var -> /tmp

Edit: Thinking of it, this might be intentionally. Saves space on the storageunit.

Everything else seem to be persistent. So I'm not sure what's up with opkg update. Maybe it puts the files somewhere it doesn't get saved. Hmhm.. it's quite obvious that's what might be happening here..

Thanks for replying!

We already can compile on the Onion Omega using the python-light package. If you add some more space through USB, you can even install gcc on the Onion Omega. There are no problems whatsoever using Vim and compile C-code on this unit. The problem is when I want to use their libraries libonionspi and/or libonioni2c. For some reason, they don't include the header-files when you install libonionspi and/or libonioni2c.

The reason I want to code directly on the Onion Omega is because it's fast. I just want to write small programs that deal with the LEDS or read/write stuff to the GPIO's.

I could of course go without their libraries and go low-level myself. I might do it. Or maybe I should just go with Python. Or maybe go the cross-compilation route. We'll see