Technical Director

I am an Electrical Engineer by qualification and an Embedded Software professional and IT manager. Having about 38 years of experience in various industries such as Atomic Energy, Telecom, Digital Tv, Automotive Electronics, Appliance control, Robotics and Electric Vehicles I am from India and am currently a free lance professional


's contributions
    • A very god article explaining the trade-offs between performance. I have worked on embedded software development for both domains - customised solutions where the hardware cost was not an issue and could deploy high performance hardware so that the software design could be kept simple Vs High volume low cost consumer products where I had to use all kind of tricks to keep the code size minimal, keep real time budjet of the critical code tight to minimise interrupt latency, and have all kind of tricks with stack manipulation to avoid stack overflow. Coding a small embedded product such as a ignition control unit for a scooter with a 1Mhz micro controller having just 256 bytes of memory and is a real challenge for real time software engineer.

    • I am also a firm believer that , though it may seem to be a lot of unnecessary things , the basic RTOS is the fool proof answer for any Embedded system developer - Preemptive scheduling being one of the essential features. Any shortcuts in this can prove to be a headache later on when the design specs expand.

    • A good article that reassures the Embedded system developer that he is not alone left with problems to solve. As longas he/she is open to disclosing the problems , the help is available - through on line forums, manufacturer's support sites and so on. The earlier the problem is disclosed , lesser will be the time to solve it.

    • With todays multi-core soc environment we require a robust language like ADA.

    • Whether good or bad we all have to agree that the world is now dependent fully on software and the world is now running on software. The software in some of the systems is so huge and so complex that it is not possible to make it 100% fool-proof. But it is possible to make the software fault tolerant so that it continues to run . Most of today's money transactions are being handled by software. Even airplanes are being flown by software The days are not far away when the software will be written to correct itself of the error situations.

    • This is a great news for Java lovers who want to use Java in small embedded applications. The implementation of Java where the virtual machine concept is removed and Pure Java is used will make it look like any other language implementation and the overheads associated with the VM - memory and real time latencies can also be minimized. I am eager to use such Java implementation in my embedded applications.

    • One of the security measures that can be deployed for an embedded device is to reduce the time for which it remains connected to the internet, to minimum required. That can reduce the time a hacker or attacker gets to get into that device and break open its security

    • Yes of course! Networking micro controllers using serial links was a common practice at that time. Using serial multiplexor cards we had built a networked system for Hotel Management application sometime in 1985

    • The basic concepts in any programming language are 1) data Types 2) arithmetic operations 3) logic operations ( Boolean) 4) Program control - branching, looping, procedure calling Once you know these basic by learning a programming language it is easy to switch from one language to another by learning the syntactical differences. The algorithms to solve a problem generally remain the same.

    • On freeways and express highways such self driven cars will definitely be a boon which will save us from those long hours of sitting with steering wheel in hand. More time to spend with kids on the backseat!

    • David, reading your article , i felt like reliving my career in the Embedded systems. I started my career in the hardcore Embedded systems sometime in 1979 and have traveled through all those transitions in the micro controllers, OS the RTOS and the development tools. Those were the days! doing away with the print media is an inevitable thing of today as everybody is more at ease with the online content.

    • A very informative tutorial for a person looking at this topic for the first time and is also good for the person who has cursory information on the topic. It would be nice to include some real life implementations showing the energy requirements of a given circuit and how those requirements have been met by the applicable energy harvesting technique.

    • The braking function seems to be not working effectively or fast enough and hence on sharp turns the vehicle is going out of control. It is a nice challenge to designers.

    • In a typical control application we could successfully use a 6 core SOC where each core was dedicated to a specific function - Sensor input and signal processing, keypad and display handling, Actuators output control ( analog and digital) and the main control algorithm. So an asymmetric multi core solution is always preferable .

    • The focus of the article should be on the kind of solar panels used , the energy conversion efficiency obtained and how it kept the batteries charged and how much mileage was obtained between stops . The motor control and battery management functions have now become rudimentary and I do not think STM 32 has some USP in it specifically for solar cars

    • I am just wondering , in all this jungle of powerful micro controllers and the OS and RTOS where do those DSPs stand - Has anybody tried to have an OS working on a DSP?

    • In today's generation of programmers ( Sorry! the software engineers ) it has become a habit not to comment the code. Not commenting your code should be a cardinal sin! Just because you can easily debug your code using the tools does not mean you don't document your code properly.

    • Apart from knowing the prize winners of these awards, it will also be interesting to know the top contenders or nominations. This will also show the other leading edge technologies/products worth looking at.

    • This reminds me of the BBC Accorn home computer which became popular and promoted to schools in India sometime in 1985. This initiative is very good for students even at engineering levels to build their projects.

    • A very detailed and informative presentation on RTOS. May be if some slides are added to give tips on how to simulate various sensors by creating sensor threads instead of connecting to real sensors while debuuging the code , will add some more value. The advantage of writing sensor threads is that you can create all kind of sensor situations ( sensor range, sensor faults etc) which many times is difficult to achieve with the real sensors

    • Suddenly the two founder members and icons of today's information technology industry pass away in aquick succession. The marks they have left on Programming ( Ritchie) and consumer electronics ( Steve) remain there forever like the carvings on a granite

    • The course material appears to preliminary for somebody an engineer looking for key information. Does the author plan to have a sequel to this ? First of all for a measurement from a sensor signal it is important to know what you are measuring - The frequency, amplitude, area under the curve or what? this is the key to what interface and data acquisition software you will use. In my opinion this basic point is missing in this presentation. Or am I missing something?

    • A very good article on software reuse in the embedded domain. The fact has to be also remembered that while designing the new modules for any project care must be taken to identify those modules ( being developed first time) which may have a potential for reuse and to make them as generic and documented as possible for the reuse by the future projects.

    • When something enters a legal fight,it is very easy to prove a case either way and it is only the lawyer from one side who wins and everybody else loses. This is universal whether it is a case of murder or robbery or copying somebody's source code. The legal system does not help here much. What we need to build is mutual trust and employee integrity.

    • A very informative article on I2C serial bus. With so many serial bus standards in vogue today - USB, CAN field bus and also I2C, I was wondering if anybody offers a universal converter which convert one serial interface input to another desired serial interface output.

    • A very informative article comparing the GPOS with RTOS. In my opinion in most of the embedded control applications there will be very few dynamic tasks created and destroyed on the fly. Most of tasks ( or threads) are created on system boot-up and stay alive all the time. In such cases the priorities are also statically assigned. In such cases even a GPOS should be able to handle such applications if we have sufficient CPU speed

    • This a very useful paper giving guidelines on both hardware and software considerations aiming to reduce the power consumption of an embedded device. Running the device at lower possible frequencies and at lower voltages are the two obvious ways to reduce power consumption. In Software using the processor sleep modes whenever there is no activity is also a must for software design. One important thing in software, in my opinion, is not to have continuous software loops scanning for sensor or timer activities but to make most of the activities interrupt driven. This allows the software to make use of the snooze/sleep modes of the processor.

    • I remember to have made a coding mistake while programming a robot and the Robot instantly broke one of the vital part attached to its arm when I executed the program. In another instance a timing mistake in bus arbitration software used to burn the driver transistors of the bus circuit in our Digital TV circuit.

    • Many thanks for sharing your discoveries of gold at ESC. I got a good insight into ESC sitting here in India. One pleasant surprise for me was to read the names of languages like FORTRAN and Ada being still very alive for web based applications

    • As has been mentioned in the article it is not just the state machine but something like artificial intelligence, applying the interpolation and extrapolation techniques , similar to what is being applied in Robotics. This is OK for the robot to do this kind judgments based upon the surrounding situation but in an automobile situation such inferior duplication of what a common driver's human mind can do in a split second is something which is unnecessary addition to already overcrowded electronics in the automotive.

    • A very point-to-point description of the Embedded application development process on an SoC. As the paper describes correctly the key to a good embedded application design is to pick up as many things common and generic to other applications as possible, bring those modules to use to develop your unique application by just developing that unique UI and related application code. The I/O management, Remote data management, communications , all of these if handled using tested components from third party software developers your job gets simplified, your time to market is reduced and the testing time reduces by a geometric proportion.

    • Oh! so many ideas! But won't that make things more complex to manage. with so many intelligent systems on board a vehicle its complexity will be more than a Aero-plane cockpit. One simple thing can eliminate the need for all - sensible driving by the person behind the wheel. Of course some of the intelligence is very useful e.g. advance information on the road and traffic condition, advance warning on incipient problems in the Engine, Tyres or such critical systems. But don't make it overkill. Let the driver be capable of making his best judgment !

    • Today's embedded systems are almost emulating the yesteryear's mid range computers. With their multi-core architecture the processors are presenting the newer and newer challenges to the software community to develop matching development tools, simulation and testing tools , language support and so on. So we are actually working on those old big PDP-11s with RSX-11M like operating systems but in a physically much miniaturized form.

    • I worked as a programmer for almost 10 years before moving to software project management. Since I started with programming in machine language ( in binary form) in the initial phase, working later on assembly language itself was a luxury for me when later I worked on software development for 8080 based EPABX and ACD development. We were working in India for a project assignment from USA company. We did not have the computer to run the 8080 cross assembler/linker/loader in India. So we used to write code manually on paper , verify it with code walk through with our peers and used to send the code to usa by courier . A team in USA would then get this code entered onto the development system, cross assemble, link the same and test it on the target hardware and report any bugs to us by TELEX. we used to fix the bugs by rechecking the code manually. Such development environment forced a lot of programming discipline into our team of programmers and we were able to write zero-defect code by the manual process. We could optimize the code for real time and memory again manually. In contrast to this , I envy the current day c programmers who cannot get a single statement syntactically right because the development systems are doing that work for them, they do not have to worry much about memory constraints because abundant processor memory is now available. They do not have to worry much about the real time budget because the processor speeds have increased many fold. With these state of art fast micro processors and micro controllers with development systems and simulation systems the real art of programming has vanished.

    • A good article explaining the tightrope situation in which today's control systems have to work. Apart from the right kind of RTOS which will minimize the interrupt latency, it is also important to keep any on-the-fly calculations or interpolations to the minimum while controlling a tool position or tool path.

    • This a very concise and precise introduction to the motor control and gives comparative view of various control strategies for AC and DC motors. In the slide showing applications , I found the mention of EV missing. The BLDC motors are increasingly being used in Electric Vehicles because of their compact nature, in-wheel construction and simple control algorithm using hall sensors. I believe this is worth adding to the possible application areas. Or is the cost of Fujitsu micro-controller a constraint here?

    • This appears to be something more rugged than those fragile touch screens being used in the smart phones and other similar devices. Low current consumption is another plus for this new material. But I could not understand what advantages it has in a 3D product over the existing touch screens

    • In my opinion, for safety critical systems what we need to do is have a different set of development tools rather than using the off the shelf compilers, emulators or any such tools. Some of the facilities like dynamic memory allocation, where there is a possibility of exceptions at run time making the system crash, can be disabled in such compilers. Even the testing methodology and the associated tools have to be more stringent. I do not know whether , languages like ADA still exist. We need such languages which will enforce all type declarations and not do automatic typecasting. No default initialization of variables to be allowed.

    • For such seriousness to happen there has to be some pinch in hard cash to the software distributor. Currently the bug fixing cost, though very high ,is hidden . because it is a manpower cost and not wasted components. If like in hardware the software goes into OTP chips ( one time programmable chips), then millions of such OTPS will become scrap with every bug detected and cost of fixing software bugs will become more apparent in the hard cash count to the top management.

    • Dipal, I do agree on this point that the young programmers are forced to take up the project lead positions for which they may not have the adequate skills. I myself was an avid programmer and not really interested in taking up the management position. What is wrong with remaining a skilled programmer all your life ? But as Dipal says, you are then branded as not ambitious enough ! There are many examples of good programmers becoming bad managers and ruing their and may be many a programmers' and the associated company's prospects.

    • There seems to be too much focus on finding the bug in the software and thus ignoring the other components of the control circuit - The sensors, sensor interface, actuator interface circuits etc. There may be some runaway problem in any of these components. These also need to be thoroughly analyzed by the competent experts. We have to accept that there is problem somewhere and not just keep on insisting that there could be a bug in the software but we are unable to find it.

    • To be able to develop a bug free software , a very strict methodology has to be adopted right from the requirement specifications . In most of the projects the real problem is that the requirement specifications are never frozen and the people modifying them at any stage of development , think that it is just a minor change and since it is software anything can be changed even at the last minute. The specifications keep on getting modified, twisted and the project schedule remains the same and the poor programmer finally loses control over his code and then fixing one bug creates another!

    • As a RTOS designer myself , I find this short course very informative and concise. Some more details on memory management would add value to the content. In my design i had found the bit map driven memory pool management very efficient and requiring less amount of code. Also some more explanation on importance of re entrant code and critical code section of the kernel may be included.

    • This course gives a concise picture of the product building process and is very useful and important for the Embedded system designers. The debugging of embedded systems becomes more and more difficult as you process towards hardware & software integration. The prototyping helps to build a controlled environment where the developer an concentrate and debug on area of functionality at a time. Prototyping also allows non-real time testing and introduction of additional hardware and software blocks to trace the intermediate stages of program execution. For a successful and bug free product one must invest in prototyping and tools like those provided by NI give a ready made platform to build your prototypes.

    • Since any medical device developed by any company undergoes rigorous tests for functionality, performance, reliability, durability by the health authorities before it is permitted to be used on patients, the designer do not have to worry much how their device will fare in the life critical applications. But better design methodology will certainly help in reducing the development time and jitters during the qualification process.

    • I am just shocked to see that the Americans save only about 1%( or even less ) of their earnings. The salaried class in India saves at least 10% of their earnings as an insurance for the future. Even govt policies encourage savings to the tune of almost 30% of the earnings , by proving tax reliefs on savings. I just can't imagine how Americans can have a sound nights sleep with so less saved for their future!

    • This article reminds me of a venture capital funded project in which I worked 5 years back, we had successfully developed a multiprocessor configurable system on chip (SOC) where each of the I/O pin was configurable as either a digital input, digital output, analog input or analog output. We could also further configure the digital outputs as pulse output , level output etc. a built in ADC interface would automatically get attached to the pins configured as analog inputs. For analog outputs DACs were also built in . As per the configuration and by programming various control bits the whole I/O processing of all the I/o connected to the chip could be achieved by just setting/resetting some control bits offline. The chip would remember this I/O configuration once programmed. We had developed a utility in visual basic where you could just fill in some forms to configure the whole chip for your application. So no code was required to perform any I/O processing. We could then only have to write the application logic. We had successfully demonstrated the use of this chip for Appliance controllers and temperature controllers in HVAC application.

    • Yes! Timing analysis at the time of design is very critical otherwise subtle bugs can get introduced in the system which are difficult to trace. I remember one such project back in 80's when we were working on a micro computer based networking system. While the software integration was in progress, we used to find that the system used to be stable in the morning but as the day progressed the system behaviour used to become irratic. Our software team used to feel that it was because of their patches, until one fine day we discovered that the memory section of the hardware had a mix of memory chips of two different speeds ( 15ns and 22ns if I remember correctly ) with system heating up their timing difference used to put garbled data onto the data bus! We must have spent at least 15 days to finally detect and correct this problem whcih appeared to be a silly component selection mistake.

    • A nice paper that concisely describes the implementation approach for noise cancellation in a hands free speaker phone systems. I wonder whether similar solution can be applied to filter noise emanating from the road traffic in a road side house. If this can be achieved in a low cost manner ( without shutting the windows off-course) it can create a tremendous market opportunity

    • All said and done it is up to us engineers ( especially in the senior level) to keeps these 8-bitters alive. Don't bow to the management pressure from the top and don't have the fear of being ridiculed by the younger recruits who may have done their college projects with the latest 32 bitters just to get good grade.

    • Looks like a lot of integration and support for various serial bus interfaces required in Consumer as well as industrial applications has been provided in this design. Some information about the internal architecture of the Atom processor - its instruction set etc will be beneficial to the software and firmware developers

    • This e-call system of emergency alert looks fine but its activation leaves some doubt in my mind. What if the air-bags have not opened? what if the occupants of the car could not activate e-call manually? What if the GPS and the e-call unit itself gets smashed in the accident? why not have a system which works otherwise- the e-call equipped vehicles will be scanned continuously for the OK signal. Anytime the signal is missing the car can be assumed to have a mishap and the emergency assistance system be activated. This should same like a Plane is continuously monitored on a Radar and as as it goes missing an emergency is declared for that plane.

    • It also came into my reading that the new breakthrough in materials like Graphene has made it possible to build PV cells by just a thin layer of Graphane on the window glass( retaining the trasnperancy of the glass. ) may be some light can be shed on this new development

    • This course is a good overview of Solar power systems basics. Inclusion of some more details on the suitable battery technology and the charging techniques will be appropriate.

    • Before we can understand this fourth semaphore and its importance in the multi-core systems, the readers will be interested to know how an RTOS , which is mainly designed for a single core multi-tasking operation, is extended to support the multi-core architecture. Since the multi-core architecture is a distributed architecture, how is resource management done? Is it done by running a copy of RTOS in each core and they in turn competing for common resources such as shared memory, I/O etc through the use of semaphores. Can some expert elaborate on this?

    • I thoroughly enjoyed this article as it represents an era where the Embedded software developers could really write the code bit by bit and know each and every bit in the EPROM or EEPROM they programmed. They could even patch the code by just modifying a few bits in the EPROM programmer memory and reprogramming the EPROM. Today with advanced tool sets and higher language support available the Software engineer has moved away from those bits and nibbles. In 1974 when India did not have a free access to the latest technology I remember to have worked on a 12 bit computer which had piano switches along with LEDS on its front panel. The Program had to be first coded in 12 bit binary machine language and had to be fed into the computer memory using thse piano switches. Once in the memory you had the luxury of getting it punched onto a paper tape. The debugging was done using a single stepping switch and watching the LEDS for the correct binary output.

    • Porting of existing applications onto the new multicore processor architectures is not an efficient way of using this powerful hardware. A grounds-up approach is required to provide an integrated development environment for such hardware platforms. To use the software already developed for older architectures the best approach would be to build a generic software layer over and above the OS and below the target applications to take care of those endian and other architecture specific problems. Such emulator software should solve the porting problems

    • I foresee one big application area for home appliances. Internet can be used to control all the home appliances in a given home by the person's mobile phone. The control software in each and every appliance can be totally eliminated and the drive electronics ( say the motor movement in a washing machine) can be driven by the mobile phone acting as the UI and the control logic in a internet server of the manufacturer ( say for example Samsung) interpreting the UI commands coming from a specific washing machine to send the specific drive commands thru' the internet medium. With the gigabit internet all this will happen so transparently that user has a feeling of controlling his appliance from his mobile . This way a lot of local control electronics in each appliance can be eliminated resulting in huge cost reductions for the manufacturers

    • This is a very useful paper which gives enough information for the first-timers in BLDC motor application field to give it a try. BLDC sensor based control is much simple as it only requires a small look up table to control the direction and spped of BLDC motor. The sensor less control however simplied it has been shown in this paper is software intensive solution. The first timers in BLDC should first try to build the sensor based controller and then venture for sensorless controller

    • This paper looks to be a very concise introduction to MIxed signal SOC design. I have a query to the author. I heard a couple of years back that Analog FPGAs are now available. Does this make the in-circuit-emulation of Analog, or for that matter the mixed signal SoCs in real time ( by combining Analog and Digital FPGAs to simulate the complete mixed signal SOC) Socs in real time, possible ? Does Cadence provide tools to trasfer the mixed signal design into Analog and Digital FPGAs?

    • I think such a product was long overdue. And what with the new Internet addressing protocols ( with enhanced address space) this could be a boon to the chip designers as they could easily swithc over to the upgrades.

    • This paper is a very cursory attempt to give insight into the BLDC motor control technique for e-bike application. The application notes by controller manufacturers such as micro-chip explain it more succinctly. Even the truth table for the motor direction control is missing. I expected a much detailed discussion on the control techniques especially sensor less control of BLDC motor

    • This paper by Mentor Graphics is a short and simple overview of USB. Came USB and all those engineers who struggled with those 9 pin and 25 pin RS-232 interfaces and using serial multiplexers to attach multiple serial peripherals , heaved a sigh of relief. The best visibility of USB was seen when those sleek Pen drives appeared in the market and the marketing executives no more required to carry their heavy laptops and bunch of CDs to give presentations to their customers. Just carry a Pen drive like a key chain , hook it to your customers Lap-top and there you go. This standard has definitely a much longer life. No wonder tomorrows home appliances may have a USB port and you could download Micowave recipes , washing machine programs using a pen-drive.