Uncle Bernie's YAAK project ("Yet Another Apple Keyboard")

8 posts / 0 new
Last post
Offline
Last seen: 3 hours 29 min ago
Joined: Apr 1 2020 - 16:46
Posts: 1031
Uncle Bernie's YAAK project ("Yet Another Apple Keyboard")

 

 

 

This is yet another Apple keyboard project, with the primary mission objective to be a good, affordable, nice looking keyboard for the Apple-1 which can be built by hobbyists. If we are lucky, it might also fit into the Apple II shell, but this feature was not tested yet, and so I placed a companion thread into the Apple II forum:

 

https://www.applefritter.com/content/uncle-bernies-yaak-yet-another-apple-keyboard

 

But for Apple-1 owners, many of which are building custom enclosures anyways, the mechanical differences to the original Apple II keyboard are irrelevant, so don't worry about the dimensions.

 

MOTIVATION

 

Yes, I know, there are plenty of keyboard alternatives for the Apple-1 out there (this is why it's "Yet Another" one).

 

To understand my motivation, let's investigate what is already there in terms of Apple-1 keyboard solutions and discuss their merits and drawbacks:

 

ALTERNATIVE SOLUTIONS WHICH ALREADY EXIST

 

There are replicas of the "Datanetics" keyboard which back in the mid 1976 were sold cheaply as surplus (I have some early BYTE magazines with that ad, but can't find it right now). The Datanetics replica is open source, see here:

 

https://github.com/schlae/replica-datanetics

 

There also are replicas of the Apple II keyboard, see this link:

 

https://www.applefritter.com/content/new-apple-2-keyboard-replacement

 

... among various other open source and closed source / commercial keyboard projects.

 

Finally, there is the (objectionable) way to cannibalize an original Apple II for its keyboard and slighly modify it to work with the Apple-1.

 

Various keyboard emulators also do exist, like this one:

 

https://www.applefritter.com/content/keyboard-serial-terminal

 

... and this one:

 

https://www.applefritter.com/content/apple-1-keyboard-emulator-cable-plans

 

So why did "Uncle Bernie" venture into designing YAAK ? What is the motivation ?

 

Well, being a reasonably fast typist, I hate the Datanetics keyboard layout which slows me down. Add I also dislike the mess'o wires it needs to connect to the Apple-1 motherboard.

 

Cannibalizing an Apple II being a collector's item on its own right is out of the question for me. "Adopting" Apple II keyboards off Ebay (the sellers did the butchering of innocent Apple II so these sellers are guilty) turned out to be a futile and often frustrating  exercise: over the years I bought a few of those, and not only did I spend up to $200 on these wrecks, I also spent many hours of work to replace the key switches which had failed, and to retrobright the key caps, with various degrees of success.

 

Even if I would pay myself minimum wage (~$20/hour. For posterity, at the time of this writing, this buys you a small high quality grass fed beef filet mignon which is delicious to eat, if properly BBQ'd). No way that I would spend six to eight filet mignons worth of my time on restoring decrepit original Apple II keyboards anymore.I was stupid enough to do that several times. And then I discovered that the MOLEX connector (which is unobtainium in qty 1) also can fail, see this thread:

 

https://www.applefritter.com/content/does-anyone-know-source-25-pin-apple-ii-keyboard-connector

 

As for the various keyboard emulators, they are useful, and I like them to speed up my own development work on the Apple-1, which is thanks to their "download" functions being fed from my Linux based toolchain, but frankly, for a demo of an Apple-1 clone  in a vintage computer setting (like VCF, or in a computer museum) having a modern notebook computer sitting next to the Apple-1 and using the keyboard of the modern notebook computer to exercise the Apple-1  is misplaced for that setting and may leave a bad aftertaste with the onlookers - - - the notebook could emulate the whole Apple-1, so what's the point to also show an Apple-1 once the notebook comes on the scene.

 

So, a better solution had to be found: YAAK.

 

The early steps of its development can be seen in posts #10 and #11 of the above thread about the 25 pin connector.

 

KEY FEATURES

 

YAAK will be an open source project for a keyboard for Apple-1 computers which is based on the famous Cherry MX key switches (at the moment it is NOT open source yet, as I do not want to publish imperfect and untested work, not worth the trouble it may cause).

 

YAAK can accept the original Apple II keyboard encoder card found on the split PCB Apple II keyboards. These have a 25 pin row which mates with a 25 pin connector on the actual keyboard PCB. I think that lots of these encoders float around as the keyboards with the key switches get defunct more often than the encoders. Also, I was told, or seem to dimly remember, that there are replicas of said encoder cards, although I never had one of those replicas.

 

But wait, it gets better:

 

YAAK also has the (optional) on board key matrix scanner which ends up in a PS/2 keyboard or mouse plug. This allows for detached keyboards with longer cables.

 

Although it is NOT truly PS/2 compatible protocol wise, my vision is to have a MCU based keyboard encoder card with a PS/2 jack. You could plug either the YAAK with populated key matrix scanner components into that jack, or, alternatively, a true PS/2 keyboard. Depending on how "vintage" you want the "looks". The MCU would find out automatically which type of keyboard it is dealing with.

 

This proposed solution based on a PS/2 keyboard cable is partially driven by my own desires, but also by the needs of people who want to take their Apple-1 clones to VCF's or similar venues, or computer museums who want to give their patrons the opportunity to actually program their Apple-1 being on display.

 

In both cases, the Apple-1 itself can be protected by an enclosure, i.e. plexiglass, but the keyboard must be exposed and cannot be protected from rough handling, spilled beverages, or dirty kid's fingers (is that brown smear left on the keyboard by that kid really chocolate or is it something more gross ?)

 

So for these demo purposes, the keyboard must be cheap and disposable. Since PS/2 keyboards are essentially zero cost (now being electronic junk, having been replaced by USB keyboards long ago), this the the cheapest and best solution for a disposable keyboard.

 

The more valuable and cherished YAAK, of course, would plug into the same PS/2 jack of the encoder for use in safer environments, such as for demos to adults at home.

 

So far my vision of a modular, DIY keyboard, with a separate encoder that could be tailored for any target system.

 

CURRENT STATE OF THE WORK

 

This Friday evening, I got the first batch of PCBs and believe me, I could not find any sleep before I had tested out the functions of these PCBs. Because the electronics and the PCB layout was designed in a great hurry and with no time for prototypes (the reason for the hurry is the upcoming tariffs / customs duties announced by President-elect Donald Trump - I disagree with his plan, and I'm refusing, as a matter of principles, to pay customs duties on any components I buy overseas because I can't source them domestically, so why having tariffs on those components at all ? In this case these tariffs are not protecting any domestic manufacturers, but instead, these tariffs are of parasitic nature any Randian like me must refuse to pay, as a matter of principles. So these are probably the last PCBs I ever have ordered from JLCPCB in China.)

 

REMARKS ON THE CAD TOOL CHALLENGE

 

To make my risks with this layout worse, the DIPTRACE PCB layout suite I bought a while ago is still too alien to me, and so far I could not find the time to learn how to enter schematics ... so I had to do all the layout without LVS, all the layout was done just from scribbled schematics on paper. In prior decades I had used EAGLE, and drew schematics first, to get rat lines and LVS, but when EAGLE was sold to some greedy corporation which changed the license from perpetual to yearly, that was the end of my use of EAGLE (I would have needed a fresh installation after my 20+ year old tower PC became too wonky, but the new owners of EAGLE refused to accept the perpetual license I had bought, and that was the end of my dealings with them, greedy bastards who will never see a dime of my money).

 

OLD TIME TRICKS TO THE RESCUE !

 

Using old time tricks and techniques from 40+ years ago, I still succeeded in making an electrically flawless PCB layout, which worked on the first try. One of these tricks is to make a photocopy of the hand drawn schematic, and then, during layout, mark every connection done in the CAD tool with a yellow highlighter on the paper.This helps greatly to avoid bugs in the connections.

 

REMARKS ON THE DRILL TOLERANCE CHALLENGE

 

I even got the friction fit of the Cherry MX key switches right-on-spot. They can be pressed into the PCB with no undue force, but they still stay put, and won't fall out or get dislocated when the PCB is turned upside down. This is a very important feature for saving time and hassle when populating the PCB. These drill tolerances were my greatest fear - those guaranteed by JLCPCB for non plated through holes are a bit loose. And their plated through holes which have tighter tolerances don't have the friction "bite". This is one example for the risks you have to take with overseas PCB manufacturers. This risk alone would have justified making only one prototype PCB first to test the Gerbers - but there was no time for that, thanks to Mr. Trump.

 

SOME MINOR MECHANICAL FLAWS

 

The only two mechanical flaws found so far are related to the solder mask and the silkscreen, but this can be fixed in the Gerbers easily.

 

For instance, JLCPCB did not replace the "JLCJLCJLC" text I have placed on the bottom side of the PCB with their manufacturing lot number, as they usually do, but they did add that number in some corner nearby. The first time this happened to me. It is not too disturbing. Don't know whose fault this is and why this happened.

 

What is worse is that the solder mask on the pads for the key switches got somewhat too tight. I did intentionally choose a minimal (design rule) mask ring to get all small vias covered with solder mask, but this somehow also led to the keyswitch solder pads having almost no exposed HASL ring around the hole. For the top side this bug could be called a welcome feature, as it helps to prevent shorts caused by accumulation of potentially conductive debris, which is inevitable unless it's a membrane keyboard (a different animal), but on the bottom side, the solder side, I wish the exposed ring was a little bit wider, to make larger solder joints.

 

Electrically and mechanically, there is no problem though - the plated through section of the hole solders fine and actually is the part of the solder joint which takes the mechanical stresses and conveys them to the PCB base material. The copper ring of the pad as such is only glued to the base material and hence, is mechanically much weaker. This is why it's always these copper rings of the pads which come off the PCB when being overheated with a soldering iron. So the "bug" with the solder mask being too tight actually may be a benefit for the durability of the keyboard, who knows.

 

ON THE EXPECTED USEFUL LIFE SPAN OF THE KEYBOARD

 

The Cherry MX key switches as such are rated for 50 Million cycles. I don't think a typical Apple-1 user could ever reach that life limit of such a switch. How long the keyboard PCB solder joints and traces last before they develop cracks is another open question.

 

MANAGEMENT OF MECHANICAL STRESSES

 

I did my best to design the layout such that mechanical stresses are minimized (i.e. using rounded corners of traces). I also have provided seven (!) large mounting holes strategically placed around the key switch area which can be used to bolt the keyboard PCB to the top or bottom of a rigid enclosure (bolt OD max. 4.8mm, which is not exactly weak !). This brutal measure should allow operation of the keyboard with no undue flexing under any condition, despite it has no integral metal frame.

 

MECHANICAL RIGIDITY REQUIRED !

 

The importance of mechanical rigidity of keyboard PCBs cannot be over emphasized. Once we use individual key switches soldered into a PCB, it must be rigid and must not flex too much under the keystrokes. The only alternative are plastic contact membrane based, disposable keyboards, the kind which nowadays is ubiquitous in notebook computers. These are not really bad (I'm amazed how long they last, given how cheaply made they are), but they are simply not period correct for Apple-1 use.

 

So it is unavoidable to bolt this keyboard to some rigid structure. Hence, the seven strong mounting holes.

 

ISSUES WITH NAKED YAAKs - TO BE SOLVED HOW ?

 

But for casual use, the finished keyboard PCB can also be laid flat on the desk or table. The only issue with this mode of use is how to keep the leads of the various components from scratching the desk surface. Adding rubber feet may be a solution, but it has been my experience that the self-adhesive variety tends to fall off after a while. The kind of automotive rubber feet I found for my Apple-1 motherboards which can be fastened by a screw turned out to leave persistent black rings if left sitting on a light surface for prolonged periods of time. Nylon feet turned out to be too slippery for keyboard use. So you can see, lots and lots of subtle little details need to be considered when making a keyboard.  I'm open for your comments / suggestions on how to solve these issues with naked keyboards.

 

LESSONS LEARNED !  

   

All the minor bugs encountered and mentioned above could have been avoided by ordering a single prototype PCB first, and not the whole lot. But then, with the inevitiable delays incurred by this, the whole lot might already have been struck with Mr. Trump's tariffs, and according to what was said on the web, this could have doubled the costs per PCB, which is inacceptable for me, considering that I may end up with some unused empty PCBs which find no use and hence will go to a landfill. I hate to throw my money into the trash bin. So it makes a difference if a keyboard PCB costs me $6 or $12 ($6 plus $6 tariffs).

 

TESTS COMPLETED SO FAR

 

I have built one lab rat to test the key functions and the on-board scanner electronics, and it works and looks fine:

 

 

At the moment, the two signal wires from the PS/2 jack are going to the parallel port of a notebook computer running DOS, on which the scanner driver written in "C" runs, which scans the keyboard, does the key debouncing, the autorepeat, and the key encoding, and displays the results on the screen (in the yellow oval of the above picture).  Very helpful for testing !

 

WORK STILL TO DO

 

Once I have made sufficient progress with some other projects of mine, and I have a BOM for them large enough to justify an order to Mouser or Digikey, I will also order the Hirose connector which is supposed to fit into the YAAK PCB, such that an original keyboard encoder made by Apple (the corporation) could be plugged in.

 

When this test succeeds, and the solder mask has been revised a little bit, then the Gerbers are ready to be released as "Open Source" - I promise ! (The open question is who will test these revised Gerbers . . . I won't as I now have enough empty PCBs for all the keyboards I intend to ever make for my fifteen Apple-1 clones).

 

I do not have a schedule yet to design the actual keyboard encoder with the PS/2 jack, which supports the on-board scanner electronics of YAAK. I'm just too busy with other projects right now (such as atomic clocks) and so I have no bandwidth left over (at this opportunity, is anyone out there in the USA privately owning a fully functional Cesium atomic frequency standard ? - if you do, please send PM to me !)

 

VOLUNTEERS WANTED !

 

I you like the YAAK project, and if you live in North America, I could provide you with a PCB, a set of key switches, and a set of key caps, and - if you want - the other electronic components at cost ("no profit" for me).

 

Sorry, I have no mice anymore to salvage the PS/2 cable and its connector - you do this to one of your own old mice. Armed with this, you could build a YAAK with on-board scanner as seen in the above photo, and then you could proceed to develop code for a MCU of your choice to do the keyboard scan and key encoding, and to drive a 16 pin Apple-1 keyboard cable. If you then make this encoder open source, YAAK would be complete. I can provide you with the "C" code I have written for keyboard work. The trick is to turn that into assembly code small enough for a cheap MCU (yeah I know, ST32, cheap and fast enough to emulate a dozen Apple-1 running simultaneously, but this is not the spirit, not the right way, I think it should be be done with a 1980s era MCU, such like the ST6 or the PIC, just to stay somewhat period correct).

 

If no such volunteer is found, the Apple-1 user community must wait until I have found the time to code this for some period correct MCU (i.e. PIC16 family) myself, which at the current sorry state of my other projects, may take 1-2 years from now, until I can start the actual coding work (I wish I had the "Star Trek" transporter and could hack it to produce exact duplicates of me, just to make them work on all these uncompleted projects of mine ;-).

 

Alas, time for projects is always a scarce ressource. So many projects, so little time.

 

COMMENTS INVITED !

 

Do you like this project ?

Do you see an application for you ?

Do you have any technical questions ?

Do you have suggestions for improvements / extra features ?

Do you want to volunteer to develop the MCU based encoder mentioned above ?

 

I do have a small number of PCBs and key switch / key cap sets left over which are available to volunteers at cost (I guess below $100 but above $60, sorry, did not calculate the per unit costs yet, just designed it to be as cheap as possible . . . there are still unknowns, like the costs for the mechanical support of the space bar, for which I have planned several alternate solutions, but not sure yet which are most viable for hobbyists. The "professional" solution used in factory made keyboards involves bending spring steel wire to exacting dimensions, and the last time I did that I wasted spring steel wire worth more than $15 with my failed attempts . . . this is just one example how to ruin a low cost concept . . . on the other hand, the hardware for building a bending jig, available at Home Depot, costs even more ! --- you see that building a keyboard is not a trivial exercise, as there are mechanical contraptions involved, which always were the bane of us electronics hobbyists).

 

- Uncle Bernie

 

Macintosh_nik's picture
Offline
Last seen: 10 hours 57 min ago
Joined: Jan 8 2021 - 05:18
Posts: 495
Hi Uncle Bernie!

Unlike the main board, an authentic keyboard is not a "must-have" for Apple-1 enthusiasts. Sure, there are purists who want a 100 percent replica on their desk. They might want to turn on a BeeGees record or sip a joint to get the full '70s vibe, but most guys are looking for the simplest and most inexpensive solution. I reread your post twice and found neither simplicity, nor cheapness, nor something fundamentally different from existing solutions. 

 

My buddy from Moscow did a simpler one. He took the encoder out of a PS/2 keyboard, then designed a board for readily available Cherry MX mechanisms. And added to it a flashed controller from Novichok adapter. And that was it! I got a PS/2 keyboard with the minimum required number of keys for the Apple-1 and a DIP-16 connector. It can be called a simple and inexpensive solution.

 

You have several unfinished projects with a vague future in the last 3 years: a Disk ][ drive connection card, an external memory card, a video card, a book about the Apple-1, a replica Apple //e and something else, I think. Perhaps it would be more appropriate to finish a couple of these and then start something new? Otherwise it all looks like projects for the sake of a post on Applefritter rather than for the sake of a finished product. I'm afraid you'll soon stop being taken seriously. There's a Russian proverb, "Chase two hare and you'll never catch one." And you've already got half a dozen of them hares. 

 

I apologize, I respect you very much and appreciate your contribution, but I am a straightforward person and could not help saying so. Personally, I'd rather hear the bitter truth than sweet lies.

Offline
Last seen: 3 hours 29 min ago
Joined: Apr 1 2020 - 16:46
Posts: 1031
This keyboard project is real - all components in stock !

In post #2, 'Macintosh_nik' wrote:

 

" You have several unfinished projects with a vague future in the last 3 years " .  .  . " There's a Russian proverb, "Chase two hare and you'll never catch one." And you've already got half a dozen of them hares."

 

Uncle Bernie comments:

 

The "vague future" of my projects is not really vague, it only depends on whether I wake up every morning instead of being dead. This is age related, and no, I did not take the depopulation "vaccine".  At my age, one can die in sleep any night.

 

Readers of your criticism should note that all my projects are hobby projects with no intent to make any money with them. So none of these projects are driven by forces of economics or "time to market". Actually, there is no "market", there are only a bunch of hobbyists who occasionally look at Applefritter for what is new, and then they may or may not post a comment.

 

I publish my ongoing projects in Applefritter just to tell fellow hobbyists that these projects exist, and to see what the responses are, and whether there is any interest in them by others at all. So far the interest shown by Applefritter members for my projects was quite underwhelming, not to say worse.

 

All my projects you mentioned, such as my Apple-1 disk  drive controller, my 48k DRAM card, my color graphics card, and the "Replica 2e" work, the wire wrapped prototypes sit on my living room table, and they work fine, but sorry, I'm not inclined to design a printed circuit board layout for them if only 2 ... 3 people in the world have shown interest in them.

 

There also were only about 3 people who contacted me about my Apple-1 book. Which currently has about 300 completed pages of text, and maybe 200 more to be written. The big problem is to draw the schematics etc. in a way that can be handled by book-on-demand printing houses. I can't use scans of hand drawn stuff, because this would become illegible. How many books could be sold ? 10 ? 20 ? - - - you see, again, no money can be made off such a book project, so I can't pay for professional draftsmen who would redraw my hand drawn schematics using a professional publishing tool.

 

Keep in mind that anything Apple-1 related is a very very small niche in the computer hobby so this lack of demand for my projects is fully understandable and I don't complain about it. For me, it's just a hobby to kill time. I would design and build these gadgets anyways, for my own use, and if enough people out there want to build another one, fine, I will spend a few days to make a PCB layout. But as I said, I can't do this for just 2...3 people who have shown interest. Note that showing interest via email or a PM does not mean they would actually buy a PCB (or other components) from me. Without a signed purchase order, all is just pretending.

 

As for the YAAK keyboard, I now have 20 empty PCBs, and 15 of them I need myself. So 5 are left. I also have 5 sets of key caps left. Which are the most expensive set of components, I paid $60.91 per set for 20 sets. Oh, and I added up some numbers and found out that the components, if bought by individuals for one keyboard each, just end up a tad above $100. But since I have bought more than 1000 Cherry key switches, I could make complete parts sets for well below $100. These costs could be greatly reduced by using Chinese made copycat key switches, but I did a tear down of some of those and what I found was poor quality contacts and springs. I made a post here on Applefritter about this, including a microphotograph of the lousy switch contact they use. So for half the money, you get key switches which are lousy, but would work for a while. The Chinese also make cheaper keycaps based on transfer printing and not on double injection molding. So these cheaper key caps will have their symbols worn out soon. But again, they cost much less than the ones "Made in the USA" by Signature Plastics, which are double injection molded.

 

I have everything for these keyboards in stock, they exist, and are real, but I lack the time to code a MCU based keyboard encoder in some assembly language. I do have "C" code which does all the work, including encoding a real PS/2 keyboard, but it will take more than 80 hours of work to reimplement this in a 8-bit MCU assembly language. This is why I presented this project here and did ask for volunteers who would like to do develop this missing piece. So far, no volunteers.

 

- Uncle Bernie

Online
Last seen: 1 hour 57 min ago
Joined: Feb 27 2021 - 18:59
Posts: 650
no assembly required

Barely any MCU applications are done in assembly language anymore. The Kiel, IAR, XC, and GCC compilers support all of the major MCU architectures, including 8-bit MCUs. The number of timers and counters built into today's MCUs make it basically unnecessary to count instruction cycles by hand.

Offline
Last seen: 3 hours 29 min ago
Joined: Apr 1 2020 - 16:46
Posts: 1031
Keyboard encoders written in "C" feasable ?

In post #4, 'robespierre' wrote:

 

" Barely any MCU applications are done in assembly language anymore. The Kiel, IAR, XC, and GCC compilers support all of the major MCU architectures, including 8-bit MCUs. The number of timers and counters built into today's MCUs make it basically unnecessary to count instruction cycles by hand. "

 

Uncle Bernie comments:

 

I agree that with the advent of  very powerful, modern MCUs which may be faster than a Cray-1 of the 1970s, use of "C" compilers, even if they produce inefficient code, can solve most problems quickly and for low software development costs. And still run many time faster than needed. A whole Apple-1 system could be emulated on a ST32 including the video generation in software.

 

But for legacy 8-bit MCUs the story is a bit different. About 20 years ago I developed some code for the 8-bit PIC family and the "C" compiler they had for free produced code that was so inefficient that it was useless for my application. It simply was not in the league of the Keil "C" compilers for the 8-bit MCU with Intel architectures. The paging scheme for the RAM of the PIC may have contributed to the inefficiency. We need to keep in mind that the original 8-bit PIC architecture is very old and never was meant to do "real computing stuff". It even predates the Apple-1 !

 

The first PIC was meant to implement peripherals for the ill fated CP1600 CPU made by General Instrument, which had some architectural flaws thwarting easy implementation of real time capable peripherals if running their drivers on this early 16-bit CPU. So out of this pressing problem, General Instrument developed the PIC, which is a good and efficient architecture for implementation of quick-and-dirty peripherals not needing much buffer RAM within them. Hence, the "register based" concept of the PIC which initially had no RAM in the classic sense, but only a "register file" which could be used as a RAM.

 

From this historical background it can be understood why the 8-bit PICs do not lead to efficient "C" compilers unless the "C" source you write is essentially the same thing as native PIC assembly code . . . throw in a few arrays and nested functions and the whole attempt falls apart, and the developer must go back to hand crafted assembly code.

 

However, in 20+ years, "C" compilers could have made some progress towards code efficiency. You have alerted me that there is a new "XC" compiler from Microchip, so I just downloaded the Linux version, and will give it a try.

 

As for the YAAK keyboard project, no timed loops are required, so no cycle counting necessary. PS/2 keyboards are a different animal, as they generate the clock internally, and the MCU in the keyboard encoder needs to be able to keep up - but there also is the trick to "stall" the keyboard and make it wait until the MCU is ready.

 

So I think, if the more modern "C" compiler will generate better code than the compiler of 20 years ago, it may be very straightforward to just compile my existing "C" driver and have a PIC as the keyboard encoder.

 

Of course, all this is driven by the fact that I do have several 1000's of PIC16C66 in my basement, which have been waiting to find a use for many decades. This is the way ! - I hate waste of precious silicon.

 

- Uncle Bernie

Offline
Last seen: 4 days 22 hours ago
Joined: May 31 2022 - 18:18
Posts: 366
UncleBernie wrote:However, in
UncleBernie wrote:

However, in 20+ years, "C" compilers could have made some progress towards code efficiency. You have alerted me that there is a new "XC" compiler from Microchip, so I just downloaded the Linux version, and will give it a try.

 

I suspect you know and have, but if not... the optimizations are only available in the "pro" (ie licensed) version of XC16. The free version dose no optimizaitons, so no it's not very efficient. =)

 

While modern compilers are better than they were, where they really excel over assembly programmers is when dealing iwth all the features found in modern RISC processor designs. I am smart enough to understand it would take me months to years to match the compiler's results with scheduling, look ahead and branch predections stuff so unless it's needed... I stick with C. That said, I write the asm, but more importantly always examine the compiler output to understand how the compiler handles things. I've found many examples which any self-respecting programmer would be embarassed to have in their code. For example, these Microchip parts have a lot of sample code which tries to keep things "pretty" with their "bit addressable" operations. But... if you look at the generated code you'd may never want to use bit addressable instructions, but their libraries do! I had inherited a dsPIC16 project and had no free space for code changes and bug fixes. I found the inditial devleopers just took the Microchip samples and ran with them. The problem was this was a read, modify, write architecture so you see this "cute" MC sample code initializing every bit in a register as a single bit-addressed line of C code. When compiled each line becomes 5-9 assembly instructions, and that happens for every single bit in the register! With all instructions being the same size, memory disappears quick!  If they had realized this and refactored with the old-school way to configuring all the bits of the reginster in one shot that's one or two or three instruction but then all bits in that register are done! With only 12kB of flash for code every byte matters! Another thing these programmers did without realizing the potential problem was to create a incoming "message" handler using a switch statement where each case was a call to a message handler. Sound fine, but these message "ID"s covered a large range value and was sparsley populated.... XC did not do anything special here and just make a very large jump table with most entrires contianing a branch instruction to the next C line after the switch! Highest space optimization in the "pro" version and the compiler didn't take liberities to handle any of these space wasters. The compiler just did the minimum and the H1B developers never figured out why all their memory had disappered. But they also couldn't understand the compiler generated code, and missed all the clues in the linker output. 

 

Long way of saying, if you do try to compile an encoder for the PIC, be sure to check the ouptut to verify things are as you're expecting! 

 

UncleBernie wrote:

Of course, all this is driven by the fact that I do have several 1000's of PIC16C66 in my basement, which have been waiting to find a use for many decades. This is the way ! - I hate waste of precious silicon.

My precious... that sounds like a nightmare someone should help you with. =) 

Offline
Last seen: 3 hours 29 min ago
Joined: Apr 1 2020 - 16:46
Posts: 1031
Why "C" compilers for 8-bit MCUs are so inefficient.

In post #6, 'jeff d' wrote:

 

" I suspect you know and have, but if not... the optimizations are only available in the "pro" (ie licensed) version of XC16. The free version dose no optimizatins, so no it's not very efficient. "

 

Uncle Bernie comments:

 

Thanks for the warning, but I will still give it a try !

 

From the standpoint of a MCU manufacturer, it makes sense to offer a "free" C compiler which, by design, must only be able to produce inefficient code. This is why:

 

1. With assembly language programmers being expensive, without a "C" compiler offer,  only few prospective customers would consider this particular MCU. So nowadays, offering a "C" compiler is mandatory.

 

2. The "free" C compiler lures them in, and the development team (if inexperienced with that type of scam) commits to their manager that the "C" code could be developed and be ready for release in X weeks.

 

3. The manager plans the project schedule according to these promises.

 

4. The development team quickly finds out that the "free" C compiler produces rotten and inefficient code, and that they will not be able fit the code into the MCU and fail to meet the schedule.

 

5. Now the project is in jeopardy and two ways to save it exist:

 

a) Change to a more powerful MCU from the same manufacturer (similar but more memory to hold the inefficient code).

 

b) Caugh up the money to buy a more expensive "C" compiler able to generate more efficient code, which then - hopefully - will fit into the originally chosen, smaller and cheaper MCU.

 

Rinse and repeat. The MCU manufacturer makes more money in any case.

 

But to avoid any false impression, I don't blame the writers of these "C" compilers to be incompetent. About 30 years ago I developed my own "C" compiler targeting 8 bit MCUs and it turned out that it's almost impossible to do the stack frames in an efficient way.  I did not try it for the PIC, which has the further complication of "RAM" aka "register file" chunks not being continous and cluttered all over the address space, and for the larger PICs, distributed over several banks, which need bank select code. I think the only viable solution would be to build a function tree and then allocate register file bytes to the tree, so no stack frames are ever needed. I have a hunch that the famous "Keil C compiler" for the 8-bit Intel MCUs does that, but I never worked with it, as it did cost an arm and a leg.  (See points 1.-5. above why they could do this). The downside of this approach is that no recursion / no reentrant functions are allowed. And it defeats the intent and purpose of high level languages to generate code this way.

 

- Uncle Bernie

macnoyd's picture
Offline
Last seen: 9 hours 12 min ago
Joined: Oct 15 2012 - 08:59
Posts: 857
Maybe another option ...

Maybe you could find someone who has access to that pricey C compiler of your choice that could compile the code for you?

Especially being a hobby project you're simply trying to prove out.  Just a thought.

Log in or register to post comments