Yes, for level 1. Variadic functions are not necessary, and in fact are major error sources in C. Pascal supplies them for read and write operations in a form that avoids the error problems. C doesn't provide the look-ahead file buffer (via f^) and put or get functions. However Ada provides the abilities, and is a modern language, and is also widely available. Ada also provides designed-in access to object code written in other languages.
--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]:
Try the download section.
Unfortunately Borland did not meet the simple requirements of the Pascal standard, which they could have easily done when they brought out TP4 (about 1988). IMO this is heavily tied to the death of Pascal.
I fixed the attributions again.
--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]:
Try the download section.
At least there is ungetc in C. But I don't think this is very important, because you can build your own functions for simulating it, if you really need it. But if you use e.g. flex and yacc for parsing, this is all handled for you by the parser generator anyway.
--
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Excuse me, what century is this? I find it hard to believe people are still using the ISO straw man to knock Pascal. Who actually uses ISO standard Pascal for embedded systems?
The only "string support" C has is putting an extra null after the last quote character in the source code. The rest of the string operations are handled by (standardized) library calls.
Apart from the terminating null in constant strings, even FORTRAN IV would have a string support similar to C, but IMHO even Fortran77 has a better character string support than C on the language level.
While I like null terminated strings when programming in an assembly language, does it really belong to a high level language ?
That's certainly true about Ada, as far as I understand it (I haven't written much more than "Hello World" in Ada in practice, but I've read a fair bit about it). Ada (again, AFAIK) also has support for concepts such as tasks, locking, and atomic accesses which are important in embedded development - I'd be interested to hear how well these work in practice. I expect a lot will depend on the target-specific libraries for a given Ada port.
Fair enough. I'll settle for standard Pascal (even the ISO "extended Pascal") being unsuitable for low-level work, mainly because it is missing bitwise operations. Real-life Pascal compilers (which have bitwise operators) *are* suitable for low-level work.
Pascal was certainly designed with teaching very much in mind - and certainly low-level programming was not a design goal. But it was always intended to be practical for real software development. Some languages, such as Logo, are aimed purely at teaching - you use it to teach people about programming concepts, then use a "real" language later. Some languages, such as Pascal and Python (which is not very suitable for low-level embedded programming...), work well for both teaching and real-world programming. And some, such as C, work well for real-world programming but are unsuitable for teaching.
as a language by itself C has none. In combination with the standard libraries it has some good support for both null-terminated, and strings with a length stored separately. the latter requiring immanginative use of sscanf printf and the mem... functions :)
And you've gotta track the allocation of every byte... C is not a good language for pushing paragraphs around with as seeminly trivial operations often require careful thought lest they leak or become computationally over complex.
if you want to use the string as a buffer for binary data it's not useful, but for most other purposes it's just fine,
one good thing it does is force you to think about strings of unlimited size, on the other hand haveing an accepted limit imposed on you does make programming easier (at the cost of functionality at the end of the day)
One solution is to have a counter and a copy, when the hardware counter hits
0xc000. increment the counter when the counter hits 0x4000 copy the counter into the copy.
when you detect an event, if the high bit is set use the copy for the high word of the result, if it's clear use the counter. either way you have about 16000 cyctles to respond to each interrupt.
if you can have output match (or some other interrupt you can use) it just needs immagination. the 0xc000 and 0x4000 figures above don't even need timing precision to one significant figure.
That convention is usable only with character representations like ASCII/ISO-646/ISO-8859-x/UTF8, but not with 6 bit characters on 36 bit mainframes (OK, the requirement for 8 bit byte addressability would make that useless anyway :-) nor in systems using UCS-2/UTF16 or UTF32 character representations.
It is interesting to see the shell-shocked stare when I unexpectedly appear right in front of them :-)
I updated the presentation some time ago, and used a 1 year old version as a basis. Just for fun, I check what had been accomplished in this year, and about 50% of the items on my wish list were either implemented, or they wer scheduled to be implemented in the future, which is a pretty good track record for the product line.
--
--
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
I realized this as well, and sent another mail illustrating the solution.
Event system will take one clock to update a timer. Max time for an events is 2 clocks. The capture for the upper 16 bits are delayed by one clock, so that they are always in sync.
If you get a capture event at (3); then the lower counter is 0000 and the upper counter is 0003, but since you delay the capture by one clock, the capture register will be written with the high counter value 0004 in (4)
No, you can drive outputs at 4 x, but not sample outputs at 4x as I interpret the documentation.
--
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
I've always thought that Ada looked like a pretty good embedded programming language (which is, after all, what it was intended for). However, my one experience with Ada for an embedded system was so incredibly awful that I still have nightmares about it. It was under VAX/VMS, and you couldn't just do cross-development like you could with other languages (using normal files, standard text editors, source control, etc.).
You had to log into some horrible stand-alone Ada shell database environment torture chamber. You couldn't use your normal programming editor or source control or build/documentation tools. Just copying an external source file into or out of the Ada development environment/database was painful. I thought moving from Unix to VMS was bad, but the Ada development environment was worse than programming using an ASR-33 and paper tape. At least with paper tape, you got all the fun paper dots to play with (though the big oil stains that the reels of tape left everywhere were unpleasant).
I don't remember much about the Ada environment other than it was something either the DoD or the Navy wanted to torture people with.
--
Grant Edwards grante Yow! What GOOD is a
at CARDBOARD suitcase ANYWAY?
visi.com
It's a matter of anything is better than nothing. I dislike the need to repeatedly scan for the end of a C string, but it works. Some of the C string functions return unuseful values, but they are useful nevertheless.
Ulf Samuelsson wrote: "Jim Granville" skrev i meddelandet
Sounds good. Would simply moving to 32 bit registers not be less silicon than all the event logic ? (ignoring the other benefits of event logic, for a moment)
.. this can be something else to add to your list ;) ? (Oh, and add having a simple queue/buffer to capture registers, to allow very narrow pulse measurement.
So do the pins sample at the CPU speed, which places another restriction on the designer ?
Since the silicon can go >> 100MHz, it's not sensible to limit timers on frequency or time measurements to something much lower.
The ideal here is 100MHz Frequency or 10ns edge precisions, with a core ticking over at 1MHz, or even slower...
I was lucky enough to only use the language but not the environment you describe. I used the Verdix Ada compiler on BSD 4.2 on a VAX, and the only real problem with it was that we had too many developers sharing a VAX 11/780 with insufficient memory. The Ada compiler did require more memory than the C compiler, but I think our machine was underpowered even for C development. Eventually we did add a second megabyte of RAM, which helped a lot.
These days a lot of Ada development is done using GCC Ada (GNAT), which doesn't require any special environment.
If Pascal isn't defined by the ISO standard, where is it defined? It's obviously not defined by any particular implementation, since no two are alike.
Actually I like Pascal just fine. I've done a lot of work in various nonstandard extensions of Pascal, including UCSD Pascal, Turbo Pascal, and Apple's MPW Pascal.
Would I say that "Turbo Pascal" (or Delphi) is suitable for low level programming? Yes.
Would I say that Pascal is suitable for low level programming? No. It's not possible to write any reasonable low-level program in a nonstandard extended Pascal and expect it to compile and run with any other Pascal implementation.
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.