Microchip & OnSemi want to buy Atmel?

It's only useful as a "real working language" for a somewhat limited problem domain, because of the limitations of the language definition. The various non-standard extensions address those limitations, but when you're using them you aren't really programming in Pascal.

If you are going to asser that the Pascal language was *designed* to be useful as a real working language, I'd very much like to see an authoritative reference supporting that claim.

Eric

Reply to
Eric Smith
Loading thread data ...

... snip ...

Scud came close, Turbo failed, and I don't know about Apple, to meeting the ISO standard. Scud failed in other respects IMO. I started in 1975 or 6 with the P4 compiler, developed it into a full standard complying system (the standard was developing at the same time) which ran on micros or main-frames. My systems could generate either P-code for interpreters or machine code for the machines. Apart from some horrible accidents almost 10 years ago (lost everything) it would be public domain now.

--
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: 
 Click to see the full signature
Reply to
CBFalconer

When I program embedded microcontrollers in C, I use extensions for interrupt handling, inline assembly, flash data (on Harvard architecture micros), and other target-specific features. Does that mean that I'm not programming in C, or that C is not suitable for low-level programming because the standards don't include such features? Can you give me an example of *any* programming language where existing compilers slavishly follow the language's standards, implementing everything and adding nothing? Real-life, non-academic programming is done using a mixture standards language and implemented language.

I agree that the lack of bitwise operators in the standards is an issue for programming (not just low-level stuff, but it's perhaps more immediately obvious there) - I hadn't noticed the lack because practical Pascal systems support it.

I don't have any history books on hand. But Niklaus Wirth developed a fair number of programming languages - they were not made just for fun, even though their success in large-scale usage varies.

Reply to
David Brown

The Pascal derived language Modula2 was a lot more suited to low level tasks with its native BITSET type and SET. Most of the embedded Pascal compilers I ever used did offer packed array of boolean as a native type even if the strict language standard did not. Yes there were portablity issues but most of the embedded apps were designed around very specific hardware so this was seldom an issue (unless the CPU went obsolete).

The answers to your question in Modula2 (which for a while at least was a language of choine for some embedded high rel kit).

INCL( BITSET(some_integer), 5);

and

Result := INTEGER(BITSET(var1) * BITSET(var2));

The modern ISO standard Modula 2 (as opposed to PIM3 above) now distinguishes between VAL(TYPE, variable) and CAST(TYPE, variable). I don't like the new syntactic sugar at all. The ISO 10514-1 standard is not free access but a porting guide for one compiler gives enough detail

formatting link

formatting link

The one big thing I think they missed in ISO M2 was not permitting procedure declarations which allowed call by reference for large structured objects but enforces a CONST property upon them. That way you get the speed of call by ref for large structures and a programmer making changes in the routine cannot corrupt the outside world.

The seriously device dependent bits of Modula2 implementations are in SYSTEM.

formatting link

I don't see how you can beat compiling to a single instruction a la M2.

Quite a lot of real world pascal compilers had extensions that allowed them to work very well in an embedded environment. TI9900 series machines had a pretty good implementation very early on.

Ada is a bit too big and uwieldly. There are high integrity subsets selected by the likes of John Barnes at Praxis.

Regards, Martin Brown

** Posted from
formatting link
**
Reply to
Martin Brown

Provided that the order of the bits in a packed set is well defined they are the same thing. Is that the case in modern ISO std Pascal?

The problem that C programmers seem to have with other languages is they tend to treat integers as their base type. And believe that terse cryptic code is faster.

I can't answer for Pascal but for M2 it would look very like:

EXCL(Timer1, InterruptFlag)

I'd expect it to compile on a PIC to BCF Timer1, InterruptFlag (I don't know if there are any M2 implementations for PIC)

And it would compile to a single instruction assuming that the underlying CPU had the capability to alter a single bit in a register. You can write efficient interrupt handlers in this language with relative ease.

