RoadTest: Seeking an Engineer to Evaluate Infineon's PSOC 4100T Plus Prototyping Kit
Author: MATRIX7878
Creation date:
Evaluation Type: Development Boards & Tools
Did you receive all parts the manufacturer stated would be included in the package?: True
What other parts do you consider comparable to this product?: Any microcontroller with analog capabilities
What were the biggest problems encountered?: Communication with board and community on Infineon support
Detailed Review:
INTRODUCTION
If you have an awkward family member you would rather not be around, but do still love them because they are family, you have the PSoC 4100T Plus CAPSENSE Prototyping Kit. This microcontroller is a respectable microcontroller, but you need to have a long time to warm up to it. Compared to the several other microcontrollers, FPGAs and other similar products I have used, the Infineon 4100T is a MCU that has its uses but is not the go-to. The board itself is rather freaky and fragile looking, the IDE has the wrong features and it has a laundry list of improvements (in my humble opinion) that I would change if I could. Alright, that's enough complaining, let me break it down for you. If you do not want to read and would rather just watch, you can go to the end of the review and you will find a YouTube video explaining and showing everything (minus the unneeded headaches) I went through. FYI, it's just under hours. This review goes deep and does not hold back anything, just making you aware.
HARDWARE
The board came in a see-through box with the microcontroller and a second touch glass cover that has a sticky side to attach to one of the wings. No cable but I have plenty of USB-C cables. The package is rather secure and took quite a lot of force to open. The glass is nothing special, just a 3 mm overlay. I did not use it as there were already glasses on the wings. The PCB itself is rather slim and is about the same width as a standard package that goes on breadboard. From left to right, there is a small square with the debugger/power connection and boot mode button. The board uses a standard USB-C connector and plugs into a PC/laptop with the cable. The boot mode button changes the MCU from a, well microcontroller, to a file system. Inside it contains a text file of information about the MCU, including its unique ID. To change, the MCU must be plugged in, status LED on and then the button pushed. To go back to MCU mode, the button needs to be held a little bit (1-2 seconds). From there things get weird. On the other side of the debugger, there is a break in the PCB. When I saw the image of the MCU online, I thought it was a noisy image, but no. There are 7 thin connectors holding the debugger to the rest of the board (with the actual 4100T itself). All the connections, power, ground and signals, are in these 7 pegs. Just looking at it, I can tell you that there is a high chance of snapping the board if something happens to the PCB. It seems like it is almost designed to be broken off. Is that true, most likely no. Despite how it looks, there are several 2.54 mm pin holes for pins. There are also holes for a USB to other protocol (UART, SW, I2C) programmer. I see it as two possibilities:
Moving on, the board has a rather flat design. There are two buttons, reset and user; some LEDs; a jumper for power; the light sensor and the MCU. That is about it. There are some passives, but overall, a flat looking board. Again, there are strange things on this board. The two capacitive wings are connected to the main PCB via 4 (on the top) and 7 (on the bottom) little legs. You hang a wing over the edge of a table and you push hard, you could break a wing. I'm sure the little connectors are strong, but they do not imbue confidence. There are little legs (rubber feet) on the bottom of the entire thing, so it is stable, but do not hang any wing over, or you risk breaking off a sensor. The top sensor is a 2-button capacitive attachment. One is a square button and the other is a circle. The square has a H in the middle of it, so it would imply that it is a hover sensor, but no. There is a 3 mm overlay on the top wing. It can detect your touch on the bottom of the wing too, showing that the capacitance touch does work omnidirectionally. The bottom wing has a thinner ~1 mm overlay that has a proximity sensor capacitive touch panel, just like the top, it will sense you if you approach from the bottom. At the very end of the PCB, there is a 24-pin connector to attach additional sensors.
This was only half of the products I received. In addition to the 4100T, I received the 4000T, the older sister variant. This board was not part of the review, so I will only touch on it. It came in a much bigger box as it has several other parts. The box has a small magnetic flap to open and close and was damaged in transit. Inside the box there was the 4000T; a 2 capacitive touch button board with inductive touch sensors on the bottom for metal sensing; a 4-button variant of the 2; a hover sensor with plastic cover; a liquid level capacitive sensor with bottle and USB-C cable. All sensors excluding the liquid level sensing one have LEDs to demonstrate a sensed connection. Each of the sensors with the KitProg 3 (the 4000T) has a 24-pin connector for simple connection to the 4000T, or 4100T.
SOFTWARE
I did not do any Linux work, only Windows work. I'll talk about the IDE, programming the board and associated things later on, right now, I'll be talking the default program on the board. Right out of the box, first program booted up seems like a great way to understand everything you have to work with. Every connected sensor, that is not a 24-pin jumper, and every LED is used. The top capacitive buttons will brighten up a LED when it detects a touch present. The MCU sends out a PWM signal to the LED for its brightness control. For the bottom wing, the lights will brighten/dim when it detects your presence, within an inch (2.54 cm if you don't speak American) or so and where on the pad you are touching. Ergo, when I approach the wing, the LED closest to that corner will get brighter and as I move away, the light will dimmer. The light sensor, or Ambient Light Sensor (ALS), will dim the always on LED depending on ambient light. Cover the sensor and the light goes almost out. It still has a few electrons passing through. This leads into the one flaw I saw with the demo. While it works, the LEDs are not always accurate to the amount of pressure being applied, nor to the exact position. I can approach the bottom left corner, but the upper right corner LED will come on too. Not fully bright, mind you, but still on. I will note that it seems like the upper right LED is supposed to come on when you are within proximity of the sensor, but outside the physical bounds. The worst part I would say, keeping in mind it is an intended feature, is that the bottom wing is unbelievably sensitive. If I want to approach the reset button, I need to be careful on my angle of approach as it could lead the bottom wing to come alive. Resetting the board on any issues was annoying as I could make the sensor think I was trying to interact with it, despite not wanting to. That is the encompass of the preprogrammed code. None of the 24-pin sensors were programmed as they are two separate kits. You have to buy both to get what I have.
Starting off with the IDE, the most foolish part is that I needed to wait 30 seconds AFTER I hit the download package balloon on the download cite to have the download start. To answer the question, you are most likely asking yourself, no, if you flip tabs to do something else, the download counter will not tick. If the countdown timer is not front and center of the screen, it only increases the delay you have to wait. The timer does not go up, but it does not go down. I'm sure it is to ensure bots do not download the software but come on. This is ridiculous. After that, the process was straightforward and normal. Exploring the IDE (Eclipse), it looks exceedingly similar to Texas Instrumentss' Code Composer Studio. This flavor though does have some nice features that TIs' CCS does not. The biggest one is an auto-commentor feature. If I write a function, loop, conditional, or anything that involves curly braces, it will add a comment at the end giving a brief explanation of what is happening. The IDE also comes with the hardware support package for faster coding and fully ready demos. It would be nice of course if you could do those demos immediately. The process you have to undergo involves pulling teeth.
PROGRAMMING
This is where the real nightmares started. I have used several microcontrollers during my time in engineering. Ranging from the TM4C12xxxx family, Arduino, ESPxx family microcontroller group, to the FPGA of GoWin, SoC of Xilinx and Raspberry Pi and its other variants, all their programming schemes were rather straightforward. For all associated IDEs, download, write something, compile it, upload. The Eclipse for ModusToolbox (MTB) IDE is not as helpful. My first major hurdle was trying to program the demo code for the two-button add-on card. I tried debugging it, I tried attaching, also known as running, and nothing worked. I looked up the documentation. The datasheet said I needed to use the programmer. Okay...where is that? Well according to Infineon (whom I contacted several times during this RoadTest) it should have been installed with the IDE. To my surprise (not) it did not. Just writing this review right now is making me upset as it brings back the memories of trying to get the most needed and basic function of ANY IDE. I finally got the link to the programmer and installed it, again facing the 30 second hurdle. Once again, the job was not done. I had to connect the programmer (which did work as I tested it before connecting) to the IDE by telling MTB where the executable was. Huzzah! I could now program the board from the IDE. Interestingly enough, after connecting the programmer .exe to the IDE, the desktop shortcut stopped working. Why, I don't know, but I also do not care as I do not plan on using it as a standalone product.
Opening a demo is simple enough and the IDE can auto detect the MCU if it is plugged in. There are several programs for demo programming in several categories:
Depending on the size of the selection, it will take some time (10-60 seconds) to set it up in the IDE. Why? because it has to download everything from...GitHub? As is seen in the video, there are a lot of git clones being done. I imagine this is to minimize the amount of data being installed with the IDE, but the installation to setup the demo code takes quite some time to complete. To be honest, this is the only real issue I have with the whole process of setting up a project on the IDE side. I'll get to the rest of the issues I had in a minute. The README file opens up immediately after the program is installed in the IDE. There was a lot of information there and I go over it in the video. After building the project, and yes, the button (hammer usually) can disappear depending on what you are clicked into, it was time to program the board. There were two options for this: debug or attach. Debug was for normal debugging and attach just meant run the code. You could not just hit the widget at the top and expect it to work, you had to go through the configuration for programming the board and set a couple things up. When that is complete, then the program can be uploaded to the MCU. It is just like any other MCU then and the board is programmed and ready for use. An additional issue I had was that to access some functions (build, other apps) the project must be selected in the project explorer. Somehow, the project must be clicked on and active. It is easier to see this in the video. Moving on then to the actual demos.
APPLICATIONS
From the flashed-on demo, the 2-button add-on board was first on the list. Connecting the boards is straightforward, have both boards facing up and connect. Once the boards are connected, then the MCU can be plugged into the computer. As I've already mentioned the programming .exe, the length of setup and the confusion of which way to program the board, I'll jump right into the actual board. On the top, there are two metallic capacitive touch buttons; on the bottom, two inductive touch pads. The top buttons are for your finger, the bottom are for detecting metal. Capacitive touch buttons are supposed to be really easy to touch and activate. I had to push rather hard to activate the buttons. The demos' README does not say anything about pressure. The name of the sensor is inductive and, on the bottom, I can move metal objects in the coils path and get the LED to turn on. On the top, no metal will trigger the LED. I have to push to get a reaction. This led me to believe that it is simply inductive on the bottom. While this may be true, I do not think the sensor truly knows what it is trying to do. If I push with my finger on the bottom, I can, I guess, glitch the sensor and the LED will remain on. I have to reset the board to get it back to normal. This is not a joke, or a setup, it is what happened to me. No, there is no metal in my finger. It is almost like I disturb the sensor enough to make it sense itself. I am not quite sure. Perhaps I am pushing the sliver of metal on the top into range of the bottom sensor. The 4-button is the same story as the 2-button, so I'll move on.
Next up was the hover board. This was an interesting one as I did not have any problems with it. It is a sandwich styled add on with a plastic cover on top to indicate points of contact, the sensor in the middle and the MCU connection and on the bottom a support structure. The top layer is the exact distance before the sensor detects you hovering. Upon measuring the distance, it is about .5 in, or 1.27 cm difference. The last sensor was the liquid leveling sensor. Ok, I'll admit it, I was an idiot here. The sensor did not have any attachment instructions, just the sensor and the bottle. What does my brilliant mind say to do? put the sensor IN the bottle. Yeah, that's not what you do. Not only does it make the sticky substance rub off, but you have to really bend the sensor to get it in and when it is, it does not unfold very well. It is getting chocked by the neck of the bottle. After getting it out, and kicking myself in the butt, I put the sensor correctly on the outside. I filled up the bottle and tried to make a reading. Now was when things started going downhill again; more like free fall with the wind pushing me down faster. The other sensors were all contained within the hardware itself (LED based). There is a LED used for the liquid sensor, but it only comes on at around 1/2-2/3 full container. The READMEs for the demos talked about using a virtual environment, but I decided to do that last. The liquid sensor was a bit different.
There is another environment (called CAPSENSE Tuner) that, from my understanding, should be installed with the Eclipse MTB IDE. It was either installed with the IDE, or the more likely programmer application. Ok, just tell me where to find something and I'll use it, whatever. I tried to connect my device (the 4100T) to it. You tell it to use I2C and then the two should communicate. Just my luck, they did not. I was on with Infineon support for a few weeks trying to figure this out. While I was waiting for a solution, my account was banned. No rhyme, no reason, I just could not log in one day. I had to communicate with Element14 here to get me unbanned. Infineon said that they did not know who banned me, or even why. That took up a couple days. After I was unbanned, I continued trying to debug with some other programs for testing the communication. After about 2 days of no response a few days after I was unbanned, I did not hear anything from my tickets. I log in and see that my responses were not there. Strange I thought and I try reposting. Something tells me to be careful; I refresh the page and the response is gone. On all my tickets, my responses were being auto deleted by the system. Again, I went to Element14 to get this issue solved. After it was, I finally got my MCU problem fixed. It turns out, to use the tuner app (which is the GUI version of the sensor reading) you need to launch it from WITHIN the IDE. You cannot launch it separately. Why you ask? because there is a checksum that needs to be found and compared. No checksum, no connection. Once again, nothing ever told me that, I had to find it out myself after weeks of trying to know what was going on. When I had everything set up, I tested the liquid sensor out. It was quite accurate for sensing the liquid. I could see in the GUI the real time data in the form of a bar graph overlayed on the segments on the inner (sticky side) of the sensor.
Alright, now all sensors have been tested and I can see that they all work as they should. A few issues here and there, but these are not the highest of quality sensors. Now was the time to go through the whole README file and try each one for each sensor out. Since I had the liquid level sensor attached, I decided to run through that one. While I wish I could zoom out in the IDE displaying the README, I can ignore it. The instructions are rather straight forward to begin with. Just open up the tuner and see how things interact. Then there were some calibration steps. Repeat a few times with different settings, but nothing too extreme. Eventually I got to a step with something that did not make any sense. There was a section on voltage reading. It did not say what was being used, or what app to use. There was just a plot. I deduced that it was an Oscilloscope. Was that ever mentioned, no. After I finished the rest of the steps, skipping a few things that I did not have the materials for, or did not understand as it was rather hard to understand, I tried the sensor again. It turned out that I tuned the sensor so much that it could not sense anything. I do not know what I did to break the sensor, but after following the calibration steps and ignoring the things that had nothing to do with the calibration, the liquid sensor only read 0%, 0mm (couldn't do mL as it can't really tell volume of water, only height). The sensor still works, just not after the calibration. I moved on then to the 2-button attachment and this one had the same aspects. I could push a button and see a bar move up based on my pressure. What about the inductive coil on the back? What have you learned so far about my luck? While the LED on the board itself lit up, the bar for the sensor was not moving. The sensor itself could read it, but not the software. Well, that is most certainly not something I want to see after all my issues. I decided, you know what, hopefully the calibration steps fix it. They did not. Unlike the liquid sensor, I did not break this sensor. Everything still worked as intended, minus the inductive sensor of course. I was wondering why the tuning/calibration steps were after how they told you to run the demo, but maybe they intend for you to ensure it works before it fails to work. Of course, I could have missed something, but without any live help on how to do this, I can only go with what I know and have done. The 4-button README has essentially the same steps as the 2-button and I had the exact same results happen.
Lastly was going back over the hover sensor. One more time, went to the README and followed the instructions. I went through all the tuning processes it said and while nothing really seemed to change, it was at least interesting to see everything that I could change to "tune" it. I do wish that they did re-read their documentation as somethings were not clear, some did not make sense and it overall did not seem like a complete document. Once all the software was tested, I decided to see what was "under the hood". Essentially, I just undid the sandwich. The top layer is the point of first contact. Any higher than the board and it cannot read you. All the electronics were on the inner board. The bottom board was interesting. It was a solid ground board. Did it say what it was, yes. Did I foolishly glance over it without sending the words through my brain to comprehend, yes. While I was trying to figure out the point of it, I played around with the middle board. I plugged it in and the topside worked as intended. The bottom side was certainly not made to be touched. Interacting with the bottom can cause erratic LED behavior, hence probably why the ground board is there. It blocks the signals on the bottom and reflects them back to the top for you to get read. It's easier if you watch the video than me try to explain the behavior. After playing around, I decided to reassemble everything. At least nothing broke when I did that.
CUSTOM APPLICATION
#include "cy8c4147azq_t495.h"
#include "cy_gpio.h"
#include "cy_pdl.h"
#include "cy_scb_uart.h"
#include "cybsp.h"
#include "cycfg_pins.h"
#include <stdio.h>
#include <stdint.h>
#define NUMSAMPLES 2
cy_stc_scb_uart_context_t CYBSP_UART_context;
struct point{
int16_t x, ///< state variable for the x value
y, ///< state variable for the y value
z; ///< state variable for the z value
}; typedef struct point point;
const cy_stc_gpio_prt_config_t PORT2_init_struct =
{
.dr = 0x00000000u, /* Initial output data for the IO pins in
the port */
.intrCfg = 0x00000000u, /* Port interrupt edge detection
configuration */
.pc = 0x00DB6DB6u, /* Port drive modes and input buffer enable
configuration */
.pc2 = 0x000000FFu, /* Port input buffer configuration */
.selActive = 0x00000000u, /* HSIOM selection for port pins */
};
point p1;
uint8_t _yp, _xm;
uint16_t _rxplate = 300;
struct point TSPoint(int16_t x0, int16_t y0, int16_t z0) {
p1.x = x0;
p1.y = y0;
p1.z = z0;
return p1;
}
static void Initialize_UART(void)
{
cy_en_scb_uart_status_t initstatus;
/* Initialize the UART */
initstatus = Cy_SCB_UART_Init(CYBSP_UART_HW, &CYBSP_UART_config, &CYBSP_UART_context);
Cy_SCB_UART_Enable(CYBSP_UART_HW);
}
void PWM_initialisation(void)
{
/* Initialize PWM block */
(void)Cy_TCPWM_PWM_Init(CYBSP_PWM1_HW, CYBSP_PWM1_NUM, &CYBSP_PWM1_config);
/* Enable the initialized PWM */
Cy_TCPWM_Enable_Multiple(CYBSP_PWM1_HW, CYBSP_PWM1_MASK);
/* Then start the PWM */
Cy_TCPWM_TriggerReloadOrIndex(CYBSP_PWM1_HW, CYBSP_PWM1_MASK);
}
uint16_t analogRead(uint16_t ain, int chan){
/* Start the continuous conversion */
Cy_SAR_StartConvert(SAR0, CY_SAR_START_CONVERT_SINGLE_SHOT);
/* Wait till the sample is ready */
Cy_SAR_IsEndConversion(SAR0, CY_SAR_WAIT_FOR_RESULT);
ain = Cy_SAR_GetResult16(SAR0, chan);
return ain;
}
struct point getPoint(void){
int x, y, z = 0;
uint16_t samples[NUMSAMPLES];
uint8_t i, valid;
valid = 1;
Cy_GPIO_SetDrivemode(XP_PORT, XP_PIN, CY_GPIO_DM_PULLUP);
Cy_GPIO_SetDrivemode(XM_PORT, XM_PIN, CY_GPIO_DM_PULLUP);
Cy_GPIO_SetDrivemode(YP_PORT, YP_PIN, CY_GPIO_DM_HIGHZ);
Cy_GPIO_SetDrivemode(YM_PORT, YM_PIN, CY_GPIO_DM_HIGHZ);
Cy_SysLib_DelayUs(20);
Cy_GPIO_Write(XP_PORT, XP_PIN, 1);
Cy_GPIO_Write(XM_PORT, XM_PIN, 0);
for (i = 0; i < NUMSAMPLES; i++)
samples[i] = analogRead(_yp, YP_PIN);
if (samples[0] - samples[1] < -4 || samples[0] - samples[1] > 4)
valid = 0;
else
samples[1] = (samples[0] + samples[1]) >> 1; // average 2 samples
x = 1023 - samples[NUMSAMPLES/2];
Cy_GPIO_SetDrivemode(XP_PORT, XP_PIN, CY_GPIO_DM_HIGHZ);
Cy_GPIO_SetDrivemode(XM_PORT, XM_PIN, CY_GPIO_DM_HIGHZ);
Cy_GPIO_SetDrivemode(YP_PORT, YP_PIN, CY_GPIO_DM_PULLUP);
Cy_GPIO_SetDrivemode(YM_PORT, YM_PIN, CY_GPIO_DM_PULLUP);
Cy_SysLib_DelayUs(20);
Cy_GPIO_Write(YP_PORT, YP_PIN, 1);
Cy_GPIO_Write(YM_PORT, YM_PIN, 0);
for (i = 0; i < NUMSAMPLES; i++)
samples[i] = analogRead(_xm, XM_PIN);
if (samples[0] - samples[1] < -4 || samples[0] - samples[1] > 4)
valid = 0;
else
samples[1] = (samples[0] + samples[1]) >> 1; // average 2 samples
y = 1023 - samples[NUMSAMPLES/2];
Cy_GPIO_SetDrivemode(XP_PORT, XP_PIN, CY_GPIO_DM_PULLUP);
Cy_GPIO_SetDrivemode(XM_PORT, XM_PIN, CY_GPIO_DM_HIGHZ);
Cy_GPIO_SetDrivemode(YP_PORT, YP_PIN, CY_GPIO_DM_HIGHZ);
Cy_GPIO_SetDrivemode(YM_PORT, YM_PIN, CY_GPIO_DM_PULLUP);
Cy_GPIO_Write(XP_PORT, XP_PIN, 0);
Cy_GPIO_Write(YM_PORT, YM_PIN, 1);
int z1 = analogRead(_xm, XM_PIN);
int z2 = analogRead(_yp, YM_PIN);
if (_rxplate != 0) {
// now read the x
float rtouch;
rtouch = z2;
rtouch /= z1;
rtouch -= 1;
rtouch *= x;
rtouch *= _rxplate;
rtouch /= 1024;
z = rtouch;
} else
z = (1023 - (z2 - z1));
if (!valid)
z = 0;
return TSPoint(x, y, z);
}
int main(void){
int pressureThreshhold = 10;
cy_rslt_t result;
/* Initialize the device and board peripherals */
result = cybsp_init() ;
if (result != CY_RSLT_SUCCESS)
{
CY_ASSERT(0);
}
Initialize_UART();
result = Cy_SAR_Init(SAR0, &pass_0_sar_0_config);
if (result != CY_SAR_SUCCESS)
{
CY_ASSERT(0);
}
Cy_SAR_Enable(SAR0);
PWM_initialisation();
Cy_GPIO_Port_Init(GPIO_PRT2, &PORT2_init_struct);
while(true){
char buff[3][32];
p1 = getPoint();
if (p1.z > pressureThreshhold){
Cy_SCB_UART_PutString(CYBSP_UART_HW, "x = ");
sprintf(buff[0],"%d", p1.x);
Cy_SCB_UART_PutString(CYBSP_UART_HW, buff[0]);
Cy_SCB_UART_PutString(CYBSP_UART_HW, " y = ");
sprintf(buff[1],"%d", p1.y);
Cy_SCB_UART_PutString(CYBSP_UART_HW, buff[1]);
Cy_SCB_UART_PutString(CYBSP_UART_HW, " z = ");
sprintf(buff[2],"%d\n\r", p1.z);
Cy_SCB_UART_PutString(CYBSP_UART_HW, buff[2]);
Cy_TCPWM_PWM_SetCompare0(CYBSP_PWM1_HW, CYBSP_PWM1_NUM, p1.z);
}
}
return 1;
}
#include "cy_pdl.h"
#include "cybsp.h"
void PWM_initialisation(void)
{
/* Initialize PWM block */
(void)Cy_TCPWM_PWM_Init(CYBSP_PWM0_HW, CYBSP_PWM0_NUM, &CYBSP_PWM0_config);
/* Enable the initialized PWM */
Cy_TCPWM_Enable_Multiple(CYBSP_PWM0_HW, CYBSP_PWM0_MASK);
/* Then start the PWM */
Cy_TCPWM_TriggerReloadOrIndex(CYBSP_PWM0_HW, CYBSP_PWM0_MASK);
}
uint16_t ALS_reading()
{
uint16_t adcResult = 0;
Cy_SAR_StartConvert(SAR0, CY_SAR_START_CONVERT_SINGLE_SHOT);
if(Cy_SAR_IsEndConversion(SAR0, CY_SAR_WAIT_FOR_RESULT) == CY_SAR_SUCCESS)
{
adcResult = Cy_SAR_GetResult16(SAR0, 0);
}
return adcResult;
}
int main(void)
{
cy_rslt_t result;
/* Initialize the device and board peripherals */
result = cybsp_init() ;
if (result != CY_RSLT_SUCCESS)
{
CY_ASSERT(0);
}
/* Initialize the SAR ADC with the device configurator generated structure*/
result = Cy_SAR_Init(SAR0, &pass_0_sar_0_config);
if (result != CY_SAR_SUCCESS)
{
CY_ASSERT(0);
}
Cy_SAR_Enable(SAR0);
PWM_initialisation();
for (;;)
{
Cy_TCPWM_PWM_SetCompare0(CYBSP_PWM0_HW, CYBSP_PWM0_NUM, ALS_reading());
}
}
Now for something a bit more interesting. Everything up to now has been something that Infineon has made. It was time I made my own C code. I was trained and love using DRA coding. This means that when it comes to programming any device, give me the actual registers and the proper usage and I will write you code. I cannot stand using pre-written code that is nicely packaged. It sounds silly, but why? Simply put, if I have access to the actual addresses, I can see exactly how something works and I'll know for a fact what I am typing. Sure, the packaged code has function names saying what it is, but that's not fun. With the hardware support packages, I have to look-up the functions, all the things I can input to it, what it outputs and if it is actually what I need. It allows for fast coding, but no freedom. It is exceedingly restrictive and can make coding harder for me. This is the default for Arduino's as all one has to write is "digitalWrite(pinNum, value)" and it is done. No need to say GPIO_PORTx and GPIO_PINx, listen to me and write what I say. It makes it all simpler but makes me have to look up more than just a datasheet. This is the biggest issue I faced. I had to find examples in the demos to know what I needed and everything I could put into the function. There were registers and addresses I could have used in a tucked away datasheet, but no example/order of operations for me to follow to know what I had to do. The next step was the easiest I had: find out which pins do what and their number on J24. After Googling the pinout and pin functions on two separate datasheets, I could locate the pins on the connector and wire it up. To the IDE and example codes to program the MCU.
Starting with the easier custom application since I had already written code before for it, I wanted to create 4100T code for my resistive touchscreen. The one I use is this: adafru.it/2050. Adafruit has GitHub repos dedicated to a lot of their tech. This screen is no different. I translated the Arduino code from the Git to my TM4C129EXL years ago, so moving it one more time to the 4100T should not be a problem. While I knew what I needed to code, my issue was knowing if it was possible. The touchscreen has raw analog pins and the pins on the MCU need to switch between analog and digital mode. This entails switching pin modes dynamically. Can the 4100T do this? I would not doubt it, but always good to make sure. Fortunately, it is capable of doing that. While there are of course no specific guides for everything one wants to do (no one can predict what the next person will program), luckily there are enough demo codes already built by Infineon that help give me a starting point. I started off by opening up several other demos and copying and pasting code. I moved over header files, functions, variables and then arranged everything so it would work for me. Let me slow down a minute actually. Due to the nature of everything, I had to make sure that what I was doing would actually work. Ergo, I tried building some of the copied code. Here comes another problem just over yonder hills, things are not defined. Just like what I said above about needing to know what lines of code I need can make things complicated. I had to open up another demo to try and find the code and its uses. Fortunately, there are Doxygen documents that help give some guidance that were sent to me. Ok, code seems right, but why am I getting errors? I matched the pins and alternate functions. What am I missing? Well just like a boomerang, the problems keep coming back.
Remember up above how I said that there was a GUI that I needed to use for checking out what the sensors are really seeing and another .exe for the programmer, well there is a third application that is needed. I realize there is a learning curve for any new technology, but I was not expecting an asymptote. It turns out that the needed functions, classes, variables, etc. are not natively in the header files, there is something called the Device Configurator and that is needed to actual setup everything. Think of it as the GUI version of assigning names, pins and functions. It is designed to make your life easier but only can if you know it exists, which I did not. Once I learned that this thing existed, I had to find out how to use it. Once Infineon helped me through explaining the app existed, I was able to find the app in the (hidden) quick panel. Once again, you start it up through MTB and that loads the program into the configurator. Once all the setup for the pins are complete, you save and copy whatever class/port/pin names it spits out and put that into your custom C application. Once I did that, my errors started to dissolve. Long story short, you cannot just copy and paste the example code from a pre-written demo to a brand-new C project. There is setup for it; you can see why I prefer my method of coding now. In the GUI, the known GPIO pin usages (LEDs, button, etc) are already named. For the other pins, I can name them whatever I wanted and then assign the clock and default values. The source code will then update itself and auto update MTB. After fixing the code again and completing the set up in the GUI, I could touch the screen and have something happen. You'd imagine I'd be happy, and I was, but it took too long to figure out what to do and it was not very accurate. It worked though and that is what counts. I tried using a LED as well to say the pressure on the screen, but that certainly did not work. This part though I am willing to let go as I was using a class to hold data and am not sure that the data was able to get read right to the PWM.
The second custom C code I built was a light dimmer for my HX8357D 320x480 touchscreen. I knew that the ProtoKit has a light sensor on it, so naturally, this is the ideal trigger for a PWM signal. I was going to use the actual register code, but again, due to the nature of the available datasheets, it would be very difficult (or at least exceedingly time consuming) to backtrace everything in the hardware support packages to know exactly what to do. As usual, my personal opinions get in the way of speed. I'd rather know what I'm doing and what is happening than just do it. I opened up the demo code that came with the board, located the needed functions and began copying and pasting. Okay, now I have a fully written code that reads the data from the ALS (P2.7), which was already named by default in the device configurator, enabled pins, linked the PWM to the output pin and I am ready to send it out to the "LITE" pin on my LCD. One main annoyance I had though going through the entire process above was that the IDE is very picky about the project selection. You cannot simply click on the main.c file that is open, you have to go to the project explorer and actually select the project header and then go into the configurator. A weird step, but nothing that makes me pull my hair out. Program the board now and SUCCESS!!!! I was able to power the screen, and be careful as there are three pins labeled as voltage references, but only one of them is capable or supplying power, and control the brightness of my screen. Well, that made me happy.
CONCLUSION
If you have used any microcontroller in the past, you know that they come with a berth of peripherals. If you need UART, it's there; PWM, sure no problem; bit-banging your own program, bleeding edge, but feasible. If you need a plethora of ADC, you will need to be more selective. An MCU built for this is the PSoC 4100T by Infineon. It has plenty of 12-bit ADC peripherals and even has special sensors built on the PCB. If you need more, there is always a 24-pin connector for a slew of add-on boards you can plug in. If you need simplicity of creating a large ADC system with capacitive/proximity sensors, this is the board for you. Getting it all set up though and ready to go will make you question if the decision was worth it. From the waiting times to download the software, to the order you open applications up, there are a ridiculous number of steps needed to have a starting point. Once the board has all the software ready to use, it is simple process, but there are no clear answers to all your questions. I had to go to the Infineon forums a lot. If they had more/better documentation, that did not skip any steps or leave something out, then I could rate this experience higher. In addition, I have never seen a PCB with the same style support structure as this MCU. It is freaky and makes me worry that I will break it if I accidentally hit it wrong. To be completely honest, taking everything into account, I give the entire time I spent on this a 5/10. It has a purpose and has more "built-in" sensors than most boards I know/have used, but the set up and design of everything makes me wonder why they chose the path they did and if they actually proof-read/thought about things. TL;DR: here is the video I promised: https://youtu.be/xLBK4xKgZ6M
Top Comments
Ooops, that's embarrassing, forgot to make the video public. Fixed.
MATRIX7878 I respect your candor. Since it's a prototyping kit, I'm not as concerned about the design of the boards and their arrangement - or physical robustness. The IDE, et al, however... sounds…
kmikemoo , I understand your skepticism and appreciate your words. I agree with what you say about the prototyping kit.