Duane Benson 7/6/2012 11:01:49 AM User Rank Blogger
Re: I'm embarrased to say that...
Karl, re: "Are the members equivalent to device drivers in other contexts? That would only need ability to read and write MMIO regs?"
Every one of those languages I mentioned represents registers differently. In some cases, I've been able to use macros to sort of make a translation table, preserving some level of code transportability, but generally that seems to be more hassle than its worth for the size of programs I typically write.
The one good thing is that in the case of all of those "C" variants targeted at PIC processors is that they will all plug into Microchip's MPLAB IDE. At least I don't have a different IDE for each language too.
Hi Karl, thanks for your questions. Always a pleasure to answer. The most common language for 8051 programming is for sure C. But it's still all up to you if you choose IAR, Keil commercial tools or free SDCC. The IAR offers C++, C, related libraries, a simulator and the debugger. The Keil offers C language, related libraries, a simulator and the debugger. SDCC offers C language and related libraries. And the last but not least, you can also choose available RTOS with 8051 ports (e.g. RTX-51, Salvo, FreeRTOS, CMX-RTX, ABASSI, QP)
Norm no one could say it better. I think that in the 1980's no one could ever think that 8051 will be still popular in 2012. Its design lasts and lasts and even though 32-bit MCU are moving our imagination, goll old fashioned 8051 or 80251 still got a place in outstanfing projects. So.... "Long live the 8051!" :)
NormNovotney 7/5/2012 2:41:58 PM User Rank Beginner
The 8051 lives
The end of the 8051 has been predicted (over & over) for at least 20 years. It has proven to be resiliant & adapatble as the core of many newer upgrades...shows that a thoughtful design can last and last and end up being used in ways the originators never imagined.
Brian Bailey 7/5/2012 1:57:51 PM User Rank Blogger
Re: I'm embarrased to say that...
"Given high speed and programmable, is the need for a complex HLS a bit less critical?"
Hmm - lets take that in two pieces. First is HLS a good idea for FPGAs? I would say most certainly it is. We are producing much bigger and more complex designs than we were in the past and just doing all of it in RTL is too time consuming and too error prone. HLS can provide a big leg up here.
Now, does it warrant complex HLS? Yes, HLS is complex, but part of the reason for this is coming up with the best architecture for a given problem. The best architecture may be to maximize what can be fit into an FPGA, or its performance and that also benefits an FPGA developer just as much as an ASIC developer.
@Duane: It is amazing how th marketing Hype, Drivel, Half-truths, Outright lies and plain old BS has become a way of life. It is truly amazing that so many things have been designed in spite of all this.
To be civil, a lot of programmers have produced tools that are usable enough to get the job done.
A lot of designers avoid using any GUI and I am baffled as to how they can remember all the command line stuff for both the OS and the tools. When I am designing, I am barely able to click the right buttons on the menu, Maybe they have a great set of makefiles that I never bothered to create.
Back to the peripheral library. No programming language seems to have ever done IO directly, there was always an OS for that. Are the members equivalent to device drivers in other contexts? That would only need ability to read and write MMIO regs?
@Brian: Very good point that memory is very big issue. I liked your article on the memory wall. To pick up on your point of moving away from the processor -- I think a program written in C, or anyother curly brace language, can be reduced to test a condition then either jump or got to next sequential where either target is a test or an assignment. The first step of compiling does this parsing and produces an intermediate language which is probably still pretty concise. Then the bottom falls out when it is "de-compiled" to some typical ISA. The instruction is formatted into fields but the register select fiels is too limited leading to all kinds of overhead trying to allocate registers and to get the operands in and out of the registers for processing.
One extremely good use for a memory block in an FPGA is to hold as many variables as possible so that any two can be read at the same time to apply the operators.
Other independent memories can hold control bits, addresses, stack data, etc.
Just like Jacek's 8051, it takes very few cycles to do things, The data width can be a parameter chosen by the user.
Did you mention "distributed memory"?
Given high speed and programmable, is the need for a complex HLS a bit less critical?
Duane Benson 7/5/2012 12:15:07 PM User Rank Blogger
Re: I'm embarrased to say that...
Karl - re: "Is it a full C with all the function libraries?" I think this question illustrated one of the major challenges / frustrations in the MCU world these days. Most modern processors should be capable of faithfully following the original Kernighan and Ritchie C language. But, from what I've seen many MCUs wreek havok on the newer standards and newer standard libraries. Something so fundamental as "printf" can consume far more of the MCU's memory than is good for any of us.
The peripheral libraries really mess this up. For example, take a Microchip PIC processor. I can use any of these C compilers: C18, Hitech-C, CC5X, Boost C or XC8. Every single one of them uses different syntax here or there for the peripheral libraries. Some are just a little different while some are so different that you're better off just starting from a blank sheet than trying to convert.
So in answer to your question: 'So if something is "programmed in C" does that really mean that C syntax is used, or is it the "C language"?', I would have to say that hearing that an MCU is programmed in C, doesn't mean much.
Brian Bailey 7/5/2012 12:03:51 PM User Rank Blogger
Re: I'm embarrased to say that...
No Karl - you havent wasted anyones time. I think the point that you are making is that with a processor (CPU, MCU etc) there is a fixed memory architecture and the programming paradigm relies on that. When building accelerators or custom processing blocks, the memory architecture can be defined in many different ways and that can have a huge impact on performance. Sometimes that it at the cost of flexibility, but lets face it, that is why you are moving away from the processor in the first place.
In order to implement the components of a new chip design, any IP core should be delivered with everything needed to design, test, and validate that core in the target product.
If you are interested in licensing a third-party IP core, it's a good idea to ensure that the vendor can also supply you with the debugger. The ideal situation is to obtain the debugger together with the IP core -- all from one vendor.
To save this item to your list of favorite All Programmable Planet content so you can find it later in your Profile page, click the "Save It" button next to the item.
If you found this interesting or useful, please use the links to the services below to share it with other readers. You will need a free account with each service to share an item via that service.
Tweet This
