Microchip & OnSemi want to buy Atmel?

In this day and age, programming in asm to save code space shouldn't be an issue. Neither should banking, limited stack space, or other limitations from the

1970s.
Reply to
RumpelStiltSkin
Loading thread data ...

On a sunny day (Sat, 4 Oct 2008 09:26:12 -0700) it happened "RumpelStiltSkin" wrote in :

Well, it is like you say: we need no wood, we have concrete, we need no nails, we have glue, etc...

Use the right thing for the right job! The little 8 bit pics are made for asm. If you have problems understanding banks, small stack spaces, and some other limitations / peculiarities, then you likely do not have the brains to fully use C on a much bigger micro either.

PIC serves me well, learning a few special tricks took hours, not more, this is the same for each new micro. It is a very simple instruction set, and yes I know very well how to program in C. But I would _never_ and I repeat _never_ use C on a simple micro like an 8 bit PIC.

Reply to
Jan Panteltje

I've used PICs extensively ... and hate them.

In this day and age, chips are cheap enough with decent code space. Shouldn't have to beat yourself to death to fit in 1K.

I never use assembly unless forced too. Hitech C is quite efficient on a PIC. Done may systems that way.

Reply to
RumpelStiltSkin

in C.

PIC.

Why?

w..

Reply to
Walter Banks

On a sunny day (Sat, 4 Oct 2008 11:30:17 -0700) it happened "RumpelStiltSkin" wrote in :

Well, I am not getting into a C versus asm war, it is pointless. This also replies to the other poster's 'why'. If you dunno why you are in the wrong field.

In asm, at least you know what actually happens. There is no problem playing around with data and registers.

Timing, adding a few nops, it is fun. Only advantage I would see for C is, that if you have a lot of floating point stuff, you can perhaps do the math in a simpler way. OTOH you can do most stuff in integer math too. The libraries are all there for asm.

No, I like to use the spare resources in a way I have full control over, that is why asm.

It will work out cheaper too, as you can use smaller PICs, could be important if you need a lot.

OK, I am out of this pointless discussion. As a last remark, if you really want bigger, use Linux and gcc on a board with a different processor supported by gcc.

That is an other price point all together. The little PICs are great for lots of stuff. And programming in asm is _not_ more complicated then in C for many applications for those!

Reply to
Jan Panteltje

Now that the thirty-times leveraged million-dollar mortgages to paupers market has imploded, bankers have to hustle up commissions someplace else.

Mel.

Reply to
Mel

I know how to program PICs and it is fun, because you have to think about how to do solve a problem with the small instruction set and limited resources (if it sounds strange that is is fun for me, the reaon is that I'm a programmer, so it's relaxing like Sudoku for non-programmers, which I don't like :-) , but as you say, the advantage is that you have the full control of the hardware. This was my last small hobby project:

formatting link

But I disagree that it is not more complicated than programming in C. I think I could implement the monoflop project with 1/5 C source code compared to the assembler code and it would be easier to understand and faster to write, because you can concentrate on the problem and don't have to think about strange PIC things like skip-if-not branches etc. at the same time.

BTW: what do you think of the RS08 series from Freescale?

formatting link

Very nice 6502-like instruction set and they are cheaper than PICs with the same functionalities.

--
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Reply to
Frank Buss

Mostly, but there are sectors where the last 1c matters, and if your client says "SOT23 uC", then you are already constrained.

Of course, as the designer if there are two similar SOT23 uC, and one is better with a compiler than the other, then you have the luxury of choice :) [PIC//Freescale spring to mind here]

-jg

Reply to
Jim Granville

On a sunny day (Sat, 4 Oct 2008 21:55:35 +0200) it happened Frank Buss wrote in :

Nice project, yes for signal detection this can be useful.

Here my last PIC hobby project:

formatting link

Well, it all depends, I was writing today (or am writing) some intrusion detection and counter measure software in C, (Linux based), it detects those nasty denial of service and even worse Kaspersky related attacks on my name server, and automatically starts counter measures. It is linked list based, and coding time was so far some hours. Been test running now tonight (I am lucky somebody is attacking my port 53 now). I need this so the server stuff can run unmanned for a long time, it sucks if your log in the morning shows you have been made part of a botnet... or similar. This program test frequently.

This programs depends on other stuff (like snort) and scripts, and is simply a bit complicated, in the sense that writing it is asm would take a lot more time (for a x86), but always remember 'Hello world' in asm is only a few bytes, and linking in libc with printf() variants in C takes more space. If all came down to it, then it would (with the right libs you build over time in asm) not be that much more work to do in asm, but it 'looks' simpler in C. But on this system I have practically unlimited memory and resources, so C is nice.

Well I have not used it, so I cannot give an informed opinion :-)

