Hello,
Its been some time since the last update to be exact 2 weeks. Lots of progress and some roadblocks that I will be discussing later on.
First for Time line of Stage 3:
Stage 3: Interfacing
- Prerequisite for this stage is the arrival of all Element14 ordered material on-time
- Wiring Up
- Connect all the Shields and test individual interfaces
- Check for Capacitive Touch sensitivity and user interface using cap-sense interface prepared earlier
- Remaining Software trials
- Check for Sounder operation with controlled DC-DC activation
- LCD tested for working with SD Card Driver + Font updates
- SD Card driver - Fully tested for Append File, Create, Read and Write file operations
- GSM - Need some work on designing the Interrupt based UART etc
- Missed Call alert working
- SMS Transmission is working
- Signalling State check is working
- SMS Reception not working
- Missed call Reception not working
- Implement the detection loops for the analog sensors - Done for LDR Sensor
- PIR Senor has interrupt issues - Need to redesign using timer based sampling
- Implement filter and frequency analyzer for the switched sensor inputs – Need more time for this so possibly would implement this in the next stage
- Implement the RTC interface
- Code Complete at driver level
- Host Interface - Unit Test cases done and passed
- LCD Interface - Unit Test cases done and passed
- SD Card Interface - Unit Test Cases done and passed
- GSM Interface (discrete) - Driver based on polling - Unit test cases only done for SMS Transmission , Signal Acquisition and Missed Call alert
- Sensor Interfaces working discretely need to integrate the driver and unit test cases for faults.
- Check for timing and synchronization for key events and fault scenarios – Most of the Fault scenarios are addressed, need to write software for them
As I progressed with the integration of the various modules and software drivers there were lots of optimization that needed to be added to the drivers to make them more singular in nature. After a while amount of code became some huge that the 32kb of flash for PSoC4 was not enough to contain the complete program in debug mode. As we know that in the Debug mode of PSoC Creator the Arm Gcc compiler stores all the debug into and does not fully optimize the code first hand integration in debug mode became difficult.
I applied some of the conventional tricks and finally landed up a software that was able to size up well even in debug mode. I will try to list some of these steps that helped me reduce code and have a more modular software:
1. Use constant arguments where ever possible in function API. This tells the compiler that you would not be modifying the argument inside the function and use it only for computation purpose.
2. Use of central general purpose / specific purpose buffers as global in specific modules instead of declaring them in stack (inside the functions)
3. Use of 32bit variables as the base - Optimizes speed and size as now registers can be directly used and bigger values can be printed
4. Use of global conditional Debug status prints that can be disabled at Module level or throughout the code.
Here is the Schematics without the GSM module:
Issue 3: SD Card on a Shield
The software integration progressed smoothly till the LCD interface. The unit test cases based on the features were tests also.
Integrating the SD Card was the first challenge. I will try to briefly describe the scenario and possibly it might help to realize the short comings while interfacing Shields with long pins.
In DAS as stated in my earlier update that there would would 2 shields on top of the PSoC4. Now in general Arduino shields come with long and high berg connectors with female on one side and a long male on the other. These connectors are quite useful in plug and play type of interfacing. But there is a small catch. If you use a 1inch contact on the edge connection then effectively the signal would be routed through a long trace of more than 2inches and also would be fully exposed to the external interference. In general analog or slower digital interface such as UART can do well. Higher speed interface such as SPI would land up into problem. And the long line would contribute to bigger impedance on the line. Hence this would put distortion based limits on the SPI line. The distortion would be jitter and slew contributed by the varying lengths. In my case this was the Adafruit Logging shield layout limited the rate to 4MHz. It can go up to 6MHz. However it took me time to realize this. In total I has tried the integration of various open source drivers that work in other microcontroller but could not figure out the reason that why these all were not working. So in the end I spent a lot of time just trying to figure out whats wrong with the software without thinking of the real prototyping issue. Finally I have integrate the modified driver from the PSoC4 100 Projects 100days Series - SD Card example. Since its license to use on PSoC devices so I found it easier to use for DAS. Although the famous Elm Chan's FAT FS would have worked but I did not have time to spend on that as I lost a considerable amount of time in debugging the SD card.
Road Block 1: Arduino GSM Shield
Now, I call this a road block as this would completely turn around my design up till now. Let me explain this in detail so that if some one has a work around this please suggest.
If we look at the schematics for the Arduino GSM Shield one can find that the GSM TX and RX are available on D3 and D4 pins of the Shield.
This means for the PSoC4 Pioneer Kit these are pins: P3.7 and P0.7
The problem with these two pins is that they are not on any SCB module pin locations hence these need dedicated UDB based UART to be assigned typically a Cypress UART v2.30 would do.
In case of DAS its already using considerable amount of UDB resources due to the SPI Master used for LCD and SD card. Hence the clash.
If I include the UDB based UART component then it causes errors and Digital synthesis doesn't allows proceed. Even configuring the uart to RX only and using a software transmitter would not be able to compensate for the UDB resources used.
Now there are two approaches to solve the problem.
1. The first approach would be knock out the SPI master and use a software based bit bang SPI. This approach would help to use the full UART based on UDB.
2. Use software only (timer based) Receive and Transmit modules, keeping the SPI intact.
Now each of these approaches has its own merits and demerit. I am bit in favor of going with the first approach, however I would like some suggestions on this.
Actually I have tested the first one but have not checked the bit bang SPI and its impact on SD card interface.
Here is the required GSM interface - of course without the other modules:
I have attached the complete project below with all the unit test cases integrated and full debug enabled.
One can try the integration of the UDB to see the errors.
I would request for the community support to help me resolve this blockade.
