ObjAsm "Hello, World!" help, please?

I’m going to admit defeat. I’ve been trying to work out how to print a string. Not a big deal. I know.

Here’s the story. I wrote a bare metal program with ObjAsm which runs on an Orange Pi PC and communicates with the UART
No matter what I did, I just couldn’t work out how to go through a string and print it. I can do other things including printing characters, messing with registers etc. This however has taken me forever, and the section of the program has been chopped around, rewritten etc so many times now I don’t even know what’s going on.

To make it easier on myself I stripped out all its other functionality, and changed it to a RISC OS program to save a lot of time with testing. That was trivial. The errors were the same either way. The problem was with churning through the string in memory. The character writing worked the same either way.

The outcome, I’ve gotten myself confused.

  AREA    |main|, CODE, READONLY, PIC
  GET     h.SWINames
  ENTRY
_start

  SWI  OS_GetEnv
  MOV  R13, R1
printloop

  MOV R0, #'H'
  bl send_charRO
  MOV R0, #'i'
  bl send_charRO

;newline
  MOV R0, #&D
  bl send_charRO
  MOV R0, #&A
  bl send_charRO

  LDR r0, =HelloWorld
  bl uart_println
  SWI OS_Exit
;b printloop

;blocking. sends a single character directly to the port.

;---------------------------------------------------------
;void uart_println(char*);

uart_println
  PUSH {R1-R5,LR}
  MOV R1, R0 ;string base addr in R1
uart_println_1

;R0: current_char
;R1: string_base and offset
;R3: byte_num
;R4: scratch
;R5: cur_text_word (current word of chars)
;load a word when R2 = 0
  AND R3, R1, #&3;#2_11 ;current byte of word
  CMP R3, #&0
  BNE uart_println_2 ;not 0. Just spit out a char.

;byte 0. Time to load a word.
  LDR R5, [R1] ;text word into R5


uart_println_2
  LSL R3, R1, #&3 ;rotate by 3 to change to bit # in the word
  AND R3, R3, #&000FF000

  LSR R4, R5, R3 ; rotate text word by R3 bits, and put in scratch.
;current byte should be LSB in scratch now.
  AND R0, R4, #&000000FF


  CMP R0, #&0 ;is it null?
  BEQ uart_println_return ;Yes. So exit
 ;Else
 ;send_char(char);
  BL send_charRO
  ADD R1, R1, #&1 ;increment counter
  B uart_println_1

uart_println_return
  POP  {R1-R5,LR}
  MOV PC, LR

;----------------------------------------------------------
;send_charRO(char);
send_charRO
  SWI OS_WriteC
  MOV PC, LR
;----------------------------------------------------------
  AREA |HELLODATA|, DATA, READONLY, PIC


HelloWorld DCB "Hello, World!", 0
    ;null terminated string
ALIGN
END

So there’s some cruft in there. I know. Also, yes I am aware that even though I called it println, there are no actual newlines in there.

*!RunImage
Hi
HHHHoooooooo!!!!*

It’s off to work we go…

This says to me that it’s doing something like only getting the same character for all four bytes of the word, and something else too. I’m going to replace the text with numbers so I can get a better sense. However I feel I have a basic misunderstanding in uart_println

Please, someone come along. Laugh at my mess and tell me what I’ve done wrong?

I plan on dropping the removed / altered parts back in etc once I’ve fixed it to run it as intended on the Orange Pi PC.

e: I replaced the text with “0123456789012” and saw “0000444488882222” so it is definitely just repeating the same byte 4 times before moving on to the next word. It was just blind luck that the null terminator was in the right position.

Take your pick

   PUSH {R0, LR}
   LDR R0, =HelloWorld
   BL write0
   POP {R0, PC}
write0
    PUSH {R0, R1, LR}
    MOV R1, R0
write0loop
    LDRB R0, [R1, #1]!
    CMP R0, #0
    POPEQ {R0, R1, PC}
    SWI OS_WriteC
    B write0loop

or

   LDR R0, =HelloWorld
    SWI OS_Write0

ObjAsm “Hello, World!” help, please?

https://www.riscosopen.org/wiki/documentation/show/A%20BASIC%20guide%20to%20ObjAsm ? :-)

Although the example on that page just uses OS_WriteS rather than writing characters one at a time, so won’t help much for your bare-metal work.

As for the actual bug in your code:

uart_println_2
  LSL R3, R1, #&3 ;rotate by 3 to change to bit # in the word
  AND R3, R3, #&000FF000

The mask you’re using with AND is wrong. You’ve shifted R1 left three bits, but you’re masking it as if you’ve shifted it three hex digits (i.e. 12 bits).

In ObjAsm you can do binary constants by prefixing the number with ‘2_’, so you could change the mask to 2_11000 (you can also do any other base between 2 and 9 by changing the leading digit accordingly).

Or you could just go with a more sensible approach like Colin’s and use LDRB :-)

OH! I knew there was something up with the bitmasks, but just couldn’t see it. Too long staring at that mangled mess of a program.
There was an LDRB, however I incorrectly thought it was causing an issue, removed it and ended up with some of that masking and shifting mess.

Colin’s version is much neater for sure. Very true that using an SWI to print a string is precisely what I can’t do though :)

I’m forcing myself to learn, especiially within the limited time constraints I have for doing this sort of thing these days. The listing I wrote initially was far neater, but wrong. So it didn’t matter.
Colin, I must confess I learned a few things from your short listing. The POPEQ is a great one! I didn’t realise it was possible to do that, especially with the PC.
Would someone mind explaining exactly what’s happening here?

 LDRB R0, [R1, #1]! 

Jeffrey. Thanks for the link! There are so many things on the Wiki which aren’t immediately obvious. There are some that I can still only find by going to a forum thread that I know has a link.

So far my best resources have been HeyRick! , davespace , The ARM quick reference cards and RO kernel source.

e: Found the exact answer myself. Very exact in fact.
http://www.heyrick.co.uk/armwiki/LDR

It’s actually wrong it should have been

LDRB R0, [R1], #1

LDRB R0, [R1, #1]! loads a byte at R1 + 1 and then because there is a ! at the end adds 1 to R1 (equivalent to R0 = *++R1; in C).

LDRB R0, [R1], #1 loads a byte at R1 then adds 1 to R1 (equivalent to R0 = *R1++; in C)

I didn’t want to post until I had positive results. I have them, but not as positive as I’d hoped. It worked fine in RO but fell apart in bare metal. The infutiating part was it could print single characters, but depending on changes I made the OPi would appear to lock up, or the print routines would print garbage.
It was part programmer error, part chasing ghosts.

First, the stack. It seemed to be stepping on some part of the bootloader. Something else seemed to be interfering with it but I just couldn’t quite work it out.

The printing garbage. Still haven’t worked that out. The only thing I can still put it down to is possible stack corruption, maybe. The memory area I’m using is safe.

The locking up. This is the big one. There were strange things occuring. Sometimes an otherwise still text screen with a rapidly pulsating cursor. Faster than VBlank because it was tearing. Sometimes the OPiPC would lock part way through the bootloader’s loading message, which was weird.
I got my hint today when I unplugged the power from the OPiPC during one of these locked screens when suddenly screens worth of text appeared. It was garbled but they consisted of a subset of the characters I should have been seeing.
Long story short, my “Hello, World!” program now sets up a hardware FIFO and monitors it’s state to avoid flooding. a simple loop based delay was also added after this, as my simple program was now capable of flooding the RPi Zero so badly that it locked solid.

On the positive side, I now have a nice slow churn of lines of “Hello” over the UART. It’s just sent a character at a time form the main loop. I still need to fix whatever’s upsetting the string printing.
It’s absolutely infuriating how easy it is to mess with it’s hardware yet the code I really need for basic debugging is exactly what’s not working. I’m sure that’s my fault. At least the underlying issue of character display has been dealt with.

Jeffrey. Thanks for the link! There are so many things on the Wiki which aren’t immediately obvious. There are some that I can still only find by going to a forum thread that I know has a link.

Yeah, working out how to structure things so that they can easily be found is a constant battle. Especially since the current wiki isn’t the most editor-friendly.

So far my best resources have been HeyRick! , davespace , The ARM quick reference cards and RO kernel source.

Davespace is a good resource, especially the Efficient C for ARM guide.

I initially learnt ARM code via a tutorial series in the Acorn Archimedes World magazine, and I think the tutorial is/was later made available online somewhere (I helped convert it to HTML, I think?), but I can’t remember enough details to be able to find it, to see if it would be any use for you. Maybe I still have a copy of the HTML version at home.

For what would be the most ubiquitous architecture on the planet, it is surprisingly hard to find good information on programming it!
I had a super quick look for the tutorials. Looks like some deeper digging is needed to find them. Hopefully they haven’t been lost to the ages like so much other useful information on the Internet.

No time today, but I’m going to flop my bare metal source back over to RO again and see what’s going on.
The reason I had send_char_RO on it’s own was to maintain consistency with the bare metal source. The debug send_char is monolithic, and gets called when needed.

I initially learnt ARM code via a tutorial series in the Acorn Archimedes World magazine, and I think the tutorial is/was later made available online somewhere (I helped convert it to HTML, I think?), but I can’t remember enough details to be able to find it, to see if it would be any use for you. Maybe I still have a copy of the HTML version at home.

Apparently, it is (almost) possible to erase something from the Internet. I was able to find my copy of the tutorial, and from that find the first part online, and an IconBar thread where I announced the series being available on Matthew’s (now dead) website, but no more. So I’ve tidied up my copy a bit and uploaded it to my site.

http://www.phlamethrower.co.uk/riscos/armforbeginners/

it is (almost) possible

IMpossible? My understanding is that it IS impossible to guarantee erasure, but that many things that someone erases may then be gone because no-one has copied them, and that many things disappear without anyone intending to erase them at all.

I’m surprised Jeffrey seems surprised by the “(almost) possible to erase something from the Internet” idea. While the last decade has been marked by the rise of Twitter/Facebook/Google and the idea that privacy is a mere fantasy, we in the RISC OS world have a pretty good example of something fairly effectively scoured from the ’net: movspclr.

When I had to go pull something off an Acorn User CD-ROM because it didn’t exist online (not even on archive.org), you know that with some effort, things can be erased.

Also, those of us of a certain age (which’ll be most of us grey-hairs!) will perhaps remember the vast swathes of content lost by the closure of geocities, and no, not all of it is on archive.org, only bits and pieces.

I wonder how many demon.co.uk domains are now just black holes?

I think more people are copying and archiving and storing stuff today, but in the earlier days… I guess nobody really thought about services closing down. But now it has happened, with the dot-com boom and bust, people are more aware of the ephemeral nature of data. And, yet, we’re all still expected to trust Cloud providers… :-)

It worked fine in RO but fell apart in bare metal. The infutiating part was it could print single characters, but depending on changes I made the OPi would appear to lock up, or the print routines would print garbage.

Just off the top of my head… RISC OS’s VDU drivers are not a real device. They’ll deal with data as fast as you can throw it.

A serial port? Not so much. You can easily output a hundred characters in the time it takes the port to send two. The other 98? Well, that’s the question.
What are you doing to ensure that you are not overrunning the serial port’s buffer? It won’t be particularly large.
While, at the same time, you’ll need to think of a clever way to avoid the problem that plagued many machines the ‘80s, that being what to do if the serial device is NOT connected (back then, they’d hang awaiting data being removed; but as modern devices don’t tend to have any sort of flow control, maybe this is less of a problem as the port can blind-send until it runs out of data).

Anyhow, check what your serial output routine is actually doing, and how it handles “I’m busy” situations.

For what would be the most ubiquitous architecture on the planet, it is surprisingly hard to find good information on programming it!

Well, do you mean ARM32? AArch64? Thumb? Thumb-2? On an A-series processor? An M core? :-)

Sometimes what you need might not be immediately obvious. For instance, programming the Gameboy Advance. I think that’s a 26 bit era ARM in Thumb mode (been ages since I looked), but there may be some useful routines in there…

Or, perhaps, a wander around here? https://www.osrtos.com/
There’s undoubtably a lot in C/C++, but some lower level stuff ought to be in assembler.

I also found this, a never-ending loop that will output a character as fast as it can:

    while(1)
    {
        while(1)
        {
            if(GET32(AUX_MU_LSR_REG)&0x20) break;
        }
        PUT32(AUX_MU_IO_REG,0x30+(ra++&7));
    }

It’s in C, but might give you an idea of what to check upon.

I’m surprised Jeffrey seems surprised by the “(almost) possible [etc.]

It’s one thing that things disappear whether we want them to or not; it’s quite another to erase them. You can never be sure they’ve really gone. If you don’t want them to have gone, they probably have; but it you want them gone, odds are they haven’t…

And, yet, we’re all still expected to trust Cloud providers…

In my office we’re all expected to distrust cloud providers¹ – even the ones that claim to have all the servers within the EU.
Apparently people get upset when the details of their nether regions (possibly with pictures) are placed in the hands of non-clinical people or even clinical people who have no legitimate connection.

¹ and we do distrust them. A lot.

even the ones that claim to have all the servers within the EU.

As Microsoft vs United States demonstrates, a server based within the EU means absolutely nothing when you have a judicial system that thinks it is not only completely acceptable to try to force an American company to hand over data stored in another sovereign state (presumably as it would be simpler than requesting said data through proper diplomatic channels), but also seems to think it is completely acceptable to do this and then gag anybody from mentioning it (re. FISA).

Probably the only reason we even know about this at all is because Microsoft said No and they didn’t get gagged quickly enough. What about all of the other such orders (especially those that didn’t even come from the judicial system) that were quietly honoured?

This is not to mention, as an NHS outfit you are dealing with people’s private data, and the moment such data hits “the cloud”, it should really no longer be treated as private. Paranoid? Maybe, but let’s see anybody who believes in the cloud prove that the data is secure and hasn’t been copied.
Encrypted, I hear you say? Fine, that means it probably hasn’t been ‘seen’ (yet), but not that there aren’t a dozen copies floating around Israel¹ and Lithuania¹…

Plus, while your servers may go down, you can determine why and estimate recovery times and know when the last backups were made (and hopefully, tested). For a cloud service? The five-nines uptime promise is not so useful when the service is down because AWS-West-1 is throwing a tantrum and you can’t tell your users when it’ll be back up because your provider can’t tell you because……

Cloud might be useful for spewing cat photos to the world. For serious uses? Not so much.

I’m tired beyond the capacity for any real high level thought, but I’ll do my best.

What are you doing to ensure that you are not overrunning the serial port’s buffer? It won’t be particularly large.

This one is pretty simple. I’m using one of the H3’s internal 16550 compatible UARTs. My simple program sets up UART0’s FIFO. uart_send_char which does what you’d expect checks whether the buffer is full before sending. If it is full, it just thrashes the register until it’s not full. Just a simple blocking IO routine.

Well, do you mean ARM32? AArch64? Thumb? Thumb-2? On an A-series processor? An M core? :-)

Point taken. ARM32. A series processor sounds good.
Now AArch64. There’s an interesting one. I think it’s the Orange Pi WinPlus that would be a really nice one to be able to slam into ARM32 mode and play with. Main reason being it’s more tablet based than STB based. It has a PMU and solder pads for a battery connector. The non-Plus version has them too. It’s just I’m a sucker for more RAM.

My RPi isn’t even set up right now. I had to pack everything up temporarily because of a chronic space deficit disorder. So no examples of my battered and bruised source.

I’ve found my problem. Or more accurately found things that point in it’s general direction. It’s puside the scope of this thread as I don’t believe it’s even to do with ObjAsm or even directly user error.

I can emulate the issue I’m having in the RO “port” of my program by not grabbing SP at the beginning. The exact same data abort occurs.
Something just isn’t right. I’ve tried putting the stack all over the place, using different methods but something is off.
Getting suspicious I grabbed some simple tests for Orange Pi PC that others have made and shunted them over, including a known good one that I based my work off originally. None of them worked correctly.

I already have an older thread that explores the odd behaviour somewhere on here. I believe it’s to do with U-Boot versions.

e: I built a fresh U-boot last night and am in the process of transplanting it on to an SD card.

Found the main Orange Pi PC thread that I made. Going to hop on over there for the “bare metal” but not really U-Boot loaded programs.

Crosscompiling to Orange Pi PC thread

This is within scope I believe. I’m just fiddling around with ObjAsm on RPi with RO as the target and I’ve hit another issue. It doesn’t seem to recognise MCR and MRC. Chapter 5 (Floating Point Instructions) of the Acorn Assembler manual kind of mumbles about their existence briefly but that’s it. To check I wasn’t going mad I used them in GNU assembler.
How does ObjAsm go about it?

How does ObjAsm go about it?

Using MCR and MRC!

MRC p15,0,r0,c0,c0,0

One thing to bear in mind is that BASIC uses ‘CP’ as the prefix for the coprocessor number, ObjAsm uses ‘P’. (Not sure offhand what gas uses – presumably something else if you’re having trouble)

Your syntax is the same as mine. I gave yours a shot anyway although I’m pretty sure you’re doing something like turning off the MMU there right? I haven’t looked it up explicitly. ObjAsm still can’t deal with it.

ARM AOF Macro Assembler 4.03 (Acorn Computers Ltd) [15 Oct 2015]
Error: Unknown opcode at line 11 in file SCSI::FC_USB.$.source.asm.copro.s.copro
   11 00000006    MRC p15, 0, r0, c0, c0, 0
Assembly terminated: 
1 Error, 0 Warnings

Odd. What command line options are you using?

I tried both with Drag and Drop to the ObjAsm icon and via a simple Obey file listed below.

objasm --cpu=Cortex-A7 --arm_only --keep copro.s -o copro.o
link copro.o -Output copro

The problem has disappeared by the way. I tried the old solution of rebooting. I can however sort of reproduce the problem by choosing UAL ARM.

It’s so strange. Anything else assembled fine, but it just completely broke when I tried using coprocessor mnemonics. Thanks for the help by the way. I do appreciate it.

It’s worth noting that the co-pro registers are case sensitive. They need to be lowercase.
I just came back to this today. It took me a few minutes to work out why it was getting upset about the register names.