6502, now that is long ago....
Reply to
Jan Panteltje

"Jan Panteltje" skrev i meddelandet news:gc86jr$sff$ snipped-for-privacy@aioe.org...

That is exactly why you want to avoid them...

Fact: Programmers are less productive in assembler than in a high level language. You therefore need to show that you have some other benefit from using the PIC, or you have just proven yourself to be a poor engineer.

Funny, I got a ~700 byte ATtiny13 assembler program from a customer who wanted help finding a bug. I rewrote the program in C using the IAR C compiler and managed to reduce the code to ~400 bytes.

I would never *start* writing a program for the AVR in assembler, simply because it rarely makes sense. I find that most AVR customers agree with me.

--
Best Regards,
Ulf Samuelsson
ulf@a-t-m-e-l.com
This message is intended to be my own personal view and it
may or may not be shared by my employer Atmel Nordic AB
Reply to
Ulf Samuelsson

That's because you (and others) are used to it.

Yes. It actually isn't. There is usually only one way of doing something, rather than the 55 of C. But it isn't available for everything.

--
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: 
            Try the download section.
Reply to
CBFalconer

... snip ...

I'll wager you used something like Turbo, which does not meet the language specifications. I used it for nearly 15 years in embedded work, with very wide applications, and minimum problems.

The above attitude is just what I am regretting. I don't believe the language will return, but Ada is available.

--
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: 
            Try the download section.
Reply to
CBFalconer

... snip ...

That says, among other things, that the AVR coding is suitable for expressing C source, and that a decent compiler is available. Nobody says that about PIC assembly coding. In my experience attempting to move something to C for the PIC involves loss of clarity, and something like a factor of three in code size. Admittedly my PIC experience is about 10 or 15 years old.

If you want something simple, that can be handled by a PIC and its memory, PIC assembly can be very attractive. Say for a Microwave controller.

--
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: 
            Try the download section.
Reply to
CBFalconer

Which part of Turbo Pascal doesn't meet the language specification? I think TP is a superset of Pascal, because it has some more features, like inline assembler and object oriented extensions, but otherwise it should conform to

formatting link

Something similar is used as structured text (ST) for PLCs:

formatting link

Looks like ST doesn't need begin/end for multiline blocks, which I always disliked in Pascal.

--
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Reply to
Frank Buss

detection

and

I hope you don't use something like BIND? The last time I installed a nameserver and SMTP-server on a Linux system, I installed it in separate chroot-jails. Nowadays my hoster provides these services and I'm using only lighttpd for my webserver, which is small, clean, more secure and faster than Apache.

If you really like to do all by yourself, there are nice features in iptables, if you are using Linux.

Yes, looks like I'm getting old :-) Today most people think it is cool to write PHP or Visual Basic programs, if they are interested in programming at all, but only a few people know the basics, or even like it.

--
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Reply to
Frank Buss

ST is more like Modula-2, in that the Pascal 'begin' is implicit, so you avoid the single-line context variance of pascal.

ST also includes the Modula-2 extensions, of IF..ELSIF and adds an ELSE in the CASE statement.

ST slightly extends Moudla-2 in that it is more explicit on the END - ST has END_FOR, END_IF, END_WHILE etc

ST also allows this super-set of Modula-2 on numbers (more Ada like) :

