Why is everyone so adamant on coding in C?

[be80be]

misterT said the same thing. And

Computers don't do "random",

no but people do LOL

 

[misterT]

I don't think Mr RB suggested the Black RNG was pure random, just that it had better entropy.

Yes he did. In the website he says: "My algorithm for generating pure entropic (random) data" and "After enough passes the data is completely random and cannot be predicted."

 

[LTX71CM]

Yes he did. In the website he says: "My algorithm for generating pure entropic (random) data" and "After enough passes the data is completely random and cannot be predicted."

Mr RB didn't say that, Mr Black did.

There is a RNG here that generates very good entropy from a simple algorithm although it is not particularly time efficient; The Black Random number generator

I'd say either Mr Black isn't well informed or that he knows something others don't. Perhaps he just mis-spoke/mis-typed.

 

[misterT]

Mr RB didn't say that, Mr Black did.

Where do you think the nickname comes from?

Anyway I am interested to try out his RNG. Maybe I do some tests myself when I have time.. maybe I post the results to the forum too. It is just annoying that Mr Black tries to sell his RNG like it is some pyramid scam or a TV-Shop product. There should be some test results and properties of the RNG presented in the website.

 

[LTX71CM]

LOL! Wow, can I borrow a towel? Face, egg, everywhere.... Carry on gents. ;-D

 

[arhi]

It seems that hardly anyone codes in primarily assembly anymore, yet I've read pretty much everywhere that assembly code seems to be much more efficient than C.

1. asm is not by default more efficient then C. good asm developer will probably write better code then bad c developer, but good asm developer vs good c developer in 80% cases the C code will be better
2. what is "better" code, what is "more efficient" code?

To optimize asm code you need to hire very smart ppl and they need to spend hours optimizing it. Optimized asm code is very hard to maintain. To optimize C code you turn optimization on in your compiler, you can even choose - you want speed or size or both to be optimized - it takes few seconds to optimize your C code and your source remains the same easy readable easy maintainable code - that can actually move from mcu to mcu.

Again, a team of professionals will in mosr cases make asm code better (faster or smaller) then C compiler will do, the thing is
- they will make code run 3% faster
- they will make code 5% smaller
- they will spend 5 days

team of "good developers" working 5 days cost some money, not small money... let's say it is 2 man team we are talking 80 work hours, you don't pay such smart guy's below some 40$ per hour so we are talking 3200$ for the optimization. The best of the best compilers are cheaper then that, but not only that ... what did this 3200$ acomplished? 3% faster and 5% smaller code that is impossible to maintain - if you pay 0.1$ more you can purchase mcu that will be 30% faster with 10% more flash so your "unoptimized" code will still fit and still run faster then the super optimized and if you are using less then 3200/0.1=32000 mcu's for your project, the C was more efficient! And even if you are makig 32000 pcs of your device it might be cheaper to go with C just because next time you want to upgrade something there's another expense, and if you make second product if you developed first in C you might borrow some functionality, if it was in ASM and your new product uses other mcu, you have to redo all from scratch ....

And yes, there are coders that do work for 3$/h but those are unable to make asm code that is better optimized than one generated by c compiler ...

one interesting link wrt this discussion: YouTube - EEVblog #45 - Arduino, PICAXE, and idiot assembler programmers - the reeeealy interesting part start around min13:00

few quotes
- "assembler is for archaic dic*heads"
- "some inline assembly is ok, but to write your entire code in assembly is a mark of madness"
- "if you have to worry about every last byte on your chip to fit your program, you have chosen the wrong chip, choose a decent one with a decent amount of memory, there is no excuse any more, it is not 1985"

 

[Dakta]

I started pic programming with assembly.

It was a good way to start in my opinion. Learn to set up the chips, the clock speeds, the timing, the interrupts and so on.

But when you want to read numerous analogue inputs, consult maps stored in eeprom, set the duty cycle based on the resulting lookup figure and finally output it to lcd for debugging, something like C would be a lot easier.

However if you start with C, you might regret it, as you never quite escape the registers and you might find yourself missing little blocklets of information that get your project working.

I think what i'm trying to describe perhaps is 'hardware appreciation'. If you are aware of the task your C modules are performing you might also be aware of it's strengths and limits, especially when it comes to common modules that say, overwrite registers for others or whatever.

So a bit of assembly helps. No need to be a genius at it, just be able to guesstimate whats going on underneath your code.

It's just my philosophy of matters, I'm no great shakes at asm or C but I think a little of both is perhaps a good help.

and finally, never go overkill. If you can write a solution that works in C then forget assembly. If you can write a solution in flowcode forget C. Yes it arguably ain't proper but your aim is the solution. Just take time to have a bit of understanding.

 

[ericgibbs]

I started pic programming with assembly.

It was a good way to start in my opinion. Learn to set up the chips, the clock speeds, the timing, the interrupts and so on.

But when you want to read numerous analogue inputs, consult maps stored in eeprom, set the duty cycle based on the resulting lookup figure and finally output it to lcd for debugging, something like C would be a lot easier.

