A newcomer asks about Riotboard HDMI...

Hello .

Well I got the HDMI to VGA cable today. (As mentioned above..)

Plugged it into the HDMI connector of the board and plugged a dell LCD monitor into the VGA end of the adapter...

Turned on the board and!!!!!

NOTHING!!!

I also tried plugging it into my laptop VGA socket. The laptop screen border changes but TIA... hmmm....

Anyone have any ideas or experience of what I can do?

(apart from spending hundreds of punds on something I don't have the moolah for at the moment...?)

Cheers,

Steve.

plugged a dell LCD monitor into the VGA end of the adapter

HDMI interfaces are highly supported but with vga connectors may not work.

apart from spending hundreds of pounds ...

serial console is nice and good if there is no display specfic work.

I mentioned the software setup here and hardware connection here.

Hope that helps for the moment.

GPIO can, theoretically, be programmed using any language you like. /sys/class/gpio being the starting point. However some folks had problems with that on the ubuntu image early on.  There's a thread around here somewhere where I tried to show how to decipher the gpios, but unfortunately used the addresses from the i.MX6 Quad instead of the Solo. The method works, you just need to use the right datasheet.

Unfortunately the setup in the default 3.0.35 kernel appears to be less than useful for using gpio.

Hopefully I'll get time to do another blog post or two soon that will finish off setting up Debian, at which point things like gpios basically just work on the 3.15-rc* kernel. Even so, you will need some sort of linux machine in order to build all the pieces. Ideally I'll try to produce an image that can be easily written to an SD card so that people who don't have the confidence to do it themselves can just write the image and go..  Right now I don't have anywhere to host a large image, so how to make it available is still a problem

ERROR: HDMI is not ready!

doesn't sound particularly good.

asoc: can't open platform imx-hdmi-soc-audio.0

don't think I'd worry too much about that... native HDMI can do audio as part of the stream to something like an HDTV. but a DVI monitor doesn't do audio while the video format is essentially identical. So you're likely seeing a message that indicates the driver can't detect that the connected device has audio capabilities - which is probably ok for an HDMI-VGA converter

steven scutt wrote:

 

Should one of the LEDs be flashing? (the one nearest the power jack)..

possibly, it's usual to configure one of the leds as 'heartbeat' so that you can tell when the system is running,

modprobe: FATAL: Could not load /lib/modules/3.0.35-02871-ga35ffe3/modules.dep: No such file or directory

once you get logged in (as root), try running depmod -A and then rebooting. in theory that message should go away. maybe you need to do 'sudo depmod -A'

oh, p.s. did I tell you I was interested in mainly Audio, synthesis and control..

So android may not be the best idea for you right now, there's a known issue with audio playing slow on the current android image. works fine on the linux image though.

if you're not interested in accelerated video, then 3.15-rc* might be the way to go. The downside to 3.15-rc* is that you currently get simple framebuffer video with little or no hardware assist. So while you can get a working desktop it may feel sluggish.  There may be ways to get accelerated video working, but as yet nobody has done it for RIoTboard. We can likely borrow from work done with other i.MX6 based boards like Sabre-Lite and Wandboard though.

Ultimately we could do with a few people who are interested in different areas to spend the time on bringing all the pieces together - I'm not overly interested in video so ideally would leave that to someone else.. but may get round to it eventually if nobody else does.

Heartbeat I remember that from StickOS. I have 2 Freescale DEMOJM boards that run Stickos from Rich Testardi.

I've had a look at the thread on GPIOs. Very very useful and good. I Managed to get a light to turn on and off using the "Echo" command.

Will have a look at the tome that is the data sheet and get to grips with the peripherals and audio.

.

good luck with the datasheet, it's not quite bedtime reading is it

I'm installing python 3.3.0 as per Otto's instructions above.

I've got to running "make"

1. sudo apt-get build-dep python3.2 
2. sudo apt-get install build-essential libreadline-dev libncurses5-dev libssl1.0.0 tk8.5-dev zlib1g-dev liblzma-dev 
3.  
4. wget http://python.org/ftp/python/3.3.0/Python-3.3.0.tgz 
5.  
6. tar xvfz Python-3.3.0.tgz 
7.  
8. cd Python-3.3.0 
9. ./configure --prefix=/opt/python3.3 
10. make   

its been running for about 45 minutes now... should it be taking this long????

45 minutes is a bit long...

What is he showing right now?

By the way you can cancel it with Ctrl + C.

it was going through something like this:

By default, distutils will build C++ extension modules with "g++".

  If this is not intended, then set CXX on the configure command line.

checking for -Wl,--no-as-needed... yes

checking how to run the C preprocessor... gcc -E

checking for grep that handles long lines and -e... /bin/grep

checking for egrep... /bin/grep -E

checking for ANSI C header files... yes

checking for sys/types.h... yes

checking for sys/stat.h... yes

checking for stdlib.h... yes

checking for string.h... yes

checking for memory.h... yes

checking for strings.h... yes

checking for inttypes.h... yes

checking for stdint.h... yes

checking for unistd.h... yes

checking minix/config.h usability... no

checking minix/config.h presence... no

checking for minix/config.h... no

checking whether it is safe to define __EXTENSIONS__... yes

checking for --with-suffix...

checking for case-insensitive build directory... no

checking LIBRARY... libpython$(VERSION)$(ABIFLAGS).a

checking LINKCC... $(PURIFY) $(MAINCC)

checking for GNU ld... yes

checking for inline... inline

checking for --enable-shared... no

checking for --enable-profiling... no

checking LDLIBRARY... libpython$(VERSION)$(ABIFLAGS).a

checking for ranlib... ranlib

checking for ar... ar

checking for readelf... readelf

checking for python... found

checking for a BSD-compatible install... /usr/bin/install -c

checking for a thread-safe mkdir -p... /bin/mkdir -p

checking for --with-pydebug... no

checking whether gcc accepts and needs -fno-strict-aliasing... no

checking if we can turn off gcc unused result warning... yes

checking whether gcc supports ParseTuple __format__... no

checking whether pthreads are available without options... no

checking whether gcc accepts -Kpthread... no

checking whether gcc accepts -Kthread... no

checking whether gcc accepts -pthread... yes

checking whether g++ also accepts flags for thread support... yes

checking for ANSI C header files... (cached) yes

checking asm/types.h usability... yes

checking asm/types.h presence... yes

checking for asm/types.h... yes

checking conio.h usability... no

checking conio.h presence... no

checking for conio.h... no

checking curses.h usability... yes

checking curses.h presence... yes

checking for curses.h... yes

over and over again... I've pressed cntrl c now... ???

45 minutes is relative....  cross compiling on a fast multi-core x86 machine will go a lot quicker than compiling natively on the RIoT, but it does add other complications to the equation.

A reasonably large part of the delay with doing this stuff natively on the board can be down to the simple fact thes eMMC and SD cards are slow. A USB hard drive of the spinning rust variety can speed things up a lot.

I build most of my stuff on a Sabre-Lite, or Wandboard, or CubieTruck. The reason is simple, those all have SATA so I'm not limited by slow SD card speeds.

Yes but 45 minutes for Python is really long.

Even on the RaspberryPi that compiles a lot slower than the RIoTBoard it doesn´t take that long.

I´ll install the Image on my RIoTBoard and will look if I can reproduce the problem.

Yes but 45 minutes for Python is really long.

Even on the RaspberryPi that compiles a lot slower than the RIoTBoard it doesn´t take that long.

I´ll install the Image on my RIoTBoard and will look if I can reproduce the problem.

OK. The time and date on my board was set to 1970... I kept getting a message during the compile about some process or other being in 2012...

I've updated the time to now and tried make again,

now i'm getting stuff like this:

gcc -pthread -c -Wno-unused-result -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes    -I. -I./Include    -DPy_BUILD_CORE -o Objects/bytearrayobject.o Objects/bytearrayobject.c

which looks more promising,,,

Yup that´s looking good the compiler actually compiles something now.

Even i want to give it a try and check if its that slow .

I am away so can't do it now.

to keep away the time stuff set your clock to current time using below

date +%Y%m%d -s "20140526"

date +T -s "23:55:00"

this will set the clock and hopefully not give any future date warnings  or annoying 1970s stuff.

ooh! ooh! update!! make has finished so I've now executed sudo make install...

now thats going ahead... could it have been something to do with the time and date setting?

if so, I'd have been waiting 42 or so years for it to finish.

42 years ago the first microcontroller was being developed as a calculator on a chip!! 

thats great it compiled, i guess no more hurdles ahead.

. could it have been something to do with the time and date setting?

the make has nothing to do with time, not really.

even with "time in future.." warning which some time shows during package (build/install) i have managed to build and install some packages in Rpi long back.

but it looks annoying, so to shoo them off I just put it above .

just trying to help, if i can

42 years ago the first microcontroller was being developed as a calculator on a chip!! 

hopefully today some micro controllers are capable  of running python.

i never tried it, but some "micropython" exists out there.

steven scutt wrote:

 

OK. The time and date on my board was set to 1970... I kept getting a message during the compile about some process or other being in 2012...

Ah yes... various things stupidly check the clock and then fail to compile if the data/time is prior to the date/time the sourcecode was released... sane stuff uses relative changes in time from when you start the compile. You might end up needlessly compiling some extra stuff if the clock is in the past, but rather than failing it does actually work..

What you've seen is a case where some sub-project is continually referenced and each time it is it thinks something is 'wrong' and either rebuilds the whole thing every time or just fails at the ./configure step. configure can take a while itself, so what looks like a loop might either eventually finish successfully, or eventually fail.

Moral of the story: Set the clock before you start!

tuSharp tou have helped me no end.

All looks good now.

I've done the check & Python3 starts up no problem.

HURRAH!!!!!