Regards, Martin Brown

** Posted from
formatting link
**
Reply to
Martin Brown

it has strings, and what else? "with"

can it create arrays of a size determined at run-time? (can it?) haw about variadic functions (I don't think it has them)

uudecode is a relatively low-level process, for every 4 pack the least significant 6 bits of each toegther to make

3 bytes, how would you write that in pascal.

(I can see two ways to do it in C, one of them exposes no arithmetic but is non-portable but that could probably be solved with a #define if portability is an issue)

well for the most part that's true, the few things that are more useful for pascal or more useful for C aren't extremely exciting or a great hardship if they aren't available.

I've not looked closely at this, but I think for most 8-bit expressions things can be written to use only 8 bits

ms-dos has signs of being written in pascal, why didn't pascal take off?

Bye. Jasen

Reply to
Jasen Betts

32 bit PWM with a 16 bit timer. CompareC = Top. reaching Top will reset counter to 0. CompareA = Toggle

Case 1: Period is less than 65536 cycles: Obvious implementation

Case 2: Period is 65537 cycles. Dutycycle = 1 Set CompareC to 32768 Set CompareA to 1 & Toggle I/O Interrupt on Compare A Set CompareA to not toggle I/O Interrupt on CompareC (reset counter) Set CompareC to 32769. Interrupt on CompareA Set CompareA to toggle.

Case 3: Period is 65537 cycles. Dutycycle = 65536 Set CompareC to 32768 Set CompareA to not toggle I/O Interrupt on CompareC Set CompareC to 32769 Set CompareA to 32768 & Toggle I/O Interrupt on CompareC Set CompareC to 32768 Set CompareA to not toggle I/O etc.

Case 4: Period is 65537 cycles. Dutycycle = 32768 Set CompareC to 16384 etc...

Interrupt on Timer wraparound (Higher Interrupt priority than Capture) Timer = Timer + 1

Interrupt on Capture Capture[15:0] = H/W Timer Capture[31:16] = S/W Timer

If you cannot prioritize interrupts, then there would be a problem.

They are, but it is done according to priority, and nitty gritty details tend to get less attention than adding complete blocks. The XMEGA project was a result of collecting customer feedback for several years and I think the result is quite good.

True, I do hamper a lot about timers internally... Keep a presentation on what to improve on peripherals which I provide to the MCU product lines. This is now ~150 pages, and a significant part is on timers.

The AT90PWM circuits will add 4 bit of resolution to the timer which runs from a 64 MHz PLL.

Look in the Users Manual.

The XMEGA has an event system, that will allow you to generate a 32 bit timer. The upper 16 bit timer will be clocked by an event coming from the lower 16 bit timer. IIRC, The hispeed will work in PWM mode only, but you can use the timer as a

32 bit Capture timer at 32 MHz.

The XMEGA does not have the AMBA bus, but Atmel has already said that the UC3C will use some of the ideas from XMEGA. The contents of other circuits are yet to be revealed.

Challenges are always nice!

--
-- 
Best Regards,
 Click to see the full signature
Reply to
Ulf Samuelsson

Same here. I worked on real-time embedded systems in Pascal (including an RTOS kernel). With a few minimal extensions Pascal was a great language in which to do low-level embedded systems. Unfortunately, Pascal died off, and now I use C _with_a_few_minimal_extensions_ for such applications.

It seemed to me that the Modula family of languages would be even better for embedded work, but they never became popular.

--
Grant
Reply to
Grant Edwards

It did. TurboPascal was a huge success. Back in the CP/M days (DOS was a copy of CP/M), Pascal was pretty much _the_ programming language (besides assembly) for micro-computers.

When I was in school in the early 80's and it came time to do high-level programming on a micro-processor, we used Pascal and HP in-circuit emulators. At my first job in 1983, I wrote cellular telephone firmware in Pascal.

At my second job I wrote firmware in C and data-analysis programs in Pascal.

At my third job, it was just C.

Pascal did "take off" -- then it landed.

--
Grant
Reply to
Grant Edwards

I'm a Pascal to C convert. I have to admit, C does have its strong points over Pascal, but it is also quite easy to...how shall I put this...totally *f*ck* something up if you are not paying attention. At least in Pascal, if you tried to do something weird, the compiler would flip you the finger. A C compiler just assumes that you know what you are doing. I have found in some cases, it assumes wrong and you won't know it until your program blows up. With all the different compilers out there, I have found that gcc holds its own quite well. And unless you are programming for Microsoft, gcc is one of the defacto standard compilers out there.

I've been programming in C for Unix for some time now. I have looked at Unix kernel code. Most of it is written in C. Although there's a few pieces that are written in assembly for the particular platform that it is targeted for. It is mainly for direct processor control to perform tasks that would be very difficult if not impossible to code in C. Direct register access comes to mind.

Japanese is alphabetized. There are in fact *TWO* alphabets (They call them kanna), and the Chinese characters that they ripped off are called Kanji. The problem is that all three are interdispersed in the writing.

--
Daniel Rudy

Email address has been base64 encoded to reduce spam
 Click to see the full signature
Reply to
Daniel Rudy

I think the following should do it:

U16 TimerHigh;

union { struct { U16 low; U16 high; } x; U32 timer; } event;

interrupt Capture(void) { event.x.low = TIMER.CAPTURE; event.x.high = TimerHigh; if(event.low & 0x8000) { // Capture occured under second half of period if((TIMER.COUNTER & 0x8000) == 0) { // Timer interrupt has occured event.high = TimerHigh - 1; } } }

interrupt WrapAround(void) { TimerHigh++; }

--
Best Regards,
Ulf Samuelsson
 Click to see the full signature
Reply to
Ulf Samuelsson

"with" is very useful - it can make some kinds of code a lot clearer, and it is easy for the compiler to optimise it (for example, if you have a "with" block on a record in an array indexed by a global, the compiler can easily use a pointer for all the accesses. Without "with", a C compiler may have to be conservative and re-calculate the pointer).

Yes, and you can also get the size of arrays passed to functions (arrays are a different type from pointers).

I don't know - why would you want variadic functions in a strongly typed and strongly structured language?

Higher level concepts that Pascal has are proper enumerated types, integer range types (both of which give much better compile-time checking), and local procedures and functions (which improve modularity and structure).

Sets are another very useful higher level concept.

Pascal also has proper modules with separate interface and implementation sections (though not as good as Modula-2, which has them in separate files). Of course, header files can give a similar effect in C - *if* they are properly used (too much flexibility is a bad thing sometimes).

Depending on the version of Pascal (standard, extended standard, or commonly-used non-standard extensions such as Borland's Pascal or gpc), you also have features such as overloading, classes, exceptions, etc., somewhat similar to C++ (which is also higher level than C).

Again, this is as easy as C if you have the very common but non-standard bitwise operators ("and", "or", and shift operators).

When I've been working with Delphi for a while, and go back to C programming, I find I miss the better type support (enumerated types, subranges, and sets) most.

You can't - C requires that all arithmetic on 8-bit expressions is promoted to "int". This includes switches, and even "if (x) ... " statements. A good 8-bit embedded C compiler will hide most of the effects and through away the top half of these calculations, but it will not always be optimal.

Reply to
David Brown

The designers must love to see you coming with your punch list! They probably also love you hampering[sic] about timers...

Reply to
Everett M. Greene

What string support does Pascal have? Lack of a string type is a major deficiency (of the original standard Pascal).

Reply to
Everett M. Greene

Imagine you get a capture edge, on what should be 5FFFF. (or even close to that) During the Capture INT propogation delays, the timer ticks over and fires its int, which now takes priority, and when the capture Sw finally gets to Capture[31:16] it gets 6FFFF as the answer.

Now do you see the aperture problem ?

Capture is one of those things that really needs hardware.

Good, looks like that just got some more content ;)

What propogation delay does this have ? is this aperture free ? (or at least aperture locked, so I guess a SW patch could apply to fix a known fixed phase error)

All the data says is HiResolution mode exists, but does NOT say what happens to the pin sampling, or if that is CPU or Timer clocked.

Can the pins sample faster than the CPU clock (ideally, at the x4 clock?)

-jg

Reply to
Jim Granville

Yes, that's getting closer. This code requires that you can read the running-flat-out timer, which places restrictions on the Core:Timer clocks, and it is becoming less preferred, and certainly less portable even across chip revisions.

eg This from one 32bit uC data sheet, I have open : "Timer counter. It is advisable not to access this register, which may change very rapidly"

It has also increased the minimum pulse width that can be handled

Have you noticed how even someone as experienced as yourself missed this on the first pass ?

Now, imagine the more average 32-bit user trying to do this, (maybe they code this ?)

interrupt Capture(void) { event.x.low = TIMER.CAPTURE; event.x.high = TimerHigh; if(event.low & 0x8000) { if((TIMER.COUNTER & 0x8000) == 0) { event.x.high-- } } }

and you can appreciate why 32 bit timers are a good idea :)

-jg

Reply to
Jim Granville

Take a look at Ada. Since it is now a member of the gcc family, it is available wherever gcc has been ported. It also has a proper standard, and is a descendent of Pascal and Modula.

Please don't remove attribution lines for any material you quote. I have restored them above, hopefully correctly.

--
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: 
 Click to see the full signature
Reply to
CBFalconer

The bare C language may not provide all of those convenience features, but none of them is actually necessary for embedded programming. I've done plenty of embedded work with bare C. Inline assembly is nice but certainly not necessary, and you can do interrupt linkage in assembly if need be without substantially detracting from what you can do in the C code. Assigning address spaces for various things is nice, but can be done in linker scripts.

If those kinds of things were the only problems with trying to use Pascal for embedded development, I'd say it was fine. But Pascal's shortcomings are far more significant.

I don't care whether compilers add additional features; you can use them or not. But if getting your work done REQUIRES you to use the nonstandard features, then claiming that the language is adequate is clearly wrong.

Many Ada compilers are fully compliant with the standard, though they may also offer extensions. Ada with the admittedly optional representation specs is perfectly well suited to embedded programming, without needing any non-standard extensions. Arguably it is a more suitable language than C, since C still leaves many important things as implementation-defined.

Sure. But then it isn't "Pascal", it's "someone's nonstandard language based on Pascal", so you can't use it to claim that Pascal is suitable for low-level programming.

If the claim was that brand XYZ "Extended Pascal" is suitable for low-level programming, I'd have no argument.

I don't claim that any of them were "made just for fun". I also don't claim that none of Wirth's languages are suitable for low-level programming. I only claim that Pascal is not suitable for low-level programming, and that it was designed as a teaching language. I doubt that Wirth himself would disagree.

Don't get me wrong, I think there is plenty wrong with C too. But C is useful for some problem domains for which Pascal is not.

Eric

Reply to
Eric Smith

Agreed. Modula-3 looks particularly attractive for embedded systems requiring multitasking.

Alas.

Reply to
Eric Smith

I agree that Modula 2 (and Modula 3) are much better suited for low-level work than Pascal.

That claim is widespread but AFAICT completely unsubstantiated. Back in

1983 Ada was pushing the limits of available compiler technology, but that hasn't been true for many years now.

Note that many embedded systems are programmed in C++ now, and that C++ is actually a bigger, more complex language than Ada. Many of the features of C++ appear to have been inspired by Ada, but the size and complexity of C++ has grown much more rapidly than Ada has.

You won't get any argument from me that there are some Ada features that one can reasonably choose to do without. The SPARK annotations are also quite useful.

Reply to
Eric Smith

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.