Author Topic: One Dollar One Minute ARM Development  (Read 100227 times)

0 Members and 1 Guest are viewing this topic.

Offline westfw

  • Super Contributor
  • ***
  • Posts: 3073
  • Country: us
Re: One Dollar One Minute ARM Development
« Reply #100 on: September 09, 2014, 03:42:47 pm »
Quote
would love to see someones IP stack written in assembly

http://pdp-10.trailing-edge.com/SRI_NIC_PERM_SRC_1_19910112/01/6-1-monitor/tcptcp.mac.html

(and several related files.)

(If you do read through this code, keep in mind that it is/was one of the very first TCP implementations!)
« Last Edit: September 09, 2014, 03:53:46 pm by westfw »
 

Offline Kjelt

  • Super Contributor
  • ***
  • Posts: 5738
  • Country: nl
Re: One Dollar One Minute ARM Development
« Reply #101 on: September 09, 2014, 05:55:52 pm »
http://pdp-10.trailing-edge.com/SRI_NIC_PERM_SRC_1_19910112/01/6-1-monitor/tcptcp.mac.html (and several related files.)
(If you do read through this code, keep in mind that it is/was one of the very first TCP implementations!)
Thanks, and you have proven my point, this kind of code is totally unmaintainable or expandable (someone wants to add the TLS1.2 spec to it?)  ;)
But indeed in the 80s a lot of code was written in assembly, most of the consumerelectronics were written in assembly. My first steps into microcontrollers (8048) were in assembly, but that does not justify to keep on using it in the 21st century (unless it is for hobby like puzzles).
 

Offline paulie

  • Frequent Contributor
  • **
  • Banned!
  • Posts: 849
  • Country: us
Re: One Dollar One Minute ARM Development
« Reply #102 on: September 09, 2014, 05:59:17 pm »
why waste time on creating a half-functioning assembly code?

I'm surprised so many keep missing the point but I don't mind repeating.

Because the intent was to provide a set of ARM tools that are basic enough to attach to a forum not just link and set up so even a beginner can download and test in less than a minute. That's what I claimed and that's what I did. This has never been done before, here or anywhere else.

If you want to see how others have done this, check out some of the stm8 software usb examples on the web.

Copying off the net is your game.  For my current purpose trailblazing has proven more productive. At least for this project. BTW I do have an STM8 Discovery and ran all the demos. However I lost interest quickly when it became apparent there were few advantages over other 8 bit devices like PIC or AVR and many drawbacks. Cost, performance, features. So I'll leave that scientific curiosity up to you too.

Blinking an led on this board (or pretty much any other board, arm or not) is fairly easy, especially for a C expert like yourself. Why compete where your skills are none by writing in assembly?

I'm certainly not an expert in C like you claim to be. As far as asm it don't look like you've ever seen let alone worked with a line of code. When you accomplish anything even close to what I've done come back and we'll talk.

Apparently you are an expert  on hardware tools too. Any more info on this?

There is also an approach that does not require the flash loader demonstrator - hyperterminal is all you need.

Any links or other details? No?

If you cannot write a blinky in C, I posted a short piece in the ghetto thread that blinks an led on any STM32F10x chips. It would be a ride in the park for a seasoned C programmer like yourself to get it going on your hardware.

Yes, I see you have just caught on to what is not only most common arm chip but really the best deal in that category too. But I requested a hex file not half baked C demos off the web. Anyway it's no longer needed. A hex (actually elf, even better) was provided by a generous offline contributor. It provided the missing link I needed to solve that mystery.

Anyway I don't think you ever had the courtesy to post a working hex file. Maybe with all the GUI layers you don't know how. Like with the arduino gang. ATM there is little inclination for me to get sucked into that toolchain whirlpool you call a development environment.

From where I sit, you haven't demonstrated the need, skills or resources to code in assembly.

Well it looks like I am possibly the first and only person to post a working version of ARM assembly blink program in this forum. OK, the program wasn't written by me but I got it working. Possibly westfw was able fix the include bugs and hasn't posted them yet. The latest version gets T32_OFFFSET_IMM something error with the basic CLI commands. It might be we are out of sync with command options again IDK. So attached is his previous asmh with a minor fix to suppress errors and working hex from his unmodified original source:
« Last Edit: September 09, 2014, 06:37:34 pm by paulie »
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8229
  • Country: 00
Re: One Dollar One Minute ARM Development
« Reply #103 on: September 09, 2014, 07:33:01 pm »
Quote
For my current purpose trailblazing has proven more productive.

Quote
Well it looks like I am possibly the first and only person to post a working version of ARM assembly blink program in this forum. OK, the program wasn't written by me but I got it working.

