sdr_transceiver_hpsdr C-Programm mod

[Werner B]

Hallo,
gibt es irgendeine probate Möglichkeit den C-Code “sdr_transceiver_hpsdr“ zu ändern ?
Ich habe nun >> 100 Stunden lang versucht irgendeine IDE, SDK, (nenn es wie du willst) zum Laufen zu bekommen.
Google glüht noch …
Alle Anleitungen münden in ein heilloses Durcheinander.
Möglicherweise könnte ich nun die FPGA verhunzen, das will ich aber nicht.

Mit ECLIPSE komme ich noch am weitesten.
Ich kann das ändern und kompilieren, kann den RedPitaya einbinden, kann es jedoch nicht debuggen.
„Could not determine GDB version using command: /opt/Xilinx/SDK/2017.2/gnu/aarch32/lin/gcc-arm-linux-gnueabi/bin/runtest –version Unexpected output format: ERROR: unable to find expect in the PATH“

Für Vivado wird immer das FPGA Design erklärt ?
Schließlich habe ich HLS „entdeckt“, im „richtigen“ Programm kann ich es aber nicht kompilieren
und somit auch nicht simulieren ( was mir am liebsten wäre )
Einige "includes" werden nicht aufgelöst ? Der "cross Compiler" geht ?
Ich kenne mich ein wenig mit IDEs(SDK) aus, IAR, KEIL, AVR Studio(VisualStudio), finde meinen Weg.
Ich frage mich was die Leute bei Vivado rauchen, so ein Sch.. G(U)I ohne User. 30GB bullshiut

Hat / kennt jemand eine funktionierende Lösung ?
Meinetwegen auch gerne WINDOWS , damit hatte ich aber die ärgsten Probleme.
OS spezifisch …

ORACLE Virtual Box
Version 5.2.8 r121009 (Qt5.6.2)

LINUX UNBUNTU 16.04

Eclipse IDE for C/C++ Developers
Version: Oxygen.2 Release (4.7.2)

Xilinx Vivado 2017.2 HL,HLS und SDK

Wozu ?
Ich möchte zurück auf den kleinsten gemeinsamen Nenner.
Ich möchte auf den EP2 des METIS Protokoll aufsetzen.
Bis hier wäre alles gleich und somit wäre es auch Wurst welches SDR PC Programm benutzt wird.
Was der RedPitaya nicht selbst verwirklicht sollte die angeschlossene Hardware sich selbst decodieren.

Grüße
Werner

[Werner B]

Hello Pavel,

I am not a native C-person, but might get around with some help from a good IDE.
With TTY “gedit” and a command line “gcc” I will be lost. Disastrous trial and error …
I cannot imagine the C-part of the coding is always done like that and I wonder why none of the guidance leads to anything functional.