However if you start with C, you might regret it, as you never quite escape the registers and you might find yourself missing little blocklets of information that get your project working.

I think what i'm trying to describe perhaps is 'hardware appreciation'. If you are aware of the task your C modules are performing you might also be aware of it's strengths and limits, especially when it comes to common modules that say, overwrite registers for others or whatever.

So a bit of assembly helps. No need to be a genius at it, just be able to guesstimate whats going on underneath your code.

It's just my philosophy of matters, I'm no great shakes at asm or C but I think a little of both is perhaps a good help.

and finally, never go overkill. If you can write a solution that works in C then forget assembly. If you can write a solution in flowcode forget C. Yes it arguably ain't proper but your aim is the solution. Just take time to have a bit of understanding.

hi,
This IMO is the well balanced approach to programming, bit like knowing whats happening under the hood of your car and not just being a driver...

 

[3v0]

I have been looking into how to get people started with microcontrollers for a few years. The one thing that is clear is that it is not a case where one size fits all.

What the person already knows and how they learn (or how their mind works) will determine what path is best for them.

For people with a hardware background with digital logic the learn ASM while learning the architecture often works. But without the background it can bet too much to absorb at once.

With a decent compiler you do not need to know the cpu architecture. You do need to understand datasheets to get the IO and peripherals working. How related are the two?

OK sure there is value in knowing the machine level workings. But do we have to start there? Not always.

 

[Dakta]

This IMO is the well balanced approach to programming, bit like knowing whats happening under the hood of your car and not just being a driver...

Thanks, my only concern with such an approach really is that it doesn't encourage specialisation in a particular language, which might limit what you can do. Obviously to make a complete solution for a complicated task one has to be a master of the tool they are going to use.

For this reason I'm a fan of modular systems that recycle code, in an idealistic world a developer would keep his workload down, and perhaps make a good percentage of the software 'function calls' and keep his project specific code down to functions that are unique to that solution.

But anyway, that isn't the point, but 'a bit of assembly' and 'a bit of C' won't get you building complicated solutions, so whilst I think it's a good thing to consider a bit of both you do need to do more than just put each hand in a different cookie jar.

It's the sort of situation I'm in, I can do a little assembly, do a little C, but it turns out that combined I can't do a right lot. Shame eh? by all means I'm learning but you have to be careful not to fall into that trap.

 

[be80be]

It's the sort of situation I'm in, I can do a little assembly, do a little C, but it turns out that combined I can't do a right lot. Shame eh? by all means I'm learning but you have to be careful not to fall into that trap.

You have to stay with one thing. I'm glade I learned asm it sure helps setting up chips. But to get real good at say C you need to stay with it. Then after while they all look the same LOL

 

[3v0]

You have to stay with one thing. I'm glade I learned asm it sure helps setting up chips.

IPerhaps you are confusing ASM with understanding what each bit in a SFR is used for. In C we can use RegNam=0xValue. You do not need ASM to set bits

 

[Dakta]

I agree. C is a cracking language for that.

In all fairness I don't think my problem is too severe that a decent book can't sort out. I'm just a tight git.

I need to spend some time and start doing things the hard way and empower myself