binary numbers 2#111111111, 2#1111_1111, 2#1111_1101_0110_0101 octal numbers 8#123, 8#777, 8#14 hexadecimal numbers 16#FF, 16#ff, 16#9a, 16#01

-jg

Reply to
Jim Granville

The logical conclusion is that with the PIC you have two choices:

Poor productivity, by programming in assembler - or - Poor code density which in the end means high cost.

Can't see how such a part can "serve you well". The comments fromJan Penteltje: "8 bit PIC is just fine." -- Shown incorrect "Small PICs, like the 8 bit, are ment to be programmed is asm." -- Should therefore be avoided "Use the right thing for the right job" -- See above "In asm, at least you know what actually happens." -- read the list file!

Then again, this is well known.

There are other of course other decision criteria.

--
-- 
Best Regards,
Ulf Samuelsson
ulf@a-t-m-e-l.com
This message is intended to be my own personal view and it
may or may not be shared by my employer Atmel Nordic AB
Reply to
Ulf Samuelsson

Turbo totally fails to supply critical things such as the i/o subsystem. This includes f^, which is a pointer to the last input (or output) to file f, the put/get functions, which control those transfers, etc. This completely fouls up normal Pascal i/o, which is very capable of handling look ahead. Other limitations/faults include the handling of numerical input, which insist on termination with a (I believe), rather than simply halting at the first non-fitting char, which remains in f^.

You can partially tame Turbo with my txtfiles.zip unit, which is available at:

but there was no excuse for this failure when they rebuilt Turbo (for Turbo IV).

--
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: 
            Try the download section.
Reply to
CBFalconer

On a sunny day (Sun, 5 Oct 2008 06:29:53 +0200) it happened Frank Buss wrote in :

detection

and

Yes I am using bind, and the very latest too. There is an issue with source port randomness, and transaction id randomness, you can test it here (press on 'Test My DNS'):

formatting link

When behind some NAT translation tables, like from a router, the port randomness will be destroyed however.

Well, OK, but the latest attacks are about something like poisoning the database.

I A AM SO GLAD I DO NOT HAVE AN ISP, THEY ALL SUCKED.

mmm, Apache does a good job so far here.

Yes of course I use IP tables, just passed the 1000 entries :-) Imagine 1000 bad guys.

Once in a moment of confusion I bought a book on Visual Basic, thinking it would expand my programming knowledge.. 'Visual Basic 6.0', a thick book... I learned nothing from it, not even how to write anything in VB... Waste of money and time, it seems nothing it can do that I cannot do better and faster in C using existing libs in Linux.

BASIC was OK, though, started on a Commodore PET, later a Timex Sinclair ZX80... But then z80 asm was much more fun.. and the rest follows.

As for php, I use it on the website, it is useful.

In the end maybe 'which language' is not that important, I mean

*if* you can formulate the problem correctly, then you can write the program, you have in fact the solution. But you can do it as inefficient as you like of course :-)
Reply to
Jan Panteltje

I wouldn't trust a program with such a bad security history (

formatting link
). There are good nameservers, which are more secure. E.g. the author of djbdns gives $1000 for the first person, who finds a security hole:

formatting link

I didn't test it, because I used a simpler program last time I installed a nameserver (didn't remember the name), because I don't need all the complexity of BIND-like programs. But looks like djbdns is a good program. It is even not vulnerable to the DNS poisoning exploit:

formatting link

I'm glad that I don't have to maintain the infrastructure and constantly monitoring security issues, appplying patches etc. Nameserver and eMail just works. It is not the cheapest, but my ISP has more than 2 million paying customers, so there is a good chance that problems are fixed fast.

This depends on where you use the language. I don't write bug-free programs, so I would feel uncomfortable to write a web application in C, because it could have buffer overflows or crashs the whole webserver program. If I write it in Java, I just get a nice exception trace in a log file, but the rest of the server program continues to work and low-level bugs like buffer overflows are impossible in Java (as long as you don't use native parts of the system, like JPEG decoding).

--
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Reply to
Frank Buss

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.