I have got the strange feeling, some things can be seen UDP on the C&C at EP2 but they just don’t get passed out the Red Pitaya the right way …
Now it is hard to trace and impossible to debug :O(
I am also missing the heart beat of the round robbing at EP2.
My system is HAMLAB alike, used both worlds and needs to know if openHPSDR is powered or off, up and running or down.

Best regards
Werner

[Werner B]

Ups that is simultanious...
I came across this hardware floating versus software.
Hundreds of hits at google, all leading to a dead end with no answers finally.
At one point cross compiling failed with *hf, can’t remember which constellation.
File not found …
Just found it, some sources ECLIPSE is doing that :
/lib/ld-linux-armhf.so.3: No such file or Directory
Just putting it there raises new errors ..

I will check out your link, but I only got WINDOWS 7 prof 64bit.

[Werner B]

Hello Pavel,
thank you very much.
Strange it doesn’t work like this on my side ( again )
I found some instructions last night

that do seem to make some sense for Eclipse ? It needs all steps ?!?

But it is ( I'm) missing a number of declarations ?
And I am not really sure what it is doing, the includes do not look right.
It will show ARM for new, empty projects ( vanishing as soon ... )

I had thought someone, somewhere pops up :
“ Here is a copy of my ECLIPSE, KEIL, IAR, VisualStudio etc. project, template, export etc.” ready to roll.
May be a Xilinx thing with a few hundred pages on how to easily import it again :O)

Is all that can be done with it a blinky LED, letter by letter on a command line ?
And does it take a FPGA to make it blink ?

It all seems to be a waste of time.

Best regards
Werner

[Werner B]

it all seems to be there.

It still doesn't built any usefull "bin"

Some defines / declares are bugging it ?
Some options are "wrong" ?
I don't know anymore.

Connecting Red Pitaya / remote file System does not seem to be a problem though.
May be it even would debug ....

[Werner B]

Hello Pavel,

… GNU autoconf, configure and make scripts for GNU compiler, binutils and eglibc are extremely large and complex software.
Unlike normal software development, it is almost always impossible to decipher any useful information from printed error messages.
Nobody in the world except elite GNU developers understands them.
If something does wrong, go Google for it. Probably someone already saw that particular problem. In any case, trying to handle it entirely by yourself is just waste of time.
Because the entire thing is very fragile and it's very easy to break something in the course, it's very important to perform all actions on the virtual machine(s) and take snapshots after each major success. Otherwise you'll have to restart this Rube Goldbergy each from the scratch.
Only few will go all the way to the end, and everyone of those people will have strong personal qualities of perseverance and total neglection of failures. Impatient and emotional character types should …
I've got some from the link … there is a piece of hardware.
The hardest part is done in the FPGA, thanks to Pavel.
I could imagine a number of things to be done with the rest of it.
Unfortunately it would be a quantum leap and I am not going for.
Some 40 years ago I used to toggle binaries in d-i-g-i-t-a-l PDP8. Yes, I was happy when we got a punched tape reader …
But I m not going to develop and debug with an egg and a tooth pick on a Red Pitaya..
It simply isn’t spread and supported like Arduinos, Discoveries, Raspberries and name it ... Where you setup an IDE in two or three mouse clicks.
I will just leave it alone.

Best Regards
Werner

P.S. yes, it doesn't do "Hello World" either.
But I can do it from a TTY console ...

[Werner B]

Hello Pavel,
I can leave some question marks. But I don’t think I know what I’m talking about anymore.

Years ago I’ve been playing with STM32F407VGT6-Mikrocontroller ARM Cortex®-M4 and ST-Link to xyz IDE.
Latest Raspberry is Cortex-A53 ?
For WINDOWS all free cross compilers I can find are bare metall and ARMv8-M (Hard FP) latest.

We are up to ARM-9 hardware floating point ?
They say there is for LINUX ? But it seems to be a rumor away from the command line Interpreter ?

There must be one inside Vivado but I am just too stupid for HLS or should it be SDK ?
I even cannot really figure the purpose of their three programs ?

All I can see and find is :
/lib/ld-linux-armhf.so.3: No such file or directory.
With no solution ?
May be just the *hf is the point where it all crashes about ?

Best regards
Werner

[Uli DF5SF]

Hello Werner,
your first question was, how to change the C-code:

Hallo,
gibt es irgendeine probate Möglichkeit den C-Code “sdr_transceiver_hpsdr“ zu ändern ?

I have the following simple solution. It is working here since several weeks:

On Windows you need FTP-client with SFTP-protocol (e.g. filezilla), SSH-client (e.g. putty) and an ASCII-editor (e.g. notepad++)

On RedPitaya I have RedPitaya GNU/Linux Ecosystem V0.97 Build 560 with Ubuntu 16.04.3 LTS (GNU/Linux 4.4.0-xilinx armv71). Last update 03.01.2018.

Now connect to RedPitaya with SSH, change to directory /opt/redpitaya/www/apps/sdr_transceiver_hpsdr and the following command:
# rw

Now connect with FTP-Client (SFTP-Protocol) to RedPitaya. Change to directory /opt/redpitaya/www/apps/sdr_transceiver_hpsdr
Among other files you see Makefile and sdr-transceiver-hpsdr.c Download the C-file and make your changes. After that upload the file.

After this you can compile with following commands:
# make clean
# make
# ro

Restart RedPitaya and you have your new version. That's it. I hope it helps ....

[Werner B]

Hello Pavel, Hello Uli.

Thank you Uli. I think there must be better ways. What you do and describe is the traditional trial and error.
Which isn’t what I am used to and what I am looking for. I should have asked better.
A good IDE ( EDT, SDK etc) will make life a lot easier. Coding can be fun.
More efficient, less time consuming, less error prone is what I expect from a 300Euro single board computer in 2018.
When you read the RP docs you might get the impression there is.

It doesn’t clearly say here is what you will need for FPGA design.
This is where I took the wrong turn ? I didn’t know that all of this hustle is useless for what I want to do.
The SDK is mentioned to be added and it is only a few percent of the whole 30 GB bundle.
The second best disaster has been the Vivado installation.
It does not install the promised program icon, short cuts, etc. Repeatedly on my side and according to google on many other user’s end as well.
Most end up with not knowing how and what to start ( under LINUX only ?).

A very busy thread in their forum is about just launching one of their programs. I.e. SDK.
See a three page thread on how to lauch it :O( There is a large community that wonders what and how to start at all.
https://forums.xilinx.com/t5/Embedded-D ... d-p/693615
Typical confusing Xilinx stuff.

(**** Picture greeting from Eclipse ***)
Then you will be surprised to end up in yet another ECLIPSE installation.
It comes unnoticed and in disguise named as a Xilinx SDK.
You probably should not have two gods at a time ?

(**** Screen shot of ECLIPSE II alias EDT (SDK) Vivado ****)
It doesn’t mean ECLIPSE II is working yet, but it isn’t dummy dead as ECLIPSE I in the end…
I wish I had tested ECLIPSE I before installing ECLIPSE II.

73 Werner
somehow I cannot add any files or pictures anymore.

[Werner B]

I agree on ECLIPSE.
But RP recommends Vivado SDK which is ECLIPSE in the bitter end.
I am very disappointed, left in the rain with setting up ECLIPSE myself.
RP does not give a prebuilt “Hello World!” example, ready to roll, fixing the ECLIPSE SDK for me ?
Hardware, board, OS …

[DH1AKF]

Hallo Werner,
den Hinweisen von Uli, DF5SF kann ich vollkommen zustimmen: Genau so entwickle ich die Software für den "DiscoRedTRX" (eine PC- unabhängige Lösung mit STM32F7Discovery) weiter.
Sicher wäre ein Echtzeit- Debugger wünschenswert, aber für dynamische Prozesse muss man sich schon selbst etwas einfallen lassen.
Interessant wäre zu wissen, wie Detlev (DL4AOI) dieses Problem angepackt hat.
73, Wolfgang

[Uli DF5SF]

Hallo,

Debuggen findet hauptsächlich im Kopf statt.
Dafür setze ich im Source-Code an "entscheidenden Stellen" den Befehl fprintf(stderr,......). Hiermit kann man sich Kommentare und Inhalt von Variablen anzeigen lassen.
Wenn es ganz schwierig wird lenke ich diese Ausgabe in eine Datei um 2>>.
Da ich unter Linux nicht ausdrucken kann, wird diese Datei mit FTP auf Windows übertragen und von dort gedruckt. Klinkt "amateurhaft", aber es funktioniert.

[Werner B]

Hallo zusammen
auf diese Art finde ich es zu mühsam...

@Pavel
“Read the docs” keeps misleading me.
This time installing the (SDK) development machine unwillingly destroyed the existing C/C++ ARM ECLIPSE IDE finally both were not working.
RP seems to be in love with FPGAs.
For now I don’t care if that is “Field”, “Factory” or “Not at all” programmable. If it was a bunch of hard wired TTL chips doing the DDC and DUC job, fine.

73 Werner

[Werner B]

Is it possible to compile the “sdr-transceiver-hpsdr” UDP server ( and subsets of its code ) on my VMbox and for the VMbox ?
I have tried “Make” and of cause it does not invoke the cross compiler tool chain on a x86_64 machine.

arm-linux-gnueabihf-gcc -static -O3 -march=armv7-a -mcpu=cortex-a9 -mtune=cortex-a9 -mfpu=neon -mfloat-abi=hard -D_GNU_SOURCE sdr-transceiver-hpsdr.c -o sdr-transceiver-hpsdr -lm –lpthread
does not work at all.
arm-linux-gnueabihf-gcc -static -O3 -march=armv7-a -mcpu=cortex-a9 -mtune=cortex-a9 -mfpu=neon -mfloat-abi=hard -D_GNU_SOURCE -lm –lpthread sdr-transceiver-hpsdr.c -o sdr-transceiver-hpsdr
will do some, with some missing arithmetic …
Both would not be usable binaries for local debug and simulation.

gcc -static -O3 -D_GNU_SOURCE sdr-transceiver-hpsdr.c -o sdr-transceiver-hpsdr -lm –lpthread
gcc: error: –lpthread: Datei oder Verzeichnis nicht gefunden
gcc -static -O3 -D_GNU_SOURCE –lm –lpthread sdr-transceiver-hpsdr.c -o sdr-transceiver-hpsdr
a longs list
sdr-transceiver-hpsdr.c: In function ‘icom_write’:
sdr-transceiver-hpsdr.c:334:22: warning: ignoring return value of ‘write’, declared with attribute warn_unused_result [-Wunused-result]
if(uart_fd >= 0) write(uart_fd, buffer, 10);
^
/tmp/cckSHPSb.o: In Funktion `calc_log_lookup':
sdr-transceiver-hpsdr.c:(.text+0x16b5): Nicht definierter Verweis auf `log10'
/tmp/cckSHPSb.o: In Funktion `process_ep2'
sdr-transceiver-hpsdr.c:(.text+0x20aa): Nicht definierter Verweis auf `trunc'
…
/tmp/cckSHPSb.o: In Funktion `main':
sdr-transceiver-hpsdr.c:(.text.startup+0xa0a): Nicht definierter Verweis auf `cos'
…
sdr-transceiver-hpsdr.c:(.text.startup+0xb07): Nicht definierter Verweis auf `floor'
sdr-transceiver-hpsdr.c:(.text.startup+0xcf6): Nicht definierter Verweis auf `pthread_attr_init'
sdr-transceiver-hpsdr.c:(.text.startup+0xd08): Nicht definierter Verweis auf `pthread_attr_setinheritsched' ….


With Netbeans and Eclipse building for LINUX x86_64 is always stuck with “datagram” ?!? More or less the same error

and a number of subsequent errors ?

“mmsghdr” should be a structure of “msghdr”s + size defined in “socket.h” ?
They are called datagrams but … where is “datagram” defined ?
Why isn’t “datagram” interpreted ?
I only would like to try and test a few minor changes to the I²C interfaces…
lets say a different approach.

73 Werner

[dl1ycf]

Well, all this is somehow mixed. The definite fact is: if you ONLY want to modify sdr-transceiver-hpsdr.c, you just copy this file on the RedPitaya and compile it there with

gcc -O2 -march=armv7-a -mcpu=cortex-a9 -mtune=cortex-a9 -mfpu=neon -mfloat-abi=hard sdr-transceiver-hpsdr sdr-transceiver-hpsdr.c -static -lm -lpthread

This is all you need to play around with HPSDR protocols etc., that is, as long as you do not need to modify the FPGA bitstream.

I followed this for properly implementing a TCP connection (rather than UDP), and the debugging is with printf to stderr and watching the screen.

Yours, DL1YCF