I'm very fussy about compilers mind, how hard is it to port code between two? don't they use different libraries for common functions (say, interfacing with hd44780 lcd's for instance)

 

[Nigel Goodwin]

I agree. C is a cracking language for that.

In all fairness I don't think my problem is too severe that a decent book can't sort out. I'm just a tight git.

I need to spend some time and start doing things the hard way and empower myself

I'm very fussy about compilers mind, how hard is it to port code between two? don't they use different libraries for common functions (say, interfacing with hd44780 lcd's for instance)

Everyone always claims that the big advantage of C is it's 'portablility', yet it seems no more portable that any other HLL, it's not even portable between different windows compilers, never mind between different micro-controller ones

 

[be80be]

IPerhaps you are confusing ASM with understanding what each bit in a SFR is used for. In C we can use RegNam=0xValue. You do not need ASM to set bits

Ok how many post are on here I'm using C and my adc don't work or I can't blink a led or my pin not a output Or I don't no what ICSP is

You don't get from people who know some asm because they have to read the data sheet

I like basic and it can't always set ports right and C is not foolproof

 

[Dakta]

You raise a cracking point Nigel, and one a beginner must navigate around.

I'm very fussy with compilers and unfortunately a while back I settled for one that was, well not particularly popular nor documented.

I stuck with it got through the helpfiles, then wanting to branch out a bit got myself an ebook, however that used a different compiler and suddenly the last few weeks were worthless.

It's enough to put a man off

 

[Nigel Goodwin]

I did think the thread title was pretty useless as well

Most micro-controller coding is in assembler, not in C.

I've no problem with people using C, but I still maintain that they would be FAR better off doing a few days assembler first - this forces you to understand the hardware, which is essential in C just as in assembler.

Historically, in Universities, students weren't allowed to move on to HLL's until they had mastered assembler - which makes as much sense now as it did back then.

 

[Dakta]

They did it the other way around for me, shoved me in a java class having us write 'hello world' applications amongst other desktop stuff whilst wittering on at us about bus widths, memory speeds, disk access times etc.

In all fairness they did attempt the little man machine with us eventually (iirc) which is basically assembly with an attempt to simplify it by imagining a little man running between peripherals to grab chunks of data.

Oh well I'm wandering off topic but yes, I know enough to agree that a bit of assembly is a must, from the C that I've done, i've never actually felt a million miles away from the assembly front.

Matter of fact it's just like assembly but with some fancy subroutines, so you can tell it to do math rather than tell it how to do the math then to do the math

 

[arhi]

Most micro-controller coding is in assembler, not in C.

No disrespect, you know I have very high opinion of you, but let me disagree - strongly. I do know asm, I spent many years coding in asm only (both on intel and motorola, both on desktop and embedded systems), I do know asm pretty well, won many competitions for this an that (long time ago when ppl still had 16 color image competition, c64, amiga500 etc demoes etc etc ..) where asm was they only way to do stuff ... and I don't say this asm knowledge don't help me be a better c/c++/java/.not/whatever developer today but I do say that writing application, any application, weather embedded or system or desktop is plain wrong. Maintainability of the asm is non existant, especially if any of the "tricks" to get the code smaller or faster are used and portability is not something to even discuss.. So, yes, I agree knowing asm helps but nothing else ... also "most mcu coding is in asm" - WHERE? in what year? First, most of mcu's used in larger projects today are not 8bit pic's (nor 8bit atmels), and if you compare prices the 8bit pic/atmel cost as much as 32bit pic/atmel/arm - where's the economical benefit here? Don't get me even started on advanced protocols, start with simple usb cdc profile, nothing more that that ... yes usart is simple - when was the last time you seen computer with serial port?

I'm not talking as a new kid who first learned C and then decided that .not is God given thing and that everything else ain't worth it ... my first lang was basic and because I seen with basic I can't do squat (too limited) I learned asm and was developping in asm even for win3.11 (in the meantime I did learn pascal and C and fortran and occam and many other lang's but I still used asm as I was sure the code was best and apps were faster and I had a huge library set to speed up my development) ... but then the time came where I had to realize that I'm being run over and that I need to catch up ... so now - inline assembly is all the assembly I do ...

As for the comment that "it's not even portable between different windows compilers", it is very half-baked truth, no, the "project in c" written on one compiler for one hw platform will not be recompiled on another compiler for another hw platform, but any logic that you write can be portable from one compiler to another and from one platform to another, there's so many libraries I share between 8bit PIC, 8bit ATMEL, 32bit PIC and 32bit ARM ... if any of them was written in asm there would be no way to move them around, and each of these platform uses different compiler ...

On top of everything, this forum mostly (and OP implicitly) are HOBBY electronics, so we are talking under 100 pcs of anything we make right (you don't make a hobby project in 100k pcs), difference between smallest and biggest PIC for example is below 15$, the darn 32bit dev board is below 10$ with debugger and all ... where's the benefit of coding 5% faster code and 5% smaller code - to save 2$ ??? is your time so cheap that you are willing to spent hours to save 2$ that you have to pay for "bigger & faster chip" ?

So yes, knowing asm and understanding the underlying hardware does make you better developer and does allow you to write better code but knowing asm and writing app in asm are two very different things.

 

[3v0]

The first thing the EE department did at my university was make everyone learn Fortran. That was years ago so I took a quick look at their site for ECE students.

https://www.electro-tech-online.com/custompdfs/2010/11/ce_curr_2010.pdf
Freshmen students start digital logic and then MatLab.
Sophmore student take "Programming in a high level language with applications to engineering computation, analysis, and design." (not sure what language)
Only when they are Juniors do they take "Embedded Sys w/Lab".

What I see here is a desire to get the student to think in the abstract prior to the introduction of ASM.

Nigel I am not sure how you want to count most. If one counts the number or projected coded I expect you will find that high level projects are far more numerous. It is just too expensive to do any but the smallest projects in ASM. As pointed out earlier you need more people to get the same project done in the same time. Time to market is everything these days, why would any sane manager try to use ASM?

What Arhi said on the profitability thing. I might add that the major problem with portability is due to a lack of agreement between compiler vendors on port and register names.

A well written driver can be rapidly ported from one compiler to the next with a few find a replaces, and changes in the header file.

Ok how many post are on here I'm using C and my adc don't work or I can't blink a led or my pin not a output Or I don't no what ICSP is

To use C on a micro controller you need to know both C and you need to know the micro controller peripherals. It does not matter what language you attempt to program in if you can not or will not look at the documentation.

The other problem with you logic is sample size. We have no idea how many people are using what language. We could be seeing problems from .001% of C users or maybe 100%. The important thing is that people are getting help.