Wow!

you redefine sha@#$. OK, you redefined "traiblazing", ;0

It takes more than "audacity" to claim what you did.

As to your being the "only" one. Have you thought about why you are the "only" one? Running down the autobahn butt-naked will make you the only one too but most people would understand why the "only" one there isn't so desirable.

Do you?
================================
https://dannyelectronics.wordpress.com/
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8229
  • Country: 00
Re: One Dollar One Minute ARM Development
« Reply #104 on: September 09, 2014, 07:35:04 pm »
Quote
this kind of code is totally unmaintainable or expandable

Bingo!

You hit it right on the head.

As hardware costs continue to decline and software costs continue to rise, the trade-off continues to shift towards more stylized software.
================================
https://dannyelectronics.wordpress.com/
 

Offline paulie

  • Frequent Contributor
  • **
  • Banned!
  • Posts: 849
  • Country: us
Re: One Dollar One Minute ARM Development
« Reply #105 on: September 09, 2014, 07:44:55 pm »
you redefine sha@#$. OK, you redefined "traiblazing", ;0

I'm sure you can provide evidence to the contrary. SOMEBODY must have attached a functional set of ARM tools before. SOMEBODY must have provided a way for noobs to check them out without spending days or weeks or months. SOMEBODY must have posted a working binary assembled for ARM blinky before. No?

It takes more than "audacity" to claim what you did.

It takes ARROGANCE!

"I am great, yet I am humble."
-Shark
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8229
  • Country: 00
Re: One Dollar One Minute ARM Development
« Reply #106 on: September 09, 2014, 09:31:00 pm »
Quote
SOMEBODY must have posted a working binary assembled for ARM blinky before. No?

That's good. That means humanity has honor, knows right from wrong, smart from not-so-smart.

That means there is hope for all of humanity, minus the obvious one of course.

:)
================================
https://dannyelectronics.wordpress.com/
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8229
  • Country: 00
Re: One Dollar One Minute ARM Development
« Reply #107 on: September 09, 2014, 09:33:16 pm »
Quote
New .asmh file added in

why?

Just use the header files from CMSIS / libraries.
================================
https://dannyelectronics.wordpress.com/
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 3073
  • Country: us
Re: One Dollar One Minute ARM Development
« Reply #108 on: September 09, 2014, 10:21:42 pm »
Quote
Just use the header files from CMSIS / libraries.
They don't support assembler. (for two reasons.  The first and most significant is that (in theory) while you could use the C preprocessor even when programming in asm, the CMSIS headers are full of constructs like
Code: [Select]
#define CRC                 ((CRC_TypeDef *) CRC_BASE) which the assembler is not going to recognize after substitution (nor do I see a way to add additional CPP or asm macros to simplify it enough to make a difference)
The second reason is that the preprocessor isn't included in the "reduced tool set" that we're trying to use (for better or worse.)

Part of the reason for the experiment are the frequent complaints I see of the form "I hear that Atmel Studio for ARM, scatters 3GB+ of crap all over my disk."  ("Yeah, TI's CCS does that too."  "MPLABX isn't much better."  etc.)  So here we a "usable" toolset in less than 6MB, that goes exactly where you put it.  That's 500x less space...
Sure, I'd prefer "Borland C for ARM", but efforts in that direction (pcc ?)  don't seem to be getting anywhere.

Arguably, for minimum trouble you should spend the $100 to get something like Imagecraft's "Non commercial" ARM compiler/IDE.  (~500MB)  The real truth is that there isn't anyone doing this "for real" to whom $100 and a hour or two of download/install time is a real barrier.  It *is* a sort of academic exercise...
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8229
  • Country: 00
Re: One Dollar One Minute ARM Development
« Reply #109 on: September 09, 2014, 10:28:16 pm »
Quote
which the assembler is not going to recognize after substitution

Use the base address.

Code: [Select]
  ldr R0, =RCC_BASE + RCC_AHBNER_OFFSET @load ahbner address into R0

would work.

You have to define RCC_AHBNER_OFFSET (which the header file specifies), obviously.
================================
https://dannyelectronics.wordpress.com/
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 3073
  • Country: us
Re: One Dollar One Minute ARM Development
« Reply #110 on: September 09, 2014, 11:35:06 pm »
Quote
  ldr R0, =RCC_BASE
