Hi, All,
decided to put this as a new topic, since sometimes even three USART's aren't enough.. ;-)
Since I got this running very well at my LCD, feel free to use the code linked here:
- so this is more an answer than a question here,
have fun using it!
gbulmer
Moderator
HDS - very interesting! Effectively using a timer as a 'baud rate generator'.
A small comment, the code:
if (bitRead(LCDoutbuf[LCDreadPt],LCDbitcnt)==1){
digitalWrite(LCDtransmitPin,HIGH); // send 1
}
else{
digitalWrite(LCDtransmitPin,LOW); // send 0
}could be simplified to digitalWrite(LCDtransmitPin, bitRead(LCDoutbuf[LCDreadPt],LCDbitcnt) ); because the value of the bit in the character is the value of the output pin (and lots of room for optimisation, if it ever becomes an issue :-)
Maybe consider these suggestions:
1 Change
void LCDnextBit(){
switch(LCDbitcnt){to:
void LCDnextBit(){
if (LCDreadPt == LCDwritePt) return;
switch(LCDbitcnt){As there is no work to do if there are no characters in the buffer to process, so this seems clear.
2. If you implement 1, then the value of LCDbitcnt can be used to exactly represent the state of the state machine (implemented in the switch statement) which is working through the start-bits, character and stop bits, and so case 9: could become:
case 9: // Finished this character ...
if (LCDreadPt==127){LCDreadPt=0;} // get to next character position
else {LCDreadPt++;} //if 127, reset to zero
LCDbitcnt = -1; //send start bit on next timerwhich I think might be a little bit clearer.
Just my $0.02 worth
Hi, gbulmer,
thanks for your commentary and suggests.
for your first suggestion:
replacement
if (bitRead(LCDoutbuf[LCDreadPt],LCDbitcnt)==1){
digitalWrite(LCDtransmitPin,HIGH); // send 1
}
else{
digitalWrite(LCDtransmitPin,LOW); // send 0
}by
digitalWrite(LCDtransmitPin, bitRead(LCDoutbuf[LCDreadPt],LCDbitcnt) );
would latter really generate faster code? Definitely your suggestion shortens the source! But: On the embedded system, I always try to avoid too many nested function calls, after reading in the docs that some (wiring?) functions are not tolerating for instance compound operators inside the function call parameter list... ;-)
Your second suggestion even saves a few cycles more in average, because "nothing to be sent in buffer" situation will be more often than the opposite - something to be sent there.
But, compared to a software serial with "delay(bitPeriod)" baud rate generation, both variants behave exactly the same: Much more time for the mic to do other things than delaying for sending the separate bits.
Btw: I stressed the timer software serial construction a bit, by having the other 4 serials (including non-answering SerialUSB) a dense traffic, but the LCD received what it should have received. Over hours.
To me it seems, that having in fact a second stop bit in the communication (case bitcnt=9), prevents any relevant jitter in the timer (ok, 26 µsec per Bit @38600 is a long time...)
gbulmer
Moderator
HDS -
would latter really generate faster code?
I would expect so. A very clever compiler might spot the optimisation, but I would be impressed if it did. I'd have to dump the assembler for both versions to be sure.
Definitely your suggestion shortens the source! But: On the embedded system, I always try to avoid too many nested function calls, after reading in the docs that some (wiring?) functions are not tolerating for instance compound operators inside the function call parameter list... ;-)
Where did you read that?
I believe that some PIC microcontrollers have limited stack, so I can imagine there being some caution caused by that.
Do you mean ... ?... : ... as a compound operator?
bitRead is ((... >> ...) & 1) so not a complex expression. It returns 0 or 1, which is HIGH or LOW, so no conditional code is needed.
The ARM Cortex-M3 on Maple is a very powerful processor, and it is only limited by available RAM. Maple has 20KB so it won't cause any constraints. The compiler is gcc, and it is very solid too. So I can't think of any cause of any limitations other than RAM, so nothing to worry about here.
(I'd expect ((... >> ...) & ...) to be executed in registers anyway, so even less of a constraint).
The real optimisation would be converting it to a bit band write, for pin 14, which is Port B, pin 8 according to http://leaflabs.com/docs/hardware/maple.html#master-pin-map
That would be something like:
bb_peri_set_bit(&(GPIOB_BASE->ODR), 8, bitRead(LCDoutbuf[LCDreadPt],LCDbitcnt) );
which would be about as fast as it could go.
This would be about the same amount of code as just the *call* of digitalWrite, and this would be everything; digitalWrite would still need to do its stuff.
Converting:
digitalWrite(LCDtransmitPin, LOW);
to
bb_peri_set_bit(&(GPIOB_BASE->ODR), 8, LOW );
and converting:
digitalWrite(LCDtransmitPin, HIGH);
to
bb_peri_set_bit(&(GPIOB_BASE->ODR), 8, HIGH );
would complete the transformation.
I would not recommend it because it is a bit opaque, and changing the pin would be more complex than your current code. I mention it to illustrate what a further optimisation might look like.
(I might wrap bb_peri_set_bit(&(GPIOB_BASE->ODR), 8, ...) up in a macro or inline function if I were going to do it for real.)
Yes, the second suggestion saves cycles, but I feel the logic is clearer. That clarity might be helpful at some other stage. For example, if there were more than one 'soft serial' output, the bit handling state machine could be factored out for each. So that would be an easy enhancement. Or, if the overhead of the interrupt call became an issue (maybe if it were running at a megabit/second), then it would be easier to see where to disable and enable the timer interrupt. (An interrupt takes 24 cycles to call and return, so at a high bit rate, disabling the interrupt when it isn't needed might be helpful).
To me it seems, that having in fact a second stop bit in the communication (case bitcnt=9), prevents any relevant jitter in the timer (ok, 26 µsec per Bit @38600 is a long time...)
I don't understand. The LCD spec should say how many start, stop and parity bits it requires. I can believe an extra stop bit does no harm, and might help if the LDC-side is having problems keeping up.
Jitter of the output data will be caused by servicing other interrupts. There can't be any jitter without other interrupts. So I think transmitting an extra stop bit needs to be balanced with the amount of time spent transmitting stuff. There will be other interrupts competing for CPU time, so using the minimum of CPU time to transmit data seems like a good tactic. Transmitting an extra stop bit actually has the CPU spend slightly more time in the interrupt service code (and digitalWrite is quite slow).
Anyway, thank you for publishing. Your code is straightforward and clear, and a pleasure to read.
(full disclosure: I am not a member of LeafLabs staff)
gbulmer, thanks again for the extended commentary.
Try to answer here Questions from your long post:
A) Function not compatible with Compund operator inside function parameter list:
abs()
http://leaflabs.com/docs/lang/api/abs.html#lang-abs
B) compound operators, other operators and their priority:
http://de.wikibooks.org/wiki/C-Programmierung:_Liste_der_Operatoren_nach_Priorit%C3%A4t
(sorry that in german language - you will understand it anyway..., am sure this exists in english also)
The optimizations you put in here (GPIO usage) have been already discussed in a thread in this forum thread
http://forums.leaflabs.com/topic.php?id=1133
C) Yes, the Sparkfun LCD side is having problems.... ;-) (Sparkfun 4x20 Chars LCD ver 2.5 with a pic as mic)
D) "clearly readible code" : thanks for your compliment - I have to deal with and to support, debug and maintain software packages with 130.000+ lines of source code. Definitely such huge things can't be made working easily in C / C++, if you are honest. I'm rather from the Delphi/Pascal side of the table - the older ones of the two languages. No, the Richie/Kernignham C-Compiler (including all derivates as C# and C++) with all its pitfalls, if's, operator positionning issues, brackets and undefined and compiler -version -switches -preprocessor -manufacturer specific treatement of expressions like:
i = 3;
a = i + i++;What's the value of a after?
i will definitely be 4.
- with its possibly(C++) from time to time available garbage collector, with its obfustication possibilities, its unsecured typecasts, its lacking compiler native string support (try to enlarge a char[15] by char[20], you finally end up in adressing a completely new array[35]... which means memory management lacking features...)
no, guys, c, c++, c# have never been the compilers and languages of preference if I had any choice. ;-) And within the time these fk'n few 1300 lines of code compile with the Leaf Maple IDE and the gcc compiler behind, the 130.000 lines Pascal/Delphi code are compiled and made with Delphi more than 5 times into an executable.
There even are roumours, that C, as a successor of B, an extended assembler language, has been invented only (in the times Algol and Pascal have been introduced for years) to give the US an advantage towards the russians in the times of cold war:
By slowing down software development.
The roumours are supported by the fact, that the UNIX made at Bell laboratories was given away for free, accompagnied by the C-Compiler written in very short time by Richie and Kerningham. All over the world, the free UNIX with C as compiler spreaded, in the universities, especially in the countries of former UDSSR.
Drawback: we nowdays have C re-introduced here....
(Despite much more elaborated and precise programming tools available)
Ok, back to topic: Here we are in C. And close to the machine we program...
E) Jitter avoidance/extra-Stopbit: My idea was, if there are other interrupts jittering the timer during a byte transmission, with an extra stopbit we assure the receiver of the serial transmission to be "fresh-and-long-enough-on-high" when the next byte transmission from our side starts.
And yes: The Sparkfun v2.5 LCD 4x20 serial display side has harms keeping up. That's why the Arduino guys finnally found someone who wrote a library for that LCD with a lot of delay() functions in it...
stay tuned - myself have great fun following your posts.
HDS
gbulmer
Moderator
HDS -
Function not compatible with Compund operator inside function parameter list:
abs()
http://leaflabs.com/docs/lang/api/abs.html#lang-abs
Okay, I understand the issue.
abs() is a macro (defined in wirish_math.h) and not a function call:
#define abs(x) (((x) > 0) ? (x) : -(x))
so if an operator has a side effect, as in ++, --, or any of the shortcut 'op=' compound assignment operators, it gets applied twice. So:
int a = 0;
// ...
int b = abs(a++);
// expands to: int b = (((a++) > 0) ? (a++) : -(a++))
// so a is now 2, not 1, which it would be if abs were a function,
// and b is -1 !!B) It isn't just the compound assignment operators, it is also ++ and -- which have a side effect, which matters to the abs macro.
(I had thought you might be talking about the (quite exotic) compound statement:
http://gcc.gnu.org/onlinedocs/gcc/Statement-Exprs.html#Statement-Exprs
which confused me).
Yes, I have contributed to several threads on optimisation for I/O.
(I did consider doing serial I/O using DMA, but I don't need it, and life is too short :-)
C) Okay, if the LCD is having problems keeping up, by all means go a bit slower
D) IMHO, the killer wasn't a = i + i++;, it was f(i++, i++); :-)
E) As I wrote, IMHO the extra stop bit shouldn't do any harm.
My concern is getting jitter in the individual bit data. I was less worried about the overall time for the byte. If an output bit is jittered a lot (I accept 26usec would be a lot) by another interrupt routine running at a higher priority, the result might be a data bit which lasts so little time that the receiver doesn't receive it correctly.
So then my thought was that it is better to be sending fewer data bits, as the odds should be better. Not deep, just a thought.
If the LCD is having problems keeping up with the data rate, you could generate a longer stop bit, without extra interrupts, by increasing the timer count value on bit 8, and resetting it on bit 9. According to my reasoning, this would be no worse, because there are no extra interrupts, and according to your logic, it would improve the chances of the LCD having enough processing time. But it is ugly :-(
gbulmer
Moderator
HDS -
There even are roumours, that C, as a successor of B, an extended assembler language, has been invented only (in the times Algol and Pascal have been introduced for years) ) to give the US an advantage towards the russians in the times of cold war:
By slowing down software development.
:-)
Pascal didn't really come before C. At best they were concurrent developments.
I believe export of UNIX to Russia was not allowed during the cold war.
So I can't imagine that the US would have derived any advantage from C and UNIX unless it was a superior technology.
Algol was so badly standardised FOR IMPLEMENTORS and USERS that it didn't have I/O (it was standardised for algorithms)
Algol was great for publishing algorithms in journals, but had to be reworked extensively to be capable of writing operating systems.
Nicklaus Wirth's programming language Pascal was designed for teaching. It had to be reworked in UCSD Pascal and Borland Pascal to make it a language which could be used to write systems programs. UCSD was quite slow, because it used an interpreter (actually a VM).
Borland Pascal only became available on anything other than Windows quite recently. So that doesn't really compare with the 'shape' of C's spread to different uses.
IIRC, Borland added some of the 'unsafe' mechanisms of C so that it could be used for system software, and hence is not Standard Pascal. To make it work well, I believe Borland Pascal was written in assembler; IMHO, if that is true it is a poor recommendation for the language (http://en.wikipedia.org/wiki/Pascal_(programming_language)
Other than UNIX's Pascal, implementations were proprietary or for proprietary hardware.
I used Pascal on two mainframes, PDP-11, VAX, Intel-based PC's, Apple III, and Sequent. Strings were often crap, at a maximum of 255 characters. I/O was not portable or clunky. System access was not portable or sometimes inadequately supported. Sets were so badly defined that one couldn't be sure they would work for low-level hardware access, but they were the way to do 'bit operations'.
IMHO compared to C, and C's integration into the operating system, most Pascals was too clunky to want to use for systems software. AFAIK, only UCSD and Apple Lisa used Pascal as the OS programming language. Apple abandoned Pascal when they did Mac.
Modula 2 was Worth's 'operating system' language. I used several Modula 2 systems. I thought it was much better than Pascal. IIRC, it was a bit of a task to interface Modula 2 to some hardware, but that might have been the fault of the 8086. I did that stuff more than 20 years ago, and my memory and floppy disks are fading. Then Wirth did Oberon which was used to write an OS, but IMHO too little too late.
IMHO Tanenbaum's Minix book was more influential than Pascal/Modula 2/Oberon.
Ada was so much better than Modula 2 in terms of data types, type safety, modularity, multi-processing, exceptions, that I used it. We had a Sequent, which was the best Ada development machine money could buy.
C was still more fun.
The roumours are supported by the fact, ...
No, I don't think those rumours are supported by any facts. IMHO, that is just a conspiracy theory.
There is rarely any need for a conspiracy theory when human greed and stupidity are more than sufficient.
AT&T could only distribute UNIX for free because of US anti-trust laws.
So it was one of the few (only?) low-cost real (multi-user, multi-process) portable operating systems available. So it was a perfect platform for research, so lots of students learned to use it. Then it became the basis for new entrants into the hardware market (which was extremely profitable in the late 70's/early 80's).
IMHO, it wasn't that you could not write an OS in a modified version of Pascal, it was that all the OS's in Pascal were not adequate to the requirements. They were single user systems, and were already doomed to die by MS-DOS and MS.
On the other hand, C and UNIX was implemented on multiple different processors (PDP-11, INTERDATA and VAX) relatively early on. C and UNIX had mechanisms to support program porting (e.g. the pre-processor and lint). C was used to write a working operating system which ran on multiple platforms. This allowed hardware vendors to enter the mini-computer/workstation/server market, and to innovate without the enormous start-up cost of building an operating system and tools. Neither Pascal or Algol were able to do this. Though there were operating systems written in (incompatible) dialects of Algol, AFAIK, they were ever made available in a convenient form to students, researchers and hardware startups.
Summary: AFAIK, there are no widely used modern operating systems written in Pascal or Algol (UCSD, Burroughs now UNIVAC, and ICL are not mainstream).
They are all written in C/C++.
Pascal and Algol are not widely used to write compilers and VM's for other languages.
Language compilers and interpreters are either 'self-hosting', or written in C /C++.
In the 80's, most people wanted to use the language the Operating System was written in, or something better because they didn't want to write assembler ;-)
Hi, gBulmer
You definitely are not a member of leaflabs staff, but I'm quite sure, you are one of the main mentors.
Thanks for the detailed and long 'seemingly' clearification, but - concerning a comparision of C with other languages, the history of it, the time of appearance - with a little google help translated from german to english language, maybe you find the time to read this:
http://www.bernd-leitenberger.de/pascal-und-c.shtml
Leitenberger quotes from an article of one of the developers of C, Kerningham: "C is not my preferred language"
Pascal has been developed from 1968-1972 by Wirth. The book from Richie and Kerningham "programming in C " appeared as late as 1978.
If you see it not from an academical point of view, but from a time-to-market point of view, C is only useful for programming operating systems, not more, not less.
The developement speed within large software projects - and I do not speak theoretically - in C or C++, C# simply is at maximum a quarter compared to languages as Pascal/Delphi, Ruby, Java, Ada.
- As long as you aren't aiming to build an operating system. Or a device driver.
Failure free large application development with a graphical user interface, taking into account sophisticated data structures and algorithms, easy string handling, secure data types which have not been present in C /C++ for decades - is from the point of view of a meanwhile over 25 years active developer impossible with C or C++.
The object oriented programming has been introduced with Borland Pascal 5.0 as early as 1991 - when I started to use those concepts. When did C++ appear???
For the microcontroller platform, on which we meet here, C, C++ is more than ok. Nothing else would fit better... (We have to deal with at max 20k source lines.) ;-)
HDS
gbulmer
Moderator
HDS - I stand corrected.
I can't find my copy of Jensen and Wirth "Pascal User manual and Report", but I had thought it dated the language as '76. I was wrong, Amazon.com says it was 1974. So yes, Pascal predated C. C took inspiration from BCPL, which was simplified CPL.
The 7th Edition of UNIX was described in the Bell System (AT&T) Technical Journal 57, July-August 1978
There had been 6 earlier editions, and I know that Edition 6 was written in C because I read the source along with John Lyons commentary http://www.amazon.com/Lions-Commentary-Unix-John/dp/1573980137
I read Kernighan's "Why Pascal is not my favourite language" in the '80's and it's criticism of Standard Pascal still seems reasonable and valid: http://www.cs.virginia.edu/~cs655/readings/bwk-on-pascal.html
Of course, Turbo Pascal and hence Delphi are very different languages from Standard Pascal, and people should not be confused about this. Turbo Pascal is more different from Standard Pascal than Java is from C#.
I skimmed the document you refer to http://www.bernd-leitenberger.de/pascal-und-c.shtml
i.e. http://translate.google.com/translate?sl=auto&tl=en&js=n&prev=_t&hl=en&ie=UTF-8&layout=2&eotf=1&u=http%3A%2F%2Fwww.bernd-leitenberger.de%2Fpascal-und-c.shtml
I can sympathise with some of the authors views, but IMHO, it fundamentally misses the point.
Also it appears to contain factual inaccuracies. The author appears to misunderstand the do { ... } while (), or maybe think it is somehow "wrong", but I think it is symmetric with two valid approaches.
The author creates awful, buggy, code to do simple things (e.g. to convert a string to upper case - StringToUpper). It appears the author tried to use C to do Pascal, which is not a reasonable comparison. It is no more valid than trying to write FORTRAN programs in Pascal. The author doesn't like the C syntax and having lots of operators, but presumably likes, succ, pred and ord. IMHO, syntax becomes unimportant after the first month. So I can understand their taste, but IMHO there are more important issues. It is the model of computation that matters. I think I could rewrite the paper using Java as the better language, and Pascal as the inferior, and I would be more right. That still doesn't make it a good approach for comparison.
A quote: "Delphi can be used with relatively small adjustments on Linux, Windows and. NET. These are three totally different platforms,"
No, they are all x86 systems, Windows has a POSIX layer, and the Delphi developers can choose to wrap anything they like.
If that were written about x86, ARM, MIPS and maybe SPARC, on .NET, Linux, FreeRTOS and OS X/iOS, I'd be impressed.
Key things the author seems to miss from the comparison are tools (e.g. lint, prof, gprof, yacc, lex, CVS, and piles of other handy tools integrated by the shell), lots of libraries, and the on-line manual. It was an absolute joy to use C on UNIX because of its manual, tools and libraries. IMHO, it is utterly wrong to make *any* claims about productivity when you ignore the fact that one language was embedded in a proper development environment with powerful, flexible and extensible support, and the other had no proper separate compilation support, and such a badly specified system interface that it was unusable for anything that wasn't a sequential file in and out. A toy vs an ugly but effective workshop full of tools and materials.
Pascal was designed to be a small language to teach people (who do not yet know) how to program, and explore algorithms and data structures (hence Wirth's "Algorithms + Data structures = Programs", which I quite enjoyed at the time, and read in the launderette, but is such a narrow view of programming that I wouldn't recommend it anymore). It is testament to Wirth's design that Pascal got used for wider purposes, when Wirth himself had already moved on.
C was intended to write efficient operating systems, and system-level tools like compilers, editors, databases, windowing systems, system utilities, etc. and replace assembler. Which is exactly what it has been used for.
IMHO, it was not a time to market issue. They were designed for different audiences. The first proper language I was taught in my Computer Science degree was Pascal. It was great to learn about algorithms and data structures. That's what it was good for. C was so much better for writing useful programs that it was not a fair comparison then, and still isn't. I used to write C on our UNIX system, and recompile (using Lattice C) under MS-DOS. Not an option for Pascal because of the lack of system interface and libraries.
IMHO, comparing Pascal and C is as silly a comparison as a bicycle and a truck. People have irrational "wars" when the core use cases are not comparable. Yet, the evidence is clear. Even though Modula-2, Oberon and Ada were all "better Pascal's" comparable to C/C++, with a lot of money behind Ada (and I put quite a lot of effort into Modula-2 and Ada, so I would have been okay with them winning) yet C/C++ still won. Let's get over it, and move on.
FYI C# is Java, with two syntactic changes which created an incompatible language. I believe (from a personal friend who really knows this stuff) that in very early (pre-release versions) C# used the same DLL's as Java.
C++ was preceded by C with classes, which started in 1979. It became C++ in 1983. I believe my chum Mark Rafter had the first C++ compiler in Europe, when he got a tape created by Bjarne Stroustrup (Mark had been interested in C with classes). Mark taught me (and many, many others) C++ in the 80's. He represented the UK at ISO for C++ *standardisation*, maybe before Turbo Pascal 5. So I think Turbo Pascal 5 was quite late to the party.
AFAIK, there are libraries of secure datatypes in C++, and have been since the 90's (maybe even the 80's). If you don't want to use them for some reason, you have that choice. I'd be willing to consider using Cyclone http://cyclone.thelanguage.org:8181/
There were other very influential Object Orientated languages, like Simula 67 (1967), SmallTalk from 72 onwards, with the definitive system in 1980. There were Abstract Datatype focused languages, e.g. CLU (1974), Mesa (1970's) which inspired Green, which became Ada in 1983. Also ObjectiveC (still used on Mac) dates from the 80's. All predating Turbo Pascal 5 too.
There are far more interesting and productive ways to program than Pascal or its children.
For example Haskell for productivity, compactness, type safety, algorithmic expressiveness and power (they have even generated better code than the gnu C compiler). I suspect "bernd-leitenberger" wouldn't like Haskell because it uses lots of clever syntax and clever ideas like "Currying", side-effect-free lazy evaluation etc.
Or Erlang, where productivity and effectiveness over C++ has been documented on realistic (though still relatively small) applications, for systems which have down-times of sub-seconds in 10's of years.
Python-on-a-chip (PyMyte) fits on Maple, and gives a REPL interface.
The work of VPRI may get us to 10x more productive?
Anyway, we have C/C++, and I *MUCH* prefer them to assembler, and to *every* language that I can't actually use to program my system :-)
On a machine with 512KB flash, I'd hope to get more than 20k source lines. IIRC Edition 6 UNIX was about that size, and it ran in 128KB. I believe the Xerox Alto SmallTalk 80-based machine had a 16-bit address space (64KB) in which all code, including the OS ran.
You must log in to post.