Suggestions for microprocessor module

[brucehoult]

[Garmin fanboy 

I think I have two original 1999 eTrex somewhere. I recall seeing one of them in a drawer in the last year or so. I bought one and then someone gave me one without knowing I had one. No maps but very useful at the time with up to 500 saved named waypoints that it would show distance and bearing to. And you could record a track and later retrace it forwards or in reverse.

That's te only stand-alone GPS I've ever owned, other than a Cambridge Aero Instruments Model 10, given to me for free by the manufacturer half a dozen years earlier. One of the funnier memories of using that was in early 1994 walking on to an airfield I'd never been to before, near Maricopa AZ USA, and while walking into the clubhouse happening to recognise (from photos in books I owned) one Derek Piggott walking out to the carpark. I accosted him and asked if he would fly with me, assuming I could rent a glider, which he agreed to. We spent an hour zooming around at 10k ft, with Derek in the back seat playing with my GPS, which he said he had previously not seen one of.

[Analog Kid]

Oy, what a total fockin' mess this is ...

Strap yourself in and grab either some popcorn  or an alcoholic drink; it's going to be quite a ride:

So I pursued the path (CH32) suggested by Bruce Hoult, even though there was some kind of barrier every single step of the way.

Since I was told that this script (install_xpack_gcc.ps1) held the keys to the kingdom, I set about obtaining and running it.

First hurdle was obtaining a Git client and using it to clone the repository as Bruce said I needed to do.

Problem #0: getting a Git client that runs under Windows 7
I Googled (gawd how I hate using that verb!) for a compatible Git client.
I was cheerily told, by the "AI overview" (and also by several non-"AI" pages) that yes, there were several such clients that would run under my OS.

BULLSHIT!

Every single fucking one of them, when I went to the download page, said that they required either Windows 11 in most cases or Windows 8 in one or two. None of them ran under Windows 7!

Well, still undeterred, though thoroughly flummoxed, nevertheless in the spirit of "there must be a way!", I pressed on. Finally found one on about the 7th or 8th try. Turned out that NitroGit does indeed run under 7, so I used it, entered the URL of the repository and voila! there it was on my very own hard drive. (The software I downloaded, NitroGit, was only a crippleware demo, but it still allowed me to clone the stuff.)

Now back to that mysterious file, install_xpack_gcc.ps1, which was sitting there on my computah.

I didn't even know what this was at first; turns out it's a Windows PowerShell script. I'd never heard of those things, never had need to use them. I was about to learn.

Turns out I had PowerShell on my computah (comes with Windows 7, apparently). I tried running the script under it. That's when the real fun started.

Problem #1: how do I run the damn thing?
So I quickly figured out that PowerShell was basically a glorified "command window" using some of the same old DOS commands, so I was able to navigate to the script file by typing the drive letter, then using cd to get to the folder. (Hey, just like Unix, right?) So far, so good.

Typed the name of the script:

Code: [Select]

PS E:\Programming stuff\Assembly language\ch32\ch32fun\misc> install_xpack_gcc
install_xpack_gcc: The term 'install_xpack_gcc' is not recognized as a name of a cmdlet, function, script file, or
executable program.
Check the spelling of the name, or if a path was included, verify that the path is correct and try again.

Suggestion [3,General]: The command install_xpack_gcc was not found, but does exist in the current location. PowerShell
does not load commands from the current location by default. If you trust this command, instead type: ".\install_xpack_g
cc". See "get-help about_Command_Precedence" for more details.

OK, weird (why would they require you to prefix the filename with the "current path" identifier in order to run something? what crazed programmer thunk this up? someone's idea of a "safety feature"?) but OK, I can play along.

Problem #2: You don't have permission to run scripts!
After properly typing the script name prefixed with ".\" PowerShell told me that I wasn't allowed to run scripts! Something something about permissions. However, it did tell me, cryptically, how to correct that, which I did through some convoluted, overly-verbose "cmdlet" or other. Tried again.

Problem #3: PowerShell doesn't understand the god-damned script!
When attempting to run the script, I got an immediate error message saying that it didn't understand the keyword "using" which is the first damned thing in the file!

OK, to cut to the chase a bit quicker, it dawned on me that my version of PowerShell was probably older than what the script required. I did an online search for "upgrade powershell windows 7" or something and found a page (Reddit? forget exactly where) that had a link to the last version of PowerShell that would run under Windows 7. Downloaded and installed it (it also required a companion file, some Windows "MultiPkg" something or other which I first downloaded and installed).

After that I had a brand spanking new copy of PowerShell 7. Which I was finally able to use to run that script and install ... now what is it I'm installing? ... oh yeah, something called "Xpack".

Which I now have, somewhere on my C: drive.

Now that I have this stuff I'm still not sure what I'm supposed to do with it.
Stay tuned if you've read thus far and your eyes haven't completely glazed over ...

Quite a convoluted chain:
Git client→ GitHub repository→ PowerShell script→ Xpack stuff→ have fun with CH32

[brucehoult]

These all seem to be Windows issues. I don't use Windows, so really can't comment.

It seems PowerShell came out in 2006 and ran on Windows SP SP2. That's 20 years ago. By the time Windows 7 came out in 2009 PowerShell was installed by default. So that's 17 years ago.

Git came out in 2005 and needed Windows XP (not even a SP). There are certainly plenty of git clients that run on Windows 7, millions of people were using it by 2009, I would even say it was the de-facto standard by then.

Of course you might need to hunt down an older version.

I'm sorry that your PowerShell was too old to understand the PowerShell script in ch32fun. Glad you could find an update that worked.

Using Windows 7 you are likely to have exactly all these same problems getting and running software no matter what microcontroller you choose.

Except installing an old version of Arduino, which should be easy, as I've said a number of times.

But anyway it seems you now have a copy of ch32fun and it has successfully installed xPack compiler toolchain for you. Great!

Did you also install minichlink?

Are you following the Windows install instructions?

https://github.com/cnlohr/ch32fun/wiki/Installation#windows

I'm surprised you haven't ended up with GCC 14, but it does say there that the GCC 10 version you installed before is ok too.

Have you followed the Mingw64 setup instructions? I don't know whether you need an ancient release or not.

Oh!!  I don't think you've said whether you're using 32 bit or 64 bit Windows 7.  I've been assuming 64 bit.

[Analog Kid]

But anyway it seems you now have a copy of ch32fun and it has successfully installed xPack compiler toolchain for you. Great!

Did you also install minichlink?

Apparently I did:

Code: [Select]

[e:\programming stuff\assembly language\ch32\ch32fun\minichlink]minichlink --help
minichlink version - bc15212d10407f2ac58a8b05d65c3aee8b92c2c7
VID:0x1209, PID:0xb003
Error: Could not initialize any supported programmers

(Expected error since I don't have any programmer installed)

Are you following the Windows install instructions?

https://github.com/cnlohr/ch32fun/wiki/Installation#windows

I'm surprised you haven't ended up with GCC 14, but it does say there that the GCC 10 version you installed before is ok too.

Yes, I should have gotten 14; I ran that PowerShell script. But I have an embarrassing confession: I have no idea where it installed everything! It was silent, didn't tell me "installation complete" or where it installed to.
I've looked around everywhere on my C: drive, which is where I'd expect it to land, but haven't found anything except the stuff I downloaded previously.

What I have is what I managed to obtain earlier, somehow, don't even remember how. So perhaps I already have what I need ...

Have you followed the Mingw64 setup instructions? I don't know whether you need an ancient release or not.

Mingw64: what is that again? What do I need it for?

Oh!!  I don't think you've said whether you're using 32 bit or 64 bit Windows 7.  I've been assuming 64 bit.

64-bit here.

[Analog Kid]

So I think I have everything I need.
The installation I made has an earlier version of GCC (10), not the GCC14 that that installation page claimed it would install.
But that's OK, isn't it?

Regarding that last PM you sent me, Bruce, you mentioned making one of the examples (blink) to test things.
Of course, I can't do that until I get my hardware, which I'm not about to do until I'm pretty sure I have the software squared away.
In that makefile:

Code: [Select]

all : flash
TARGET:=blink
TARGET_MCU?=CH32V003
include ../../ch32fun/ch32fun.mk
flash : cv_flash
clean : cv_clean
I can see that the heavy lifting here is done by ch32fun.mk, which is a huge makefile.
I don't think I want to mess with editing that monster.

Should I just use this as-is and trust it to do the right thing when invoked?

In my programming (X86 assembly language) I'm used to a much simpler workflow:
assemble-link-run
where my "makefiles" are just DOS batch files that run the assembler, linker and maybe the resource compiler (or the library utility if I'm making a DLL).

I was hoping to do something like that here, but one look at that makefile has shown me that probably won't be the case here.

Is it possible to set up a simpler workflow like what I described?

And what programs, exactly, do I need to get a program assembled and loaded onto the microprocessor?

To assemble: riscv64-unknown-elf-gcc.exe
To link & load:  ____________________________

What else do I need?
Is there a debugger?

What do I need Mingw64 for?

[Renate]

Is it possible to set up a simpler workflow like what I described?

DOS batch files have some advantages if you want to do loops and things, but it is unstructured compared to a makefile.
The biggest problem with batch files is that it costs effort to do correctly:

Code: [Select]

do_something
if errorlevel 1 goto something_failed
do_another
if errorlevel 1 goto another_failedWith makefile you get that built in.
Even your silliest, non-programming, automated things could probably benefit from being a makefile

OTOH, some people have the attitude that you can shovel anything into a makefile without attempting to preserve clarity.

You want to assemble, link, [extract hex from elf], flash device, [post flash monitoring, UART, SWO, debug].
That needs a makefile of 25 lines, top.

[brucehoult]

So I think I have everything I need.
The installation I made has an earlier version of GCC (10), not the GCC14 that that installation page claimed it would install.
But that's OK, isn't it?

The instructions SAY it's ok.

I guess the install script didn't download xPack GCC 14 because you already had a RISC-V GCC in PATH

Regarding that last PM you sent me, Bruce, you mentioned making one of the examples (blink) to test things.
Of course, I can't do that until I get my hardware, which I'm not about to do until I'm pretty sure I have the software squared away.

You can do everything except the actual flashing.

I can see that the heavy lifting here is done by ch32fun.mk, which is a huge makefile.
I don't think I want to mess with editing that monster.

Should I just use this as-is and trust it to do the right thing when invoked?

Why on earth would you want to mess with it, when things are clearly set up so that you don't need to ever touch it?

It's only 450 lines, of which just over 300 lines is choosing the right options for different microcontroller models.

You could cut out the config for the ones you're not using, and just keep the 7 lines out of that 307 that are for CH32V003, but what harm do the others do? One day you might have a board with one of them.

Is it possible to set up a simpler workflow like what I described?

Of course it is possible, given sufficient knowledge.

Or just take note of what things the standard makefile runs, with what arguments.

And what programs, exactly, do I need to get a program assembled and loaded onto the microprocessor?

I don't know. Observe what that makefile runs.

But why mess with it? It's there, it's done, it works. (presumably .. it does for everyone else)

Is there a debugger?

Of course. make gdbserver or make gdbclient as you prefer.

What do I need Mingw64 for?

No idea. It's a Windows thing. I don't do Windows. As I understand (maybe wrongly) it provides development tools similar to cygwin but Windows native. Both have been around since last century.

[Analog Kid]

Scratch what I wrote in that last previous post.
You're right: I don't need to know all the ins and outs of the process here.
I was thinking I could make the workflow similar to my MASM one, but that clearly isn't at all practical.
I can treat the make process as a black box, so long as it works.
I'm going to experiment with the examples in the package, see if I can get them to make (without executing, of course).

However, I will need to know a few things.
Mainly, how to create my own makefiles (the small ones for each project), since I'm using assembly source instead of C.
Shouldn't be to difficult, I hope.

And of course I need to set up the correct paths. Fortunately I have a very flexible command processor (4DOS) which makes this much easier than the default Windows command window which is pretty primitive.

Maybe I don't need Mingw64.

There are some small problems, of course:
One is the difference between Unix-type text files that only use linefeeds as line endings and the standard ASCII text files used in the Windoze world which have carriage return/line feed endings, but I can deal with that. (When I open any text file in the Xpack package in a text editor it looks like a huge blob of text. I'll add a command to my homemade text editor to convert LF-->CR/LF.)

Will report back after experimentation. I feel the target is coming within range.

[Renate]

I'll add a command to my homemade text editor to convert LF-->CR/LF.

Do not do that.
There is not anything in Windows that does not accept Newline (LF) as EOL (end of line).

[Analog Kid]

I'll add a command to my homemade text editor to convert LF-->CR/LF.

Do not do that.
There is not anything in Windows that does not accept Newline (LF) as EOL (end of line).

Except that, as I pointed out, if you open a LF-only file in an editor that expects CR/LF, you get one humongous block of text which is a pain in the ass to deal with.

Yes, Notepad, etc, will open a LF-only file but it looks like crap. So no, it does not interpret a single line feed as EOL.

[brucehoult]

Mainly, how to create my own makefiles (the small ones for each project), since I'm using assembly source instead of C.

Just do what they do. And name your program blink.s instead of blink.c and in the makefile before the include add

    TARGET_EXT:=s

That changes the file that is looked for with the same name as the directory/project/target.

If you have more source code files add

    ADDITIONAL_C_FILES:=foo.s bar.c

It doesn't matter that they're not C. GCC just does the right thing based on the extension.

There are some small problems, of course:
One is the difference between Unix-type text files that only use linefeeds as line endings and the standard ASCII text files used in the Windoze world which have carriage return/line feed endings, but I can deal with that. (When I open any text file in the Xpack package in a text editor it looks like a huge blob of text. I'll add a command to my homemade text editor to convert LF-->CR/LF.)

That hasn't been a problem any time this century for any reasonable programmer's text editor on any platform. They all accept files with any common line ending convention, display and edit them properly, and write them back in the same format they found them.

vi, emacs, VSCode, Visual Studio, XCode, Kate, Sublime, TextMate, Notepad++ all handle this just fine.

As does the built in Notepad in Win10 or newer.

[paulca]

I find the theme of these posts frustrating.  To summarise...

"I have a very 1990s problem."
"We have solutions for that decades old already, you don't need to follow the pain."
"I don't want any of that modern junk."

Later.

"This sucks it's rubbish, why is it this hard...."

I think there is an element of "Romanticising the past" with rose tinted specs and the total frustration is not just "its hard", it's invalidating the theory that things were better in the past.  When they just sucked indifferent ways you forgot about.

[paulca]

Its the same parallel in the much younger software. 

In the 1980s things where just how they were, set by the limitations of the hardware and software of the day.

As technologies advances though, some of the first fodder feeding it is the "Problems and annoyances" of the development itself.  A wise man once defined a "Utility" as - an application used to manage a problem you never had until you had a computer.

Manhattan A3 sized PCBs in a rack became FPGAs.  Modern software languages got higher and higher level.  The platforms nested inside each other and visualised.

In digital electronics parallel buses where the thing.... until they weren't and everything went serial.  Servers and Workstations used to be fixed hardware/software couplling, today they no longer are.

Take something like:  "This CPLD programmer only works on WindowsXP".

In a 2000s world, that means you first gotta find hardware that will run Windows XP.  Buy it.  Power it.  Find a CD and install Windows XP on it, then maintain it.  Hours or days.

In the 2020s, if I had a Windows XP ISO image, that takes me about 1 minute to install it on a virtual PC.  A few clicks.  Forward USB or Serial ports.  Use a basic virtual video card which gives you a view port, or install network desktop software for a better experience.  Make its base files "READ ONLY" and let the running VM "copy on write" from a snapshot which you can roll back or just discard.  Once it's set up, you literally fix it in time.  It boots like it's groundhog day the movie.  The exact same, byte for byte hard disk every single boot.

Need 3 different versions of make and FPGA tools for a project? Don't fight them all and trash your "only dev env" by installing them all on top of each other and hoping the OS and your environment variables keep working and you remember them... create 3 different variants of a build harness, one for each in containers.  There are many mechanisms to have "containerised loads" operate on the current folder as if they were actual commands.  This is just an extension of the "build the builder" which a lot of complex C applications have been doing for decades.  The first phase of the make file creates a "build" folder and copies/sets up the components required, then cd'ing in and running "make" there again.  Just the boundary moved to encapsulate the whole OS "in the build folder" and the build folder a docker image.