Trimming Some Bloat While Shaving a Yak.

Go To Last Post
25 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I know I will take hell for my odd coding methods, but humor me if you will!

Ok, so I am working with XMega Virtual ports and absolutely HATE! HATE! HATE! anything to do with ASF or all that ugly, bloated, redundant, swollen, silly, driver and definitions stuff. So after many hours of slicing of huge blobs of useless text, I managed to cut out the relevant parts of VIRT mapping.

I just wanted to verify with someone that I am understanding this in its pure and simple form. Ok, so here is a bunch of nonsensical foo I stripped from that crazy port driver C code...

.equ PORTCFG_VP0MAP_PORTA_gc = (0x00<<0) ; Mapped To PORTA
.equ PORTCFG_VP0MAP_PORTB_gc = (0x01<<0) ; Mapped To PORTB
.equ PORTCFG_VP0MAP_PORTC_gc = (0x02<<0) ; Mapped To PORTC
.equ PORTCFG_VP0MAP_PORTD_gc = (0x03<<0) ; Mapped To PORTD
.equ PORTCFG_VP0MAP_PORTE_gc = (0x04<<0) ; Mapped To PORTE
.equ PORTCFG_VP0MAP_PORTF_gc = (0x05<<0) ; Mapped To PORTF
.equ PORTCFG_VP0MAP_PORTG_gc = (0x06<<0) ; Mapped To PORTG
.equ PORTCFG_VP0MAP_PORTH_gc = (0x07<<0) ; Mapped To PORTH
.equ PORTCFG_VP0MAP_PORTJ_gc = (0x08<<0) ; Mapped To PORTJ
.equ PORTCFG_VP0MAP_PORTK_gc = (0x09<<0) ; Mapped To PORTK
.equ PORTCFG_VP0MAP_PORTL_gc = (0x0A<<0) ; Mapped To PORTL
.equ PORTCFG_VP0MAP_PORTM_gc = (0x0B<<0) ; Mapped To PORTM
.equ PORTCFG_VP0MAP_PORTN_gc = (0x0C<<0) ; Mapped To PORTN
.equ PORTCFG_VP0MAP_PORTP_gc = (0x0D<<0) ; Mapped To PORTP
.equ PORTCFG_VP0MAP_PORTQ_gc = (0x0E<<0) ; Mapped To PORTQ
.equ PORTCFG_VP0MAP_PORTR_gc = (0x0F<<0) ; Mapped To PORTR

; Virtual Port 1 Mapping
.equ PORTCFG_VP1MAP_PORTA_gc = (0x00<<4) ; Mapped To PORTA
.equ PORTCFG_VP1MAP_PORTB_gc = (0x01<<4) ; Mapped To PORTB
.equ PORTCFG_VP1MAP_PORTC_gc = (0x02<<4) ; Mapped To PORTC
.equ PORTCFG_VP1MAP_PORTD_gc = (0x03<<4) ; Mapped To PORTD
.equ PORTCFG_VP1MAP_PORTE_gc = (0x04<<4) ; Mapped To PORTE
.equ PORTCFG_VP1MAP_PORTF_gc = (0x05<<4) ; Mapped To PORTF
.equ PORTCFG_VP1MAP_PORTG_gc = (0x06<<4) ; Mapped To PORTG
.equ PORTCFG_VP1MAP_PORTH_gc = (0x07<<4) ; Mapped To PORTH
.equ PORTCFG_VP1MAP_PORTJ_gc = (0x08<<4) ; Mapped To PORTJ
.equ PORTCFG_VP1MAP_PORTK_gc = (0x09<<4) ; Mapped To PORTK
.equ PORTCFG_VP1MAP_PORTL_gc = (0x0A<<4) ; Mapped To PORTL
.equ PORTCFG_VP1MAP_PORTM_gc = (0x0B<<4) ; Mapped To PORTM
.equ PORTCFG_VP1MAP_PORTN_gc = (0x0C<<4) ; Mapped To PORTN
.equ PORTCFG_VP1MAP_PORTP_gc = (0x0D<<4) ; Mapped To PORTP
.equ PORTCFG_VP1MAP_PORTQ_gc = (0x0E<<4) ; Mapped To PORTQ
.equ PORTCFG_VP1MAP_PORTR_gc = (0x0F<<4) ; Mapped To PORTR

; Virtual Port 2 Mapping
.equ PORTCFG_VP2MAP_PORTA_gc = (0x00<<0) ; Mapped To PORTA
.equ PORTCFG_VP2MAP_PORTB_gc = (0x01<<0) ; Mapped To PORTB
.equ PORTCFG_VP2MAP_PORTC_gc = (0x02<<0) ; Mapped To PORTC
.equ PORTCFG_VP2MAP_PORTD_gc = (0x03<<0) ; Mapped To PORTD
.equ PORTCFG_VP2MAP_PORTE_gc = (0x04<<0) ; Mapped To PORTE
.equ PORTCFG_VP2MAP_PORTF_gc = (0x05<<0) ; Mapped To PORTF
.equ PORTCFG_VP2MAP_PORTG_gc = (0x06<<0) ; Mapped To PORTG
.equ PORTCFG_VP2MAP_PORTH_gc = (0x07<<0) ; Mapped To PORTH
.equ PORTCFG_VP2MAP_PORTJ_gc = (0x08<<0) ; Mapped To PORTJ
.equ PORTCFG_VP2MAP_PORTK_gc = (0x09<<0) ; Mapped To PORTK
.equ PORTCFG_VP2MAP_PORTL_gc = (0x0A<<0) ; Mapped To PORTL
.equ PORTCFG_VP2MAP_PORTM_gc = (0x0B<<0) ; Mapped To PORTM
.equ PORTCFG_VP2MAP_PORTN_gc = (0x0C<<0) ; Mapped To PORTN
.equ PORTCFG_VP2MAP_PORTP_gc = (0x0D<<0) ; Mapped To PORTP
.equ PORTCFG_VP2MAP_PORTQ_gc = (0x0E<<0) ; Mapped To PORTQ
.equ PORTCFG_VP2MAP_PORTR_gc = (0x0F<<0) ; Mapped To PORTR

; Virtual Port 3 Mapping
.equ PORTCFG_VP3MAP_PORTA_gc = (0x00<<4) ; Mapped To PORTA
.equ PORTCFG_VP3MAP_PORTB_gc = (0x01<<4) ; Mapped To PORTB
.equ PORTCFG_VP3MAP_PORTC_gc = (0x02<<4) ; Mapped To PORTC
.equ PORTCFG_VP3MAP_PORTD_gc = (0x03<<4) ; Mapped To PORTD
.equ PORTCFG_VP3MAP_PORTE_gc = (0x04<<4) ; Mapped To PORTE
.equ PORTCFG_VP3MAP_PORTF_gc = (0x05<<4) ; Mapped To PORTF
.equ PORTCFG_VP3MAP_PORTG_gc = (0x06<<4) ; Mapped To PORTG
.equ PORTCFG_VP3MAP_PORTH_gc = (0x07<<4) ; Mapped To PORTH
.equ PORTCFG_VP3MAP_PORTJ_gc = (0x08<<4) ; Mapped To PORTJ
.equ PORTCFG_VP3MAP_PORTK_gc = (0x09<<4) ; Mapped To PORTK
.equ PORTCFG_VP3MAP_PORTL_gc = (0x0A<<4) ; Mapped To PORTL
.equ PORTCFG_VP3MAP_PORTM_gc = (0x0B<<4) ; Mapped To PORTM
.equ PORTCFG_VP3MAP_PORTN_gc = (0x0C<<4) ; Mapped To PORTN
.equ PORTCFG_VP3MAP_PORTP_gc = (0x0D<<4) ; Mapped To PORTP
.equ PORTCFG_VP3MAP_PORTQ_gc = (0x0E<<4) ; Mapped To PORTQ
.equ PORTCFG_VP3MAP_PORTR_gc = (0x0F<<4) ; Mapped To PORTR

So it seems as though each port is assigned a number, starting at 0 for PORTA up to 15 for PORTR. The second set of defines for VPORT2,3 are redundant.

Still being partly human, I read decimal not friggin HEX, so my bloat hating brain reduced this down to...

PORTCFG.VPCTRLA = PORT# + PORT# * 16;
PORTCFG.VPCTRLB = PORT# + PORT# * 16;

"PORT#" is just the letter number of the PORT from A0 to R15, and since the second nibble is needed, the second VPORT is multiplied by 16.

So if I wanted PORTD and PORTE set as VPORT0 and VPORT1, would it not just be a matter of...

PORTCFG.VPCTRLA = 3 + 4 * 16;

Or just...

PORTCFG.VPCTRLA = 67;

I am away from my "lab", so I am just doing a bunch or reading, and found it absolutely stupid that to just set a few virtual ports, I needed a PORT.C driver file SOME .H file and 2000 lines of crazy HEX defines... Really?!?!

I have a few XMega datasheets here with me, but have yet to find one that explains the PORTCFG.VPCTRLA in its most basic sense.

Ok, my rant is over, but I did want to check my thinking on how this regs are so easily set without resorting to all of that foo foo.

Brad

I Like to Build Stuff : http://www.AtomicZombie.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Why are you doing all this? All that stuff is already defined in the assembler .inc for your favourite Xmega. So you will get double definitions errors.

Did you open one of the .inc files? :-)

Also if you are crazy enough to do something similar in the future use the #define notation rather than .equ and you can take the file between the Atmel assembler and your favourite C compiler. :wink:

edit also anything with a structure notation like PORTCFG.VPCTRLA can easily be replaced by a more human understandable fixed address as PORTCFG_VPCTRLA and it will again work with C or with the assembler. Again this is all done for you in the .inc file.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I just don't like all that fluff. I just think 1000 lines of code to do this is silly (for my needs)...

PORTCFG.VPCTRLA = 67; 

Anyhow, I ended up rigging up an XMega board, and it works great. So my theory was correct.

Sometimes I wonder about the state of code these days! I mean, if I were to use this kind of coding to describe how I would turn on a light bulb...

Define bedroom wall
define switch_position_on
define switch_position_off
define hand
define arm
define light_on = arm + hand + wall(switch_position_on)
define light_off = arm + hand + wall(switch_position_off)

.... and on and on and on and on..... ACK!

Just say Light=On!

I guess I am spoiled from assembly where you just talk to the hardware directly. None of that longish crap is more understandable to me than the simple register names and decimal values.

Anyone else out there think that micro-controller code is looking like a bloated floater these days??

I needed to understand a C program a few days ago and started by picking out all the crap. When I was done, it went from about 2000 lines, 4 includes, a few .H files right down to a single .C file that took no more than 2 pages, including my own logical comments!

Ok, it's late, time for sleep before I harpoon another whale and shave another yak!

Later.
Brad

I Like to Build Stuff : http://www.AtomicZombie.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There's a difference between ASF and AVR-Libc. I agree the former is mainly a lot of pointless bloat while the latter is a well thought out definition of the minimum you need to program the micro. io.h and hence ioxNNN.h are part of AVR-LibC and should provide what you need for things like Vports, except that Atmel made that mistake of using C enum's for some of the definitions which aren't available to avr-as.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes, I found that out the hard way. Also, the VIRTPORT examples don't work now either. Definitions changed, missing, etc.

Funny, I always hear the word "potability" thrown around as an argument of C over assembly, but find it to be 100% the opposite. By the time you weed through the pointless none-code C chatter (usually 90% of a C program), you could just rewrite the thing in assembly and it will work on almost any AVR or XMega with a few reg renames.

I guess it just baffles my mind how something so simple can be made so wordy. They are just 8 bit registers for the the love of god man!!! You put values from 0-255 in them, so why on earth we need 4 pages of garbolla to define and mask, and shift and twiddle and massage these things is beyond my comprehension.

Oh well, I shall plug along and keep my fat trimmer razor sharp!

Brad

I Like to Build Stuff : http://www.AtomicZombie.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
how something so simple can be made so wordy
It has been taken over by programming lawyers...
Quote:
is beyond my comprehension.
Not sure what you mean, so you don't like using things like PORTA, PORTB etc. they are also simple definitions in the .inc file and NO I'm NOT talking about C but ASM here.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

so you don't like using things like PORTA, PORTB etc.

They are OK but suppose you want to map PORTA and PORTB to the first two virtual ports the syntax is bad whether you do it in C or Asm:

PORTCFG_VPCTRLA = PORTCFG_VP02MAP_PORTA_gc | PORTCFG_VP13MAP_PORTB_gc; 
ldi r16, PORTCFG_VP02MAP_PORTA_gc | PORTCFG_VP13MAP_PORTB_gc
sts PORTCFG_VPCTRLA, r16

Who on earth came up with those names!?!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm just astounded that you managed to produce such nice NTSC video output but can't read/think in hex...

Quote:
Just say Light=On!

In reality it would be more like Light=0 (active low). The problem is if you ever need to change the '0' to something else you now have to go through all your code looking for where it is hard coded. Also a zero doesn't make it obvious if you are turning the light on or off, you have to refer to the schematic or a comment to figure it out.

Much easier to just set up nice #defines for the on and off states, making the code both more readable and easier to modify.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Light=0
Please #define light :-) Candle, oil lamp, electric lamp, LED? (different functions or subroutines are required for each of these)

When I was a bit younger I could enter hex codes into my little micro board with the ASR33, didn't need no stinking assembler. The hex output was pretty much all one would get in electronic magazines projects.
A line assembler was a luxury.

As I entered the code I could see the mnemonics flash in front of my eyes (they have now been replaced by permanent floaters). Making a mod was easy, just go to the location you want to change/add to and replace the last opcode or 2 with a JMP to an unused part of memory and then add you code there.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have to say that Light=0 is actually very PIC-esque. The HITECH compiler in particular loves to define everything that way, and you end up having no idea if you are writing a value into an 8 bit register, a 16 bit register or a bit. Horrible :-)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

mojo-chan wrote:
I'm just astounded that you managed to produce such nice NTSC video output but can't read/think in hex...

I guess my cyborg implants have not fully assimilated me into the collective yet! For some reason base 10 seems more natural than counting to 16 with alpha-numerics!

Bit banging NTSC color was just a matter of careful cycle counting and knowing the XMega hardware right down to the bare metal. Assembly is a beautiful and perfect language for micro-controllers, and I really enjoy it. I also like using C for things like 3D math and heavy 16/32 stuff, but other than that, I find it a bad language for a micro-controller in general. Verilog on the other hand would have been a better high level uC language I think. It is "fluffy" like C, but gives you much better bit level control.

I have been dipping into assembly since my PET days, and always converted form HEX to DEC. I see no real use for HEX at all really. Binary is certainly necessary, but I would still rather write ldi r16,7 rather than 'b00000111.

I guess I am just on a rant about the latest programming trend, which has decided that it is better to say something in 1000 lines rather than in 100 lines. Oh, and don't forget to have at least 30 includes, and add all libraries even if they are not in use, or from some other unrelated program found in the net 5 months ago. Don't EVER call a register by name, or try to set values without 25 different flavors of bit-masks that all mean the same damn thing. Oh, and remember, setting an 8 bit register is an extremely complex task, so you best look for a driver with 12 includes and some kind of make-file thingy that only works if you are running Purple hat Linux version 12.3.3.4.4.55.55.5.555!

And you must NEVER EVER try your code on real silicon, always use a simulator, just like you should ONLY interact with other carbon based units through facebook and texting, never in real person. Real hardware has voltage, and requires a red hot soldering iron, so it is dangerous, just like real people.

The next generation version of the tool-chain will include voice recognition and "intelli-code", so you just pick up your microphone and tell the compiler what you are trying to do. It will fill in the rest, including choosing an appropriate controller (that can run Linux, of course) and then it will order it for you from Digikey, send away for a board, and make all shipping arrangements.

See.... I go off just thinking about it! Before I go completely mad, I bet people will by trying to run .net on these things!

Where does this madness end!!!???
OK, insane rant over, I will retire to my cave and optimize some assembly code for a few hours to get back to normal!

Brad

I Like to Build Stuff : http://www.AtomicZombie.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
it is better to say something in 1000 lines rather than in 100 lines.
But think of the positives! You are getting so much more and for nothing.

I have been trying to understand the Xmega's ADC, so it's only about 6-8 lines of C code to set up and one or 2 lines of C code to use.

So I download AVR1300 to get a better understanding of things and was surprised of how much MORE I got and for nothing: Just under 8M of stuff, 834 files in 40 folders!! Sooooooooooo much better than just one page with a few lines of code. :roll:

That will SURELY make me an ex-spurt on the subject.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yeah... now that's what I'm talking about! In the end, you will probably get away with 4 lines of code, setting 4-6 regs at most.

I have been doing my best to simplify all of the XMega stuff, so maybe I have code for your ADC already. What are you trying to get out of it?

I might just have a 4 line code snippet in my collection that does not require you to add another JBOD to your workstation and fill your progmem up to 98% capacity.

It's good to hear I'm not the only one feeling bloat and the buzz of that endless herd of yaks that need shaving!

....bzzzzzzzzzzzzzzz!

Brad

I Like to Build Stuff : http://www.AtomicZombie.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I think have it sorted out more or less (even in ASM but posting in C for the ASM challenged... :wink: ) https://www.avrfreaks.net/index.p...

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

as surprised of how much MORE I got and for nothing: Just under 8M of stuff, 834 files in 40 folders!!

Ah the joy of ASF! (the Xmega app notes are an early fore-runner to ASF).

Sadly you need to get used to this. I have been looking at 4 ARM eval boards and to a man they all have these kind of "bloat libraries". The idea that you might actually write "DDRB=0xFF; PORTB=0x55;" ever again seems to be an anathema.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I will fight!! I shall deny the bloat! I may even add a special section to my new site... "Talkin' to the bare metal".

Brad

I Like to Build Stuff : http://www.AtomicZombie.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Specifically (I know I'm not suppose to mention this) I was looking at the LPC Xpresso LPC812 as those 800 devices are as close to "8 bit micros" as ARM/Cortex currently get (there's an 8pin DIP one!). But to use the debugger/programmer (LPC-Link) that is built in it seems you are tied into using CodeRed's Eclipse based IDE and it comes configured to use a whole load of their library code. I just want something simple (like AS4 / Code::Blocks) that lets me just write for the bare metal then program/debug the thing. It seems I'm asking too much and yet this isn't a 128/256/384K super micro. It's a set of 4K/8K/16Kb micros that *should* be simple.

Just like Asm programmers moaning about C because of the "bloat" and "hidden stuff" that gets in their way I think C programmers can now complain about all this chip targetted library bloat that seems unavoidable as it "makes the thing easier to program".

Err no, no it doesn't. It means that not only do I have to read the datasheet and understand the bare metal registers as I was bound to do anyway (to get the best out of 4/8/16K) I now have to wade through reams and reams of library code documentation to try and find which are the important bits (like PLL clock setting) that I must have and which are the developer's ego trip that no one is ever really going to use. To my mind this actually makes the development harder than if they gave me a C compiler with a startup that does little more than setup .data and .bss and let me read about the PLL and anything else that is important in the bare metal datasheet.

I guess they'll call this "progress".

(perhaps Arduino has gone to everyone's heads?).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:

I guess they'll call this "progress".
(perhaps Arduino has gone to everyone's heads?).

Say it like it is brother!

You know what? I bet we sound like "old codgers" now! Maybe our dislike of this new "bloated yak" style of coding is much the same as the old stories we used to hear from our folks...

"you know sonny, I had to walk 43 miles in 12 feet of snow to get to school, and you young bucks complain about riding the bus for half an hour..."

Let's see...

Hey gramps, you don't need the actual chip! Just run it through the simulator. And what the hell are you doing writing code? Just drop in a library and use the core generator. If your LED flasher doesn't fit in the 512k device, they have an 8mb core. "cycle count"? what's that, some kind of bike game?

I was talking to a College instructor (embedded systems) a while back and he also had the same thoughts on the way things were heading. He did not like teaching the required material, and actually forced students to do some PIC assembly here and there.

Oh well, it makes it all the more fun when you drill right down into the metal and do things that most would consider magic, even though the silicon was designed for it. No matter how much fluff you put between the programmer and the silicon, at the end of the day it's all assembly, sonny boy.... ones and zeros pal, 8 simple bits, a handful of registers. Nothing that warrants 1000 lines of bloatcode.

Brad

I Like to Build Stuff : http://www.AtomicZombie.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
actually forced students to do some PIC assembly here and there.
SATAN in the flesh!! :lol:

Fire and brimstone no longer good enough? :mrgreen:

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Indeed! Can you imagine going from something high level right back to that evil W register?

Brad

I Like to Build Stuff : http://www.AtomicZombie.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Brad all I can say is that this is even easier than Assembler and C. Ready for it...

10 POKE 53280,0:POKE 53281,0
20 PRINT "HELLO WORLD"
30 END

SYS64738

Hehehehe :)
Pete

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Oh yes, I do like that!
But didn't you just set the foreground and background color to black? If so, the text won't show!

Might have to...

POKE 646,3

I miss the good days!

Brad

I Like to Build Stuff : http://www.AtomicZombie.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Is the yak still sitting at the barber's chair? :?

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

hehe Brad, I was an Atari 800XL user !!! 256colours, 4 sound channels and 64k ram. LIKE WOW !!!!!! But the Commodore64 was a great machine as well. The Xmega's have more power than the whole 8-bit micro's ! hehehe Makes me laugh just thinking about it :)
Pete

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

js wrote:
Is the yak still sitting at the barber's chair? :?

The yaks are all shorn now, so I am free to make progress! Working on my new site/board every Thursday until it is ready.

Brad

I Like to Build Stuff : http://www.AtomicZombie.com