Open Source DSP XOs - Page 26 - diyAudio
Go Back   Home > Forums > Source & Line > Digital Line Level

Digital Line Level DACs, Digital Crossovers, Equalizers, etc.

Please consider donating to help us continue to serve you.

Ads on/off / Custom Title / More PMs / More album space / Advanced printing & mass image saving
Reply
 
Thread Tools Search this Thread
Old 16th May 2012, 05:02 AM   #251
diyAudio Member
 
abraxalito's Avatar
 
Join Date: Sep 2007
Location: Hangzhou - Marco Polo's 'most beautiful city'. 700yrs is a long time though...
Blog Entries: 99
Send a message via MSN to abraxalito Send a message via Yahoo to abraxalito Send a message via Skype™ to abraxalito
Cortex M0 assembler I predict is going to become the world's most portable computer language ever, in terms of the number of platforms that will run it natively.
__________________
It doesn't have to take the form of a conspiracy, rather a consensus... James H Kunstler
  Reply With Quote
Old 16th May 2012, 05:55 AM   #252
diyAudio Member
 
steph_tsf's Avatar
 
Join Date: Mar 2008
Quote:
Originally Posted by abraxalito View Post
Cortex M0 assembler I predict is going to become the world's most portable computer language ever, in terms of the number of platforms that will run it natively.
I guess you want bare metal programming, and for this you think you need to code in assembly. There is another way to do it. You may use the C language in a very restrictive way only using interger arithmetics, integer arrays, no characters, define most variables as public, define a few counters and flags as "register" (if your C compiler doesn't ignore such directive), only use simple control flow (if-then-else, switch, do while, break, goto), avoid calling functions so prefear storing the result of evaluations in dedicated variables, be cautious with pointers and structures (check the code generated by your compiler), and last but not least, avoid all input and output features, and avoid all unix/linux system interfaces. This way, you could generate efficient, readable, maintenable and portable code for the Cortex-M0/1/3/4 family. On top of this you would use assembler for your IIRs and FIRs, using different macros depending on the Cortex version you are running, finely tuned to the Cortex version you are running.

Last edited by steph_tsf; 16th May 2012 at 06:00 AM.
  Reply With Quote
Old 16th May 2012, 06:04 AM   #253
diyAudio Member
 
abraxalito's Avatar
 
Join Date: Sep 2007
Location: Hangzhou - Marco Polo's 'most beautiful city'. 700yrs is a long time though...
Blog Entries: 99
Send a message via MSN to abraxalito Send a message via Yahoo to abraxalito Send a message via Skype™ to abraxalito
Quote:
Originally Posted by steph_tsf View Post
I guess you want bare metal programming, and for this you think you need to code in assembly.
The reason I want bare metal programming is because its such fun. So having fun programming is the primary metric to optimise, in my experience the most fun is to be had with tight hand-coding and optimizing every cycle, knowing all the quirks of the hardware and working around or in step with them. In contrast C programmers are at the mercy of their compiler and its ability to optimize and have little need to know machine specifics. If I wrote in C I'd be mulling over the machine code it generated anyway and wondering why it was idiotic in its use of resources. So why not just take the (to me unnecessary) abstraction layer out of the way from the start?

C coding certainly has its place, tiny, ultra-low power systems with heavily limited resources isn't one of them in my estimation.
__________________
It doesn't have to take the form of a conspiracy, rather a consensus... James H Kunstler
  Reply With Quote
Old 16th May 2012, 06:21 AM   #254
diyAudio Member
 
Join Date: Jun 2004
Location: Connecticut
My point was only that in most cases you can implement the same function in C in less time.

If you really enjoy writing in assembler then sure, but I don't know many people who do.

C is heavily used in automotive and implantable medical devices. Assembler is difficult to maintain, error prone, gives you no ability to do static analysis and makes unit testing more difficult.

Last edited by chris719; 16th May 2012 at 06:27 AM.
  Reply With Quote
Old 16th May 2012, 06:23 AM   #255
diyAudio Member
 
steph_tsf's Avatar
 
Join Date: Mar 2008
Quote:
Originally Posted by abraxalito View Post
The reason I want bare metal programming is because its such fun. In contrast C programmers are at the mercy of their compiler and its ability to optimize and have little need to know machine specifics. So why not just take the (to me unnecessary) abstraction layer out of the way from the start?
Try the datacom bitbang scheme as an example. Where do you see an "abstraction layer" if you code it in a very restrictive C like described above ? I think that you would have fun coding the datacom bitbang using such restrictive C. I think that initially, you rejected the bitbang datacom scheme because of the annoyance of coding it in assembly !
  Reply With Quote
Old 16th May 2012, 06:26 AM   #256
diyAudio Member
 
abraxalito's Avatar
 
Join Date: Sep 2007
Location: Hangzhou - Marco Polo's 'most beautiful city'. 700yrs is a long time though...
Blog Entries: 99
Send a message via MSN to abraxalito Send a message via Yahoo to abraxalito Send a message via Skype™ to abraxalito
No, I rejected it initially not for the coding challenges (I enjoy them, provided the purpose is worthwhile) but for the apparent waste of CPU resources. When you presented your case in more detail then I noticed the 20 cycles you estimated was indeed fairly immaterial in the scheme of things.
__________________
It doesn't have to take the form of a conspiracy, rather a consensus... James H Kunstler
  Reply With Quote
Old 16th May 2012, 06:42 AM   #257
diyAudio Member
 
Join Date: Jun 2009
Quote:
Originally Posted by abraxalito View Post
Cortex M0 assembler I predict is going to become the world's most portable computer language ever, in terms of the number of platforms that will run it natively.
good luck to you. Unless you know the processor inside out it will be hard to do a better job than an optimizing C compiler.
  Reply With Quote
Old 16th May 2012, 06:46 AM   #258
diyAudio Member
 
abraxalito's Avatar
 
Join Date: Sep 2007
Location: Hangzhou - Marco Polo's 'most beautiful city'. 700yrs is a long time though...
Blog Entries: 99
Send a message via MSN to abraxalito Send a message via Yahoo to abraxalito Send a message via Skype™ to abraxalito
Its not merely the processor, its all the peripherals too. But yeah, my aim is to get to know them better than the compiler writer
__________________
It doesn't have to take the form of a conspiracy, rather a consensus... James H Kunstler
  Reply With Quote
Old 16th May 2012, 07:10 AM   #259
diyAudio Member
 
steph_tsf's Avatar
 
Join Date: Mar 2008
Quote:
Originally Posted by abraxalito View Post
Its not merely the processor, its all the peripherals too. But yeah, my aim is to get to know them better than the compiler writer
Agree, I/O and peripheral control are areas where handmade assembly code is generally overperforming C compiled code. Such handmade assembly code may deliver a ready-to-use 32-bit integer, to be accessed by the C compiler. This way you may combine the advantages of both worlds.
  Reply With Quote
Old 16th May 2012, 05:58 PM   #260
rsdio is offline rsdio  United States
diyAudio Member
 
Join Date: Feb 2008
Location: Seattle
I disagree with the claim that assembly programming is a waste of time.

In my experience, a mix of C and assembly is most beneficial. Interrupt routines, FFT, and other DSP should generally be coded in assembly, unless you already have an efficient API from the chip manufacturer. The high-level program flow logic can be in C because it is not usually time-critical.

Quote:
Originally Posted by Trevor White View Post
assembler is not portable whereas C usually is.
Interrupt routines are not portable, because they are highly dependent upon the specific peripherals that they are servicing.

As for FFT or other serious DSP subroutines, if you're coding in C for portability then you probably are not using your processor very efficiently.

Companies like Texas Instruments have entire documents devoted to the subset of C that you need to use to take advantage of special addressing modes, bit reversal, and other constructs that are common to DSP but simply not able to be expressed in C. If you want to code those sorts of things in C and place copious comments warning maintainers not to change a single character, then proceed at your own risk. It's not going to be portable anyway, although it might work with a slightly different processor that uses the same compiler.

I'm speaking primarily of actual DSP chips, rather than general purpose processors. However, every processor that I've studied seems to have a few instructions that are useful for speeding things up in ways that the compiler usually misses. This is particularly true for vector processing and other DSP-related tasks.

In general, embedded firmware is not portable. I actually think that it's a mistake to code embedded firmware using techniques that are aimed at portability rather than optimization.
  Reply With Quote

Reply


Hide this!Advertise here!
Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are Off
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Volume / Source selector - open source project ? AuroraB Analog Line Level 22 22nd September 2012 02:21 PM
Violet DSP Evolution - an Open Baffle Project cuibono Multi-Way 211 18th May 2010 02:26 AM
Open call for suggestions on Open Source DIY Audio Design gfergy Everything Else 1 15th April 2007 07:33 AM
Open Source, Open Architecture! zenmasterbrian Digital Source 185 23rd February 2007 10:35 PM


New To Site? Need Help?

All times are GMT. The time now is 03:02 PM.


vBulletin Optimisation provided by vB Optimise (Pro) - vBulletin Mods & Addons Copyright © 2014 DragonByte Technologies Ltd.
Copyright 1999-2014 diyAudio

Content Relevant URLs by vBSEO 3.3.2