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.

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.

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,,,

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

should take that long, may be it has something to do with the eMMC latency.

did you try using apt-get, i guess 2.7 based armel packages will be available.

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

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

tuSharp tou have helped me no end.

All looks good now.

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

HURRAH!!!!!