Assuming that it would get that far, this would expand to
Code: [Select]
ldr r0,=((((uint32_t)0x40000000)+0x20000)+0x1000)which generates errors
Code: [Select]
foo1.S: Assembler messages:
foo1.S:6: Error: missing ')'
foo1.S:6: Error: missing ')'
foo1.S:6: Error: missing ')'
foo1.S:6: Error: garbage following instruction -- `ldr r0,=((((uint32_t)0x40000000)+0x20000)+0x1000)'
You get similar errors for "=(((()0x40000000)+0x20000)+0x1000)"...

But of course it doesn't get anywhere near that far, since the .h file also has plenty of "typedef" statements that the assembler doesn't understand at all either:
Code: [Select]
stm32f10x.h:1266: Error: bad instruction `typedef struct'
stm32f10x.h:1267: Error: junk at end of line, first unrecognized character is `{'
stm32f10x.h:1268: Error: bad instruction `__io uint32_t CR'
stm32f10x.h:1269: Error: bad instruction `__io uint32_t CFR'
stm32f10x.h:1270: Error: bad instruction `__io uint32_t SR'
stm32f10x.h:1271: Error: junk at end of line, first unrecognized character is `}'
If I understand things correctly, this is the format/methodology that CMSIS requests/requires of the include files.
And the explicit casts on all constants are recommended/required by other standards, right?  (MISRA?)
So the CMSIS header files are pretty much defined to be an assembler-unfriendly format...

I think the only architectures I've seen .f files set up to be used by both assembler and C is the Atmel AVR.
(Microchip 8bit PIC has separate .h and .inc files, IIRC.)

Quote
You have to define RCC_AHBNER_OFFSET (which the header file specifies), obviously.
I did find some sites that have instructions for generating gnu assembler xxx_OFFSET macros from C structure definitions.  ( http://docs.blackfin.uclinux.org/doku.php?id=toolchain:gas:structs )  Just create a special C file that references all the structure offsets that you're interested in, run it through the compiler till you get generated asm, process that with awk, and bob's your uncle.  I think I prefer my technique (though the blackfin technique would have handled those structs containing arrays of other structs that mine didn't.)
 

Offline paulie

  • Frequent Contributor
  • **
  • Banned!
  • Posts: 849
  • Country: us
Re: One Dollar One Minute ARM Development
« Reply #111 on: September 10, 2014, 08:27:07 am »
My methodology involves pulling out datasheets and snipping register tables. Then, using macro/replace ability of my editor (emacs variant), convert entries to .equ or #define depending on language. Rarely do I bother with bit definitions. Those and other less common details may end up as immediates with comments or equ/define in the source file if used more than once or twice. Rarely do i bother to download the official include packages.

This has worked out well in the 8 bit world. Lately not so much for ARM due to somewhat nasty docs. Most of my efforts are not that complex. Certainly not on a par with things like mw or ardupilot, but a few did make it to market. The "sometimes less is more" philosophy has served me well. I spend more time actually writing programs and less struggling with tools.
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8229
  • Country: 00
Re: One Dollar One Minute ARM Development
« Reply #112 on: September 10, 2014, 10:59:51 am »
Quote
You get similar errors for "=(((()0x40000000)+0x20000)+0x1000)"...

You are right.

I ended up with the following arrangements:

Code: [Select]
@set gpio2
ldr R0, =GPIOC_BASE @read gpioc base into r0
ldr R1, [R0, #GPIO_ODR_OFF] @read gpioc odr
ldr R2, =GPIO_ODR_2 @read odr2
orrs R2, R2, R1 @r1|r2->r2
str R2, [R0, #GPIO_ODR_OFF] @send it back to odr

GPIOC_BASE is separately defined as:

Code: [Select]
.equ PERIPH_BASE, 0x40000000 @peripheral's base address
.equ APBPERIPH_BASE, PERIPH_BASE
.equ AHBPERIPH_BASE, (PERIPH_BASE + 0x00020000)

.equ GPIOC_BASE, (AHB2PERIPH_BASE + 0x00000800)

Retained the names from the .h file.


Quote
But of course it doesn't get anywhere near that far, since the .h file also has plenty of "typedef" statements that the assembler doesn't understand at all

They compiled flawlessly for me:

Code: [Select]
#include <stm32f0xx.h>
#include "stm32f0xx_rcc.h"
#include "stm32f0xx_gpio.h"

.syntax unified

@system defines
@RCC offsets
.equ PERIPH_BASE, 0x40000000 @peripheral's base address
.equ APBPERIPH_BASE, PERIPH_BASE
.equ AHBPERIPH_BASE, (PERIPH_BASE + 0x00020000)
.equ AHB2PERIPH_BASE, (PERIPH_BASE + 0x08000000)
.equ RCC_BASE, (AHBPERIPH_BASE + 0x00001000) @rcc's base address
...

Except that they do nothing yet, until I figure out how to use the defines.
================================
https://dannyelectronics.wordpress.com/
 

Offline paulie

  • Frequent Contributor
  • **
  • Banned!
  • Posts: 849
  • Country: us
Re: One Dollar One Minute ARM Development
« Reply #113 on: September 10, 2014, 07:31:28 pm »
Except that they do nothing yet, until I figure out how to use the defines.

If that's the case, why waste time on creating a half-functioning assembly code? Give people .axf and you are done.

From where I sit, you haven't demonstrated the need, skills or resources to code in assembly
 

Offline SirNick

  • Frequent Contributor
  • **
  • Posts: 589
Re: One Dollar One Minute ARM Development
« Reply #114 on: September 10, 2014, 09:52:51 pm »
 ;D Kinda had that one coming.

Just popping in to say, this is a neat exercise.  Not practical, just entertaining and educational.  Carry on.
 

Offline paulie

  • Frequent Contributor
  • **
  • Banned!
  • Posts: 849
  • Country: us
Re: One Dollar One Minute ARM Development
« Reply #115 on: September 10, 2014, 10:29:59 pm »
LOL I hope Danny gets it.

Thanks. "Not practical, just entertaining and educational" was the plan from day one. Maybe people are beginning to get that now. I know I've come a long way last few days thanks to guys like westfw, nctnico, and, I hate to admit, Danny too (don't tell him I said that).
 

Offline SirNick

  • Frequent Contributor
  • **
  • Posts: 589
Re: One Dollar One Minute ARM Development
« Reply #116 on: September 10, 2014, 11:21:28 pm »
Your secret's safe with me. ;)

BTW... I, for one, do and did get it.  I've often been surprised how strongly people oppose doing things the hard way (or whatever) at least once, to better understand how it works.  You'd think, in groups of engineers and hobbyists, taking the scenic route wouldn't be in the least bit controversial.  But often it is.  *shrug*  I have never understood that.
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 3073
  • Country: us
Re: One Dollar One Minute ARM Development
« Reply #117 on: September 10, 2014, 11:28:24 pm »
Quote
I ended up with
why?  I mean, OF COURSE you can create your own .equivs for whatever constants you want, but that's tedious and error-prone compared to have an algorithmic translations of the .h file (which is what I've done to create the .asmh)
I don't think we're specifically restricting ourselves to the "most primitive environment possible" (though it may feel that way.)  We're trying to provide the best possible environment within a constraint of size/time.  Adding a 60k (compressed) file of assembler-style definitions is within the constraint.

Quote
compiled flawlessly for me
I don't see how that's possible.  You're not even defining the specific chip, which should bump you immediately into:
Code: [Select]
#if !defined (STM32F030) && !defined (STM32F031) && !defined (STM32F051) && !defined (STM32F072) && !defined (STM32F042)
 #error "Please select first the target STM32F0xx device used in your application (in stm32f0xx.h file)"
#endif

(Hmm.  Are using using "arm-none-eabi-as" as the assembler?  That doesn't invoke theC preprocessor, and includes a quirk of commenting such that lines beginning with # are essentially ignored, so #include doesn't actually include anything...  To "assemble" a file that uses C macros, you usually use the xxx-gcc command (the gcc .exe being essentially a front end that invokes xxx-cpp, cc1, xxx-as, and xxx-ld and perhaps others depending on command line switches and file extensions.)
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8229
  • Country: 00
Re: One Dollar One Minute ARM Development
« Reply #118 on: September 11, 2014, 12:30:32 am »
We followed a different process. I followed a typical C project process to the end. Then delete main.c, and instead include main.S.

I will also choose CMSIS as part of the set-up.

I eventually wrote a small piece of code (h2inc) that generated stm32f0xx.inc from stm32f0xx.h to retain the base addresses. That header file is then included in the main.S to provide base addresses for the code.

Using CMSIS has the advantage of having access to SystemInit() and SystemCoreClockUpdate(), as having your stack / heap set up by the start-up file automatically.

My code looks like this:

Code: [Select]
.include "stm32f0xx.inc"
.syntax unified
.thumb

@system defines
@RCC offsets
.equ RCC_AHBENR_OFF, 0x14 @ahbner offset

@gpio offsets
.equ GPIO_MODER_OFF, 0x00 @gpio moder offset
.equ GPIO_OTYPER_OFF, 0x04 @output type
.equ GPIO_ODR_OFF, 0x14 @output data register
.equ GPIO_BSRR_OFF, 0x18 @output bit set / reset register
.equ GPIO_BRR_OFF, 0x28 @output bit reset register

@global defines
.equ LED_PORT, GPIOC_BASE @led on gpioc
.equ LED_A, (1<<1) @led anode on pin1
.equ LED_C, (1<<2) @led cathode on pin2

@global variables


.global main @so it gets called from CMSIS
.type main, %function
@.text @declare it in the code section

main:
@user main starts here

init:
@initialize the chip
@enable clock to gpioc
ldr R0, =RCC_BASE @read rcc base address into r0
ldr R1, [R0, #RCC_AHBENR_OFF] @read ahbner register into R1
ldr R2, =RCC_AHBENR_GPIOCEN
orrs R2, R2, R1 @set GPIOCEN bit, R2 | R1 -> R2
str R2, [R0, #RCC_AHBENR_OFF] @update ahbner register

The bulk of the code compiled is actually in the .inc file - almost 400k and 5000+ lines - many of it is actually masked off.

Unfortunately, there is no way to calculate the offsets so you have to manually set them up.
================================
https://dannyelectronics.wordpress.com/
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 3073
  • Country: us
Re: One Dollar One Minute ARM Development
« Reply #119 on: September 11, 2014, 02:44:04 am »
So are we now at "why use a .asmh file generated from ST .h files using your procedure when you could have used a .inc file generated from ST .h files using MY procedure"?  I'll accept that as a "victory."  The resulting files seem be be about the same size, and everything (also about the same size as st's original .h files.  I wish they didn't spend so much time/space defining PERIPHNAME_REGNAME_0 (through PERIPHNAME_REGNAME_31) and similar for each bit of every register where the bits don't have a particularly nameable function...
 

Offline paulie

  • Frequent Contributor
  • **
  • Banned!
  • Posts: 849
  • Country: us
Re: One Dollar One Minute ARM Development
« Reply #120 on: September 11, 2014, 03:22:21 am »
It would be interesting to see if using a file generated for the device in this thread actually compiles unlike the asmh files which do not.

ps. And if the program using it actually runs.
« Last Edit: September 11, 2014, 03:43:59 am by paulie »
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 3073
  • Country: us
Re: One Dollar One Minute ARM Development
« Reply #121 on: September 11, 2014, 04:47:52 am »
I should start including by example program in with the .asmh file.  I did mention that the _O symbols were replaced...
It turns out that error messages like
Code: [Select]
blink.S:61: Error: cannot represent T32_OFFSET_IMM relocation in this object file formatis "I am a lousy assembler"-speak for "the symbolic name you used in this instruction is undefined." (actually, it seems to have automatically made it "external", and then discovered that the linker doesn't support the required sort of math on the value.  Or something like that.)

Here's the most recent .asmh file.  Now includes NVIC and SysTick peripherals (from ST's core_cm3.h), and deleted some of the pointless bit value definitions.

 

Offline paulie

  • Frequent Contributor
  • **
  • Banned!
  • Posts: 849
  • Country: us
Re: One Dollar One Minute ARM Development
« Reply #122 on: September 11, 2014, 06:54:03 am »
It compiles OK but unfortunately don't blink. I haven't deciphered your code yet. Did you change the bit or something? On same hardware the original one blinks when used with the older asmh that I hacked.
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 3073
  • Country: us
Re: One Dollar One Minute ARM Development
« Reply #123 on: September 11, 2014, 07:46:24 am »
I didn't think I had changed anything.  :-(

My board is supposed to arrive tomorrow.  What did you say you were using for upload?  (JTAG, Serial, USB?)

Hmm.  It looks like when I added the offsets to the .asmh file, I forgot that my older version had created absolute values for some things with the same name.   So the code currently has
Code: [Select]
ldr r0, =RCC_APB2ENRand that (now) needs to be
Code: [Select]
ldr r0, =RCC_BASE+RCC_APB2ENR
I see a disadvantage to having dropped the _O syntax for offsets :-(
(although the peripheral register names are now ALL offsets, and always need to add some _BASE value via indexing or addition.)
 

Offline paulie

  • Frequent Contributor
  • **
  • Banned!
  • Posts: 849
  • Country: us
Re: One Dollar One Minute ARM Development
« Reply #124 on: September 11, 2014, 08:33:37 am »
Just like the version of yours that works it was assembled with first page utilities and downloaded using that ST serial flash program attached there. I peeked and see the bit has not changed so maybe something to do with the new include file. I really can't make heads or tails of actual addresses anymore what with all the offsets, bases, shifts etc.. Same tools as with my own super simple LED program from last week with just plain ol' hex numbers. No includes or even defines. Maybe a comment or two if you're lucky.

I'm sure things will move quickly when your board shows up. No hardware is a huge handicap IMO.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf