One Dollar One Minute ARM Development

[westfw]

(instead of vague statements on a forum which is the case with STM32)

The code I've been looking at has big headers:

Code: [Select]

* <h2><center>&copy; COPYRIGHT 2012 STMicroelectronics</center></h2>
  *
  * Licensed under MCD-ST Liberty SW License Agreement V2, (the "License");
  * You may not use this file except in compliance with the License.
  * You may obtain a copy of the License at:
  *
  *        http://www.st.com/software_license_agreement_liberty_v2
  *That doesn't seem vague.  (although, since it's not one of the much-discussed OSSW licenses, it might take thousands of dollars worth of lawyers before I could have a high confidence that some of the things I've done (like turning the .h files into assembler format includes) are actually permissible.  Especially if I wanted to, say, SELL them... ("My business plan predicts that there is a HUGE market catering to people who want to program ARMs in assembly language.  I'm going to be rich!")

[aon]

The code I've been looking at has big headers:

I've seen that licence somewhere too - but the STM32F10x StdPeriph library has nothing of the sort. This topic on the chibios/rt forum comes up if you dig around a bit.

(although, since it's not one of the much-discussed OSSW licenses, it might take thousands of dollars worth of lawyers before I could have a high confidence that some of the things I've done (like turning the .h files into assembler format includes) are actually permissible

Exactly - the EFM32 emlib uses the Zlib license which is pretty easy to understand.

I'm aware that none of this probably really matters in real life (especially for no-name hobbyists like me), but it baffles me that someone would homebrew an open source licence instead of just slapping a standard permissive one on something like a peripherals library. Seems like something you'd provide to your customers as a convenience and not a very major piece of IP.

[westfw]

the STM32F10x StdPeriph library has nothing of the sort.

Sure it does; that's what I was looking at.  I was careful to look at the .c files as well as the .h files, too.
The discussions you list are a bit old (2011), while the source code I'm looking at all has 2012 or later copyrights.
It looks like the STP download is pretty out of date.  OTOH, I guess I'm looking at a "STM32_Nucleo_FW_V1.2.1" download rather than a "Standard Peripheral Library" download, and the "New thing" is "CUBE", which doesn't seem to have an F1xx version.  Curious.

Vendor software licenses usually aren't exactly "open source"; they don't want you adapting their code to some other vendor's chip, for example, and it seems to be relatively frequent that they don't want third parties distributing source to the vendor libraries.  (Microchip gets this complaint.  If you write OSSW code for some clever USB or ethernet gadget that uses their USB or TCP stack, you can't include the stack in your distributed project; user have to download the stack from microchip separately.) (although: not that different than LGPL.)  In general, I'd rather have vendors write their own licenses than slap on the WRONG famous OSSW license!  (SO many Arduino *libraries* with GPL3...)

[paulie]

Post number 5 slot has been updated with a command line version of the STM8 tools:

https://www.eevblog.com/forum/microcontrollers/one-dollar-one-minute-arm-development/msg506113/#msg506113

150k complete! Even considering the first post GCC package was stripped down to 1% of standard distribution a DOZEN of these could be attached in the same space and still rooms left over for photos. Talk about minimum. One thing puzzles me though: Why must reset vector in the source files be 0x82008004 instead of the expected 0x00008004? WTF?

[mrflibble]

One thing puzzles me though: Why must reset vector in the source files be 0x82008004 instead of the expected 0x00008004? WTF?

Flash versus sram memory location?

[paulie]

Flash versus sram memory location?

Good guess. That did play a part in wide performance difference for BOOT0/1 jumper settings on the 103c chip. However not quite the situation with 003 which has no boot. With a little help from single stepping that mystery is solved. No mention of this in any of the docs AFAIK. Here's a hint: begins with the letter 'j'. Let's allow a little time to see if any of the experts can come up with the explanation. LOL.

[mrflibble]

Flash versus sram memory location?

Good guess. That did play a part in wide performance difference for BOOT0/1 jumper settings on the 103c chip. However not quite the situation with 003 which has no boot. With a little help from single stepping that mystery is solved. No mention of this in any of the docs AFAIK. Here's a hint: begins with the letter 'j'. Let's allow a little time to see if any of the experts can come up with the explanation. LOL.

That's easy. That's the January JTagging Janitor Jamboree.

And if that isn't it I guess I'll just have to wait until the guess timer expires, and the mystery shall be unveiled.

[westfw]

Well, I've found my first case where the C compiler(s) produce better code than I wrote in assembler.
??You might remember this simple loop from the clock initialization:

Code: [Select]

clklp: ldr r1, [r0, #RCC_CR]
tst r1, #RCC_CR_HSERDY /* wait for clock ready */
beq.n clklp
That seems obvious enough.  Read the register, check the relevant bit, loop if it's not set.
But the C compiler produces code like:

Code: [Select]

  lp:  ldr     r2, [r1, #0]
       lsls    r2, r2, #14
       bpl.n   lp
And guess what?  the "tst" instruction with the immediate bit value turns out to be a 32bit instruction, while the "lsls" instruction to shift the relevant bit to the sign position (it took me a bit to figure out that that's what it's doing!) is only 16bits.  So the C code is better.
Of course, now that I know this "trick", I can theoretically do the same thing.  But it's pretty inconvenient to convert that bitmask symbol value that I have into the required shift value... :-(

[paulie]

the C code is better.

Hey... I don't see any C code there at all.

It's not surprising that a team of asm programmers, spending years hacking and tuning and who have built the foundation upon which all "centipedes" rest, can do better than me. Somewhere around 90% of my library of subroutine collection was extracted from Objdump dumps. In fact your second example resembles my typical programming than the universally accepted sprinkling of includes, labels and symbols. For me they are better placed as comments. Makes debugging easier. Of course my projects are very simple by comparison so I get away with it.

One thing I don't like is when the output of a disassembler is incompatible with the assembler. For me it's a great reverse engineering and debugging tool to be able to feed it back in. As one who is great and wise once said... grrr.

[paulie]

That's easy. That's the January JTagging Janitor Jamboree.

Well at least JTAG was in the ballpark. Looks like nobody here has a clue so the key word was "JPF" (jump far, opcode 0x82008004).

Turns out STM8 do not really have a reset vector with address like all the other chips discussed in these threads. Like AVR and others it actually starts execution of code at that location and the "vector" is a jmp instruction not an address. To demonstrate this the demo in reply #5 slot has been replaced with one that has no entry yet runs fine. It's a 2 instruction program now that toggles an LED! Let's see the C centipedes top that. This has always been one of the advantages AVR had over other chips IMO. Particularly on the TINY parts where every byte is sometimes at a premium.

Mystery solved.

ps. Naturally if you use hardware interrupts the table must be fully populated. At least up to the entry for the peripheral triggering it.

[westfw]

I'll admit to reviewing the STM8 documentation recently.
32bit instruction word, eh?  No wonder they seem to have so much flash compared to most other cheap 8bit micros!

[Kjelt]

I'll admit to reviewing the STM8 documentation recently.
32bit instruction word, eh?  No wonder they seem to have so much flash compared to most other cheap 8bit micros!

Actually the STM8 code is about 30% smaller than a M0 or Atmel AT90. AFAIK the instruction part of the opcodes are 8 or perhaps in some cases 16 bit, the total size of the instruction can be larger due to the addresses or data to operate on. It is a bit hard to jump in 16M address space without a 32 bits adress 

[paulie]

Yes, many 8 bit instructions. However AFAIK the few 32 bit instructions have 8 bit operator and 24 bit operand like JPF so can't access 32bit/4Gb.

[paulie]

In the process of playing around with SDCC STM8 compiler a potential inconvenience crops up. It turns out if you make the SWIM pin (PD1) an output and don't have reset hooked up the chip can't be flashed with STVP again. If you do have reset connected the user program does not run automatically after flashing. One solution is to connect a switch to reset like with the STM32 parts but I prefer to simply not use the SWIM pin for I/O and leave reset open. This applies to both assembler and C programs.

[paulie]

A fellow at the local amateur radio club had some wiring problems with his LPC project this weekend so a photo of my setup has been attached to reply slot #3: https://www.eevblog.com/forum/microcontrollers/one-dollar-one-minute-arm-development/msg506039/#msg506039. Thanks to cheap chips from Mouser and Flashmagic programming utility working with these is a cinch.

[Brutte]

I'll admit to reviewing the STM8 documentation recently.
32bit instruction word, eh?  No wonder they seem to have so much flash compared to most other cheap 8bit micros!

These have a variable width op-codes. Spanning from one byte up to five bytes. 32-bit is the width of the flash memory.

[Kjelt]

Yes, many 8 bit instructions. However AFAIK the few 32 bit instructions have 8 bit operator and 24 bit operand like JPF so can't access 16M.

One exception 

[westfw]

These have a variable width op-codes. Spanning from one byte up to five bytes. 32-bit is the width of the flash memory.

Ah.  I see I mis-read the datasheet; it had so little information on the CPU or instruction set that I misinterpreted the "32 bit wide instruction bus" as meaning that the  CPU had a 32-bit fixed-width instruction...

"Never mind."

[paulie]

One exception

Plus of course the infamous JPF. The 16Mb in my comment was incorrect and has been edited. I meant that with only 24 bits it's not possible to access 4Gb which would need 32 bits which is not possible.

It is a bit hard to jump in 16M address space without a 32 bits adress

While it's true some instructions can technically be 5 bytes long, not really because one of those is a "pre-opcode" and the  other a regular operator. So with 2 operators that leaves only 3 operand bytes max so 32 bit address is not possible (or needed considering the memory map).

[westfw]

More work on the Hello World assembler code.
Added Uart input and decimal output.  Demonstrates implementation of "mod" using UDIV/MLS sequence (gleaned by examining C compiler output) and recursion (!)
(Note: no longer works on M0/M0+, because they don't have divide instructions!)

[paulie]

Just tried it and working like a charm. No "corrections" this time. However I'll probably reformat so it can be read with a text editor and rename to avoid confusion with previous versions that had the same filename. I know it's not the case here but in the professional world two different files with same name is a mortal sin. Thanks again for another great educational booster.

Not to change the subject (aka to change the subject) I have an SDCC package that's actually smaller than any of the assembly ones and even easier to use. I managed to tame the STVP command line version for use with this and the STM8 assembler so everything, including flashing, is a single keystroke. This will go up on page one too when I get a chance.

[westfw]

reformat so it can be read with a text editor

Is it not plain text already?  I looks so, here...

two different files with same name is a mortal sin.

Agreed.  I don't consider this a different file, though; it has "small" enhancements over the previous post.
(Next: interrupts.  That will be a new filename.)

[paulie]

I would suggest you continue to attach using the same format as before because there will be dozens if not hundreds of MAC/Linux users who depend on that. It literally only takes 5 seconds or so to load with MS Word and "SAVE_AS/TEXT" but I'm not sure how easy to go the other way. By text I mean compatible with CRLF editors like Notepad.

As far as naming it only becomes a serious issue when several files are loaded in the same post like on page one so if you don't mind me copying and renaming there it don't matter what they are originally called.

The important thing is that with every new version me and at least a few other guys I know learn new instructions and assembler tricks. Not just this chip either. Your latest effort helped me develop a more efficient version of the STM8 bootloader I've been working on. The existing C implementations didn't resemble what was really needed feature wise and had no chance of compiling as is under SDCC which is the only C compiler I have room for ATM. At least not without lots of work. Some addresses in that STM8L.H file are flat wrong for the 003 chip. A few changes were made to accommodate the demo but it was just easier for me to implement in asm. Thanks again for taking time to help out the bare-metal crowd.

[westfw]

Ahh.  CRLF vs \n...

[miguelvp]

people should use notepad++ in windows as their default text editor