|
The best starting point would be the manual for the assembler language that you are learning.
|
|
|
|
|
Thanks for feedback. I`m not using a manual as reference, I`m learning on my own.
modified 21-Feb-20 9:27am.
|
|
|
|
|
Well you must be extremely talented.
|
|
|
|
|
thank`s for your compliment, I`m no different than any other person though.
|
|
|
|
|
The point I was trying to make is that you need to make use of the learning materials that are available. And in the age of the internet there are millions of them.
|
|
|
|
|
I do what I can but I haven`t found exactly what I was looking for, though that`s only because I wasn`t looking for the right thing maybe. I know there is tons of material out there but I don`t trust them unless I`m specifically pointed to a resource by someone.
Richard thanks for your useful feedback.
modified 21-Feb-20 14:05pm.
|
|
|
|
|
Hi,
I had a nicely operating cross compilation tool setup ( see the article I wrote about it Toolset to Cross Compile/Remote Debug Raspberry from Windows Host[^] )
Today I tried to run a python script but it needed python 3.7. I did not have that in the Msys32 setup I was using. After some searching I tried to put the Msys32 configuration up to date but it completely failed and became totally inoperable. It was not even possible to start the Mingw32 shell in it any more.
I Also had an Msys64 setup available and tried to update that one and it worked perfectly. I installed python 3.8.1.1 and was able to run the python script from within the updated Mingw64 shell. The Msys64 setup also contains a Mingw32 shell which runs equally well.
So far so good but now I have a completely different problem: whenever I try to run the make command for my project ( either manually in the Mingw32 or Mingw64 shell or from Visual studio code ) I get a really odd error message:
$ make
mkdir -p build/./main/
The syntax of the command is incorrect.
make: *** [build/./main/hello_world_main.c.o] Error 1
It is the mkdir -p build/./main/ which appears to be the culprit but strangely enough that used to work perfectly and when I type the exact same command from within either the Mingw32 or Mingw64 shell it executes perfectly without the slightest trace of an error message.
For completeness I have included the Makefile content below but this has really thrown a spanner in the works. Does anyone have an idea as to what may be the cause of this?
TARGET_EXEC ?= Hello_world_c
BUILD_DIR ?= ./build
SRC_DIRS ?= ./main
SYSROOT = $(RPIDEV_LOC)/arm-linux-gnueabihf/sysroot
CROSS_COMPILE = $(RPIDEV_LOC)/bin/arm-linux-gnueabihf
CXX = $(CROSS_COMPILE)-g++ --sysroot $(SYSROOT)
CC = $(CROSS_COMPILE)-gcc --sysroot $(SYSROOT) -lpigpio
AS = $(CROSS_COMPILE)-as
AR = $(CROSS_COMPILE)-ar
NM = $(CROSS_COMPILE)-nm
LD = $(CROSS_COMPILE)-ld
SRCS := $(shell find $(SRC_DIRS) -name *.cpp -or -name *.c -or -name *.s)
OBJS := $(SRCS:%=$(BUILD_DIR)/%.o)
DEPS := $(OBJS:.o=.d)
INC_DIRS := $(shell find $(SRC_DIRS) -type d)
INC_FLAGS := $(addprefix -I,$(INC_DIRS))
CPPFLAGS ?= $(INC_FLAGS) -MMD -MP -g
$(BUILD_DIR)/$(TARGET_EXEC): $(OBJS)
$(CC) $(OBJS) -o $@ $(LDFLAGS)
# assembly
$(BUILD_DIR)/%.s.o: %.s
$(MKDIR_P) $(dir $@)
$(AS) $(ASFLAGS) -c $< -o $@
# c source
$(BUILD_DIR)/%.c.o: %.c
$(MKDIR_P) $(dir $@)
$(CC) $(CPPFLAGS) $(CFLAGS) -c $< -o $@
# c++ source
$(BUILD_DIR)/%.cpp.o: %.cpp
$(MKDIR_P) $(dir $@)
$(CXX) $(CPPFLAGS) $(CXXFLAGS) -c $< -o $@
.PHONY: clean
clean:
$(RM) -r $(BUILD_DIR)
-include $(DEPS)
MKDIR_P ?= mkdir -p
|
|
|
|
|
I can't recall which one it is but there is an option* in make to list everything as it proceeds. That may help to isolate the problem.
*I think -n will process the makefile but not execute the resulting statements
Possibly -p to list everything
|
|
|
|
|
Richard MacCutchan wrote: *I think -n will process the makefile but not execute the resulting statements
Possibly -p to list everything
correct. But you're going to want to do
make -p > make.out 2>&1 and then use an editor to view the results.
$ make -p hello.c | wc -l
1481
$
So that's ~1500 lines for a simple one liner. And then you're going to have to wade through all the rules for everything from c, c++ to lexx/yacc and fortran, etc.
|
|
|
|
|
No big deal with a modern editor to find the key parts.
|
|
|
|
|
Just took a look and it seems that the commands make will process are at or near the top of the file, and then the rules that make used follow e.g.
$ make -p hello > make.out 2>&1
$ head -20 make.out
cc hello.c -o hello
# GNU Make 4.2.1
# Built for arm-unknown-linux-gnueabihf
# Copyright (C) 1988-2016 Free Software Foundation, Inc.
# License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
# This is free software: you are free to change and redistribute it.
# There is NO WARRANTY, to the extent permitted by law.
# Make data base, printed on Tue Feb 4 12:02:00 2020
# Variables
# automatic
<D = $(patsubst %/,%,$(dir $<))
# automatic
?F = $(notdir $?)
# default
.SHELLFLAGS := -c
# environment
XDG_SESSION_CLASS = user
$
Trying to figure out the rules that make used to generate the commands can sometimes be challenging, though.
|
|
|
|
|
As Charles Petzold famously wrote in "Programming Windows 3.1", "No one said it would be easy".
|
|
|
|
|
If it was easy, any idiot could do it. The main problem, as I see it, is many of them think they can 
|
|
|
|
|
And we know where they get their code from.
|
|
|
|
|
Hi Richard,
Thanks for the info: it helped to find the solution. I will explain what the solution is as a reply to the original message.
|
|
|
|
|
Hi All,
Based on Richard's first reply I managed to find the solution which is based on some info I found here:
How to force make to use bash as a shell on Windows/MSYS2 - Stack Overflow[^]
It is one of the results I got for this google search: temporary batch file created by make does not work msys2
The reason for that search is that Richard suggested there is an option to ensure that make's output becomes a lot more verbose. The option is -d and it produces a lot more output if you use it.
In that output I noticed that make created a temporary batch file and tried to execute it but failed.
The content of that batch file was this: mkdir -p build/./main/, exactly the error that a standard make call produced.
So: apparently make could not execute the batch files it creates itself so I googled so as to know why and found the result mentioned above.
It suggested I was using the wrong version of make to try and build my application and as it turns out that was exactly what was wrong.
The make I was using was the one that was installed with the toolchain and when you type make -v it reports:
GNU Make 3.82
Built for i686-pc-mingw32
I then used pacman -S make to install the proper make version and that one reports this:
GNU Make 4.3
Built for x86_64-pc-msys
End result: when you run things in the latest mingw64 or mingw32 shell it requires the newer make version built for msys instead of the earlier version which did work in the older version of mingw32 shell. When I use the later version of make Built for x86_64-pc-msys it works like a charm again.
|
|
|
|
|
Thanks for such a comprehensive explanation. I am sure it will be useful for others.
|
|
|
|
|
Use SCP Command to Transfer Files/Folders in Linux
|
|
|
|
|
The man page for scp has what you need to do this
cheers
|
|
|
|
|
Hi,
Not so long ago I managed to set up Cross platform development to build applications for a Raspberry PI running Raspbian from a windows 10 machine as described in this article I wrote: Toolset to Cross Compile/Remote Debug Raspberry from Windows Host[^].
What is does is build an example application ( simply "hello world" ) on the windows machine, transfer it to the raspberry PI and run/debug it using a GDB server on the Pi and a GDB client from Vscode on the windows machine.
Now I would like to try and expand that a bit to develop a GUI based application in the same way.
I have done some checking and I think that using the GTK-2.0 library is probably the way to go. On the PI I have installed that library successfully but now I would like to transfer it to the appropriate location in the msys32 directory where the cross compilation tools are located as well. The problem is that it is not entirely clear to me where all the header and library files are located on the PI. Running pkg-config --cflags --libs gtk+-2.0 does tell me what I should add as extra includes when I run the gcc build tool on the PI but it is not clear how and where I could copy the required header and library files so that the cross compilation tool on the windows machine could find them.
Any suggestions/ideas would be very much appreciated.
Edit: added "directory' to indicate that the mentioned msys32 is a directory.
|
|
|
|
|
WinForms is also supported, and may be easier to use/setup.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Thanks. I have recently done an application like that: a VB.NET application developed/built on a Windows 10 machine and then executed on the Raspberry PI using mono. It worked well but I am now investigating if there is a more native way to do it.
I have found some interesting info in a document called "An introduction to C&GUI programming" by Simon Long, one of the engineers who works for the Raspberry PI Foundation.
Unfortunately everything in it is built on the Raspberry PI itself via command line etc... and I really like to use my VScode IDE on my Windows machine  .
If I don't succeed I will revert to Visual studio, C#.NET and mono on the PI but I will keep looking for a while.
|
|
|
|
|
You may want to try GtkSharp | Mono[^]; also download the MonoDevelop IDE; it allows you to "draw" UI's, like VS does for WinForms.
A quick Google implied that VS can do that natively; GTK# Platform Setup - Xamarin | Microsoft Docs[^], but never tried it. If you try it and it works, please let me know 
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Have you looked at using the remote compile option for VS? That way you don't need to figure out how to get the GTK2.0 libs and headers on Windows.
If you're looking at developing GUI programs, do you know about VcXrv or Xming, which provide XWindows servers on a Windows system?
|
|
|
|
|
Thanks for the info, I didn't know of any of those. I will check out all of them.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
