Project Journal for Hunter Field
=============== Week 15: =================
Entry 6: -----------------------------------------------------------------
Date: April 25thStart Time: 2:15pm
Duration: 4.25 hours
Ran back to lab after a quick lunch and find that Cullen and Visuwanaath haven’t made a ton of progress but nothings broken. They said they thought they fried the LoRa breakout board. That would be heartbreaking today. Also, this is probably my favorite pic from this entire project.
We crammed everything into the case. There isn’t space for the LoRa breakout board inside so we wrapped the wires around the back and taped them. Kinda jank but it gets them out of the way. Here is the final device:
Presentation is in a few minutes and we are running tests like crazy jsut to verify everything still works. Visuwanaath also wired up the vibration motor to his PCB so we might give us the stretch PSDR if we’re lucky. Ok they're walking over to us AHHHHHHHHH.
We just did our demo and the LoRa didn’t feel like working so they gave us the OLED and Buck converter checkoffs but will swing back once we get LoRa working. We’re just sitting here after getting it working by yanking the wires or something. Idk it just started working again the second they left. Just our luck. I am telling Cullen not to touch anything because he can’t get his grimy hands off of the surprisingly functional LoRa wires.
Just redid the demo after a two hour wait and LoRa worked just as planned. 4/5 PSDRs and possibly the stretch ain’t nothing for this team to be ashamed of after all the shit we dealt with the past two weeks. Here is the final product.
Entry 5: -----------------------------------------------------------------
Date: April 25thStart Time: 10:45pm
Duration: 1.50 hours
Just got out of my exam in my morning class and on 2 hours of sleep I am drained. We STILL don’t have 9V batteries so I will run to Target to grab some. Am back now with 2 batteries. Plugged them in and they actually appear to work exactly like the power supply. Yay!
Cullen came in and did some soldering with my help to get the buttons working. No luck after all that. I have to go to class but we need to get all these wires wrapped up and shoved into the case ASAP for presentation in like 5 hours.
Entry 4: -----------------------------------------------------------------
Date: April 24thStart Time: 1:00pm
Duration: 11:50 hours
I am going to get the keypad hooked up to the PCB and get the alphanumeric code running on this micro. Got all the pins hooked up and code ported over. Wow it worked first try. Thats a first this week. Very much needed win in my book.
We need to get the buttons working. Cullen is drilling holes right now while I am setting up the interrupts for the buttons and playing around with their pinouts on the board. Assuming the buttons work properly we should be able to navigate the menu now. Cullen and Visuwanaath will go to Bechtel around 4:30 so I will work on the menu software while they are away. I’m hungry so I’ll go to Subway to work.
I’m at Subway and writing the state machine for our menu. Not really much to talk about, it’s just a huge state machine. I will head back around 6:30. Ok the entire beacon part of the menu is done. I want to wait before I do more to make sure we can even navigate what we have with buttons first.
Back in the lab now, and the other two are back. Sophie, who has been sick, just popped in and grabbed some stuff to solder, mainly the buttons. Cullen and Visuwanaath realized what I had feared. The LoRa module which was still getting powered was interfering with our RX pin coming from the breakout board. Visuwanaath scraped the trace until the chip could possibly send anything over it anymore. That fixed our issue and we can now send and receive exactly what we want every time. We snagged a TA to check off that we could interact with the LoRa module over UART, giving us our third and final PSDR. Cullen insists we need 2 hardware and 1 software at least but I checked the syllabus and the PSDR doc and it says “at least 2 hardware”. I am sure we passed ABET req but he is still freaking out about it. I know I’m right.
Cullen went up to check on Sophie. I am having more trouble with the OLED. Apparently it doesn’t work with one of our boards, but realistically we only need one to work to test the menu. I am working on the menu still and making some tweaks to the interrupts. We can only set 4 the way I’m doing it which could be an issue. However, I realized while i was writing the state machine that we never actually need to use the down arrow. Our enter button does everything that the down arrow would. This is cool because we only need to wire up 4 buttons to get all the functionality.
I went up to check on Sophie and Cullen because I hadn;t heard from them in an hour and a half. Sophie left and Cullen took over soldering buttons. The wires probably aren’t long enough that could give us trouble. He wrapped it up and we took the board and Case down to lab to start assembling it. Things will be a very tight fit. We barely have room for our OLED. Also, with this board, Visuwanaath realized that it only worked with the STLink plugged in. Just wonderful. This is gonna be a tight squeeze.
Things are coming together but we will wait until tomorrow to do the final assembly. Buttons do not work even after all the soldering. Damn. There is a missing resistor that is probably the cause of every button not working. Cullen is done soldering tonight. That's tomorrow’s issue.
We changed my code to automatically send the message after 5 characters to the other PCB Viswanaath frankensteined the LoRa module onto. WOW IT WORKS. We can successfully type out a 5 character message and send it.
Tomorrow we will need to get that checkoff asap and prep for the demo. In the past, things don’t like to work from day to day so I am praying they do just this once because this is so good for the demo.
Entry 3: -----------------------------------------------------------------
Date: April 23rdStart Time: 3:00pm
Duration: 7.25 hours
In the lab with Cullen today, the first thing we want to do is get another PCB hooked up so we can both debug the LoRa module not working. We can’t find the OLED cable in our box. Nevermind we are blind. We are trying different things but getting nothing back from our LoRa module at all. We know from Viswanath's testing that we are sending the correct characters because he used the oscilloscope to check yesterday. The DMA is set up properly but doesn’t seem to be receiving data properly, despite being triggered. It’s just all 0s.
I got fed up with trying to fix it withsoftware so I quickly probed the module and saw that the GND pin is 3.3V. Uh oh. I just probed the entire ground plane under it and it is all 3.3V. UH OH. Shivam just walked by and he thought our module was fried. Cullen’s setup has the same issue; this is probably a problem on all of our boards. All our modules are probably cooked.
Cullen and I sprinted up to prof. Walter's office and explained the issue. We looked through the PCB on KiCad and he agreed there shouldn't be an issue. He noticed it was out of date and the KiCad file on our website isn’t updated. Sophie really needs to update it. We've asked her many times to upload the recent changes. Anyway he also looked at our soldering and said it should be fine. He agreed to let us use the breakout boards because otherwise we could get LoRa working which means we can’t get any other PSDRs and then we can’t graduate. I hate that it has to come to this but at least we know the breakout boards work and we know how to send messages. We can just reuse existing code. Cullen soldered on wires to the TX and RX pins so we could start testing with the breakout board. We can’t get the module working on the first try so we are gonna take a mental break for a few minutes so we don’t crash out.
Visuwanaath showed up just as we got back from a Discount Den run. He got the oscilloscope ready to read characters again and we saw that we were in fact sending correctly. I’m worried that the 3.3V will bleed back into the TX and RX pins and disrupt transmission.
We created a quick breadboarding solution with the LoRa breakout board attached. Cullen and I realized that the TX and RX pins were swapped on the board. Sophie named them correctly we just interpreted the silkscreen labels wrong. We couldn’t get a signal. Cullen left for Volleyball elections just as Visuwanaath showed me what signals we were getting.
I don’t know why the 0 and 1 are almost the same voltage towards the start but it does get the job done. We are getting correct signals out of the TX and RX pins. We just confirmed that the module works and we are getting what we expect in our buffer. We can’t do anything else with LoRa tonight because we have a report due at midnight. Why did they schedule a report during the week of the demo. That is just inconsiderate to us.
I ran home where Cullen sent out what parts we wanted us to do. We finished the rough draft of the report in an hour flat. Honestly super impressive. We will need to make so much progress tomorrow with LoRa and start finalizing packaging.
Entry 2: -----------------------------------------------------------------
Date: April 22ndStart Time: 1:00pm
Duration: 6.75 hours
I really want to get the issue of displaying arrows figured out. I also just wrapped up some other screens. I think with the exception of the arrows not being displayed the menu is done.
I again tried displaying an image to the display but it just doesn't work. Same with the transformation issue, it might just be a verison issue which I can’t fix. For now I will just use the ( < ^> v ) text arrows which sucks but whatever.
I went up to the ECE shop to give Sophie some parts she asked to be brought up and ran into Niraj. I explained the STLink issues and booting problems we’ve been having for a while now and he offered to take a look. The first thing the team wanted to tackle with his help was the issue of the micro not running code that was in flash. We tracked the issue in debug mode which was getting caught up in one of the LVGL functions. We saw it was getting caught on a HAL_Delay which Niraj said shouldn’t be an issue. I don’t think so either as we have been using them a ton this semester with no issue. He recommended nano_wait but I don’t really want to do that. We eventually looked through the system_stm32l4xx.c file which had an option to change the vector table location. We gave it a try and it actually worked.
/*!< Uncomment the following line if you need to relocate the vector
table anywhere in Flash or Sram, else the vector table is kept at the
automatic remap of boot address selected */
#define USER_VECT_TAB_ADDRESS
I played around with getting our LoRa working for a few minutes but got nowhere so that will be a tomorrow issue.
Entry 1: -----------------------------------------------------------------
Date: April 21stStart Time: 3:00pm
Duration: 7.50 hours
Cullen, Visuwanaath, and I are in the lab today. First off, I flagged down a TA and got the OLED PSDR checked off. Now we have two so we only need to get LoRa working and we pass.
I was complaining to my teammates about how slow the refresh rate was on the display and how it would make navigating a menu difficult. Visuwanaath mentioned that maybe my clock frequency was slow. I changed it from 4 MHz to 32 MHz and wow that looks so much better, it went from taking 2 seconds to display a new screen to taking maybe a quarter of a second. I also got rid of all the unused driver functions from my driver C file.
I put stickers on the alphanumeric keypad to make it easier to type with and had both teammates give me feedback on the feel of it. Cullen wanted the delays shorter and also noticed that if you hit the backspace it would sometimes delete two or three characters. I will need to increase the post button press delays on that key specifically.
After looking through the UI files I found out how to change the text that is displayed on each menu screen with a simple command. Only issue is that the screen needs to be manually refreshed in doing so. Also, given how small the OLED is, 200 characters wont fit on a single screen. 100 won’t either. 50 won’t either. Only about 30 characters can fit and that still takes up half the screen. I will need to figure out how to display different character lengths at a later time.
Sophie popped in and we talked about hardware progress. We explained that one of the boards was cooked through and through. She told us that she had stripped one of the OLED headers and that one of the PCBs was now unusable. We agreed to take some of the parts off of the board that no longer works.
We are pivoting to start testing the LoRa module. We are sending commands but getting nothing back over UART. We are fiddling with commands and the baud rate (which shouldn't need changing as the manual says 9600) but nothing is working. Visuwanaath and I are exhausted so this is a tomorrow issue. Before we left I noticed that some of the resistors weren’t soldered around the LoRa chip. Could be that they are just for the LEDs that we likely won’t need but I brought it up to Sophie over text just in case.
=============== Week 14: =================
Entry 15: -----------------------------------------------------------------
Date: April 20thStart Time: 8:30pm
Duration: 2.25 hours
I want to take a break from the manu today so I will try to get the alphanumeric keypad working. I am wiring it up as the store page says on one of the prototypes.
Just set up the GPIO pins on the Cube and tried a simple test to get it to print something to the OLED. It didn’t work. The wiring is incorrect on the website according to one of the reviews which also states the correct pinouts. The review was correct. I can now read the key presses. I just set up an alphanumeric function for the top left key which will be a/b/c.
if(Keypad_Scan() == '1'){
HAL_Delay(750);
key = 'a';
keyBuffer[bufferIndex] = key;
OLED_SendString(keyBuffer);
if(Keypad_Scan() == '1'){
HAL_Delay(750);
key = 'b';
keyBuffer[bufferIndex] = key;
OLED_SendString(keyBuffer);
if(Keypad_Scan() == '1'){
HAL_Delay(750);
key = 'c';
keyBuffer[bufferIndex] = key;
OLED_SendString(keyBuffer);
}
}
}
Just coded up the rest of the keys and it can now type out messages. The delays are much better around 300 ms.
I will need to have someone try this out to see if typing on the keypad feels natural because right now it feels stiff and slow. Also, none of the PCBs have the 7 pin connector soldered on so that will need to happen very soon this week.
Entry 14: -----------------------------------------------------------------
Date: April 19thStart Time: 2:30pm
Duration: 6.25 hours
Just got to the lab, turned on the screen, and now my screen doesn’t show up anymore. Even after I flash it this is so annoying. Ok I gave it 5 mins to sit and now it works. Good grief.
I am playing around with having the screen only display black and white pixels. The way it receives the bitmap currently has much of the screen displaying the white as grey and it looks terrible. It also has white bars going through it which I can’t explain.
I just realized that I am receiving each pixel in the bitmap as 8 bits but the RBG565 format that is benign used is 16 bits. I changed the function and it looks a bit better but I still want to go for the black and white. I have it set so that if the 64 bit grayscale value the RBG is scaled to is over 40, it will be black and white otherwise. That looks much better. I just tried inverting the black and white and it looks so much better. It also draws less mA which is a plus. I will keep it like this.
The fact that the color scale isn’t even mentioned in the OLED datasheet is super weird, there are also no drivers anywhere to be found. Right now I am able to print seemingly whatever I want to the OLED but I feel like it isn’t how I’m supposed to be printing things. However it ain’t broke yet so I won’t fix it.
I’m making the menu now in Squareline studio. Sophie has to complete the User Manual today so I will finish these up and get those over to her ASAP. I’m having trouble with the image png file being too big for the STM32CubeIDE to upload onto the micro. With the uncompressed image the code push is almost 8 MB and our micro only has 2 MB of flash. I changed some settings in Squareline Studio to turn the image into a compressed binary file. No matter what I try though I can’t get any image file to show on the OLED. For now I will just use text arrows ( < ^ > v ) and then rotate them accordingly.
Another thing I’m realizing now, switching screens doesn’t work properly. It only refreshes the part of the screen that changes, but the way I’ve written my drivers, it always starts writing from the top left corner which messes everything up.
I cannot transform text and have it display to the OLED. No transformed (rotated) text ever shows up. I was trying to make text larger and smaller by transforming it but squareline studio has different font sizes so I will just use that. I had to enable settings in the LVGL config file but now I got different text sizes to display
I am trying different ways to refresh screens without the buffer issue messing everything up like I talked about earlier. I found that this works best:
lv_disp_load_scr(ui_main_beacons);
lv_refr_now(NULL);
HAL_Delay(200);
I sent those to Sophie and I’m going to get started writing the giant state machine to navigate the menu. I will have to finish this up another time but I think I got the logic of it down assuming the navigation buttons work.
Entry 13: -----------------------------------------------------------------
Date: April 18thStart Time: 11:00pm
Duration: 0.75 hours
Added more journal entries to the website. These entries take way too long to put into the website. Course staff whines that we don't put effort into journals but I don't think they realize that it is in part due to the fact that these take HOURS to put into VSCode and format. Just make us keep a google doc or something this system is horrible.
Entry 12: -----------------------------------------------------------------
Date: April 18thStart Time: 3:30pm
Duration: 7:00 hours
I am in the lab alone today and I will try to get the OLED to display the design. Currently it displays the logo but I will almost certainly have to change the bitmap function because the LVGL software spits out the bitmap in 16-bit RGB565 format but our OLED takes 4-bit grayscale. The current bitmap function I have just takes in an array and sends each byte of data to the OLED sequentially. Currently when I try to load the design I get a blank screen with two stripes being written to over and over:
I changed the setting of the rows and columns, which it was setting manually. This OLED has rows from 0-63 as indices but for some reason the columns start at 0x1C so that should center the image better. Now I’m getting this three layered static:
I tried writing the bitmap backwards and that actually gave me a screen close to what I wanted to see. The design I wanted to display was the “hello world” screen I made yesterday. This is what is being displayed now:
I am playing around with different styles of sending the bitmap to the OLED as data bytes. Just after writing that sentence, I kept trying new settings for almost three hours and completely forgot to write anything here but here are some of the screens I got printing:
That last screen is super close to what I wanted, but I can’t figure out why that last row is filled with junk pixels. I'm sending the entire array it should all fill up. I am going to try adjusting the row settings because maybe its printing a row too high. That made it worse haha.
Ok nothing I am trying is getting it exactly how I want and I think it’s a formatting issue with how my screen is reading data vs LVGL is sending the data. I am asking ChatGPT to give me some test screen bitmaps to find out how LVGL is sending its data. Ran the test functions and it wasn’t displaying the designs that I should have so I told ChatGPT what results I got and it identified the OLED as using “SSD1306-style paging” which I looked up and found it had a different layout than I am trying. I just corrected the test function and am getting this correct result:
This is the final working code:
// Set the column
void OLED_Set_Column(uint8_t start, uint8_t end)
{
Command(OLED_CMD_SET_COL_ADDR);
// Data(start);
// Data(end);
Data(0x1C);
Data(0x5B);
}
// Set the row
void OLED_Set_Row(uint8_t start, uint8_t end)
{
Command(OLED_CMD_SET_ROW_ADDR);
// Data(start);
// Data(end);
Data(0x00);
Data(0xCF);
}
// Set the display window
void OLED_SetWindow(uint8_t start_x, uint8_t end_x, uint8_t start_y, uint8_t end_y)
{
OLED_Set_Column(start_x, end_x);
OLED_Set_Row(start_y, end_y);
}
// Draw the bitmap array onto the OLED
void OLED_DrawBitmap(uint8_t x, uint8_t y, const uint8_t *bitmap)
{
OLED_Set_Column(0,0);
OLED_Set_Row(0,0);
Command(OLED_CMD_WRITE_RAM);
for (int row = 0; row < OLED_HEIGHT; row++)
{
for (int col = OLED_WIDTH - 1; col>= 0; col--)
{
int index = (row * OLED_WIDTH + col) * 2 + 1;
Data(bitmap[index]);
}
}
}
Entry 11: -----------------------------------------------------------------
Date: April 18thStart Time: 11:30am
Duration: 1.00 hours
Added current journal entries to the website.
Entry 10: -----------------------------------------------------------------
Date: April 17thStart Time: 8:00pm
Duration: 1.75 hours
Still following the tutorial. I uploaded all the files to the CubeIDE exactly as it recommended. When building, I got tons of errors, mostly import errors with header files. Fixed those now. Progress is very slow getting this to build because there are so many files.
Next I am creating a very basic design in the Squareline studio software. I followed part two of the tutorial in creating a very basic hello world screen which I can test on our OLED to make sure the software works on our micro. I will hope to test this on the PCB OLED tomorrow but in the meantime I should be able to work on the menu screens. Our screen doesn’t have many pixels which will make the menu very compressed but oh well.
Entry 9: -----------------------------------------------------------------
Date: April 17thStart Time: 4:15pm
Duration: 2.50 hours
Visuwanaath and I met in the lab to get the packet sending code working. I had some trouble with my OLED prototype not showing strings but it was all a typing error. Also, I enabled DMA receiving for the UART. Visuwanaath already wrote much of the packet receiving and unpacking code so we just had to move it from VSCode to the CubeIDE. That took more time than we would like to admit but it runs. Since we are now using the DMA like Cullen’s code recommended, the buffer we were printing isn't filling up until it was done receiving, which makes sense but was not what we wanted for the initialization.
We finally had the idea of setting a flag in the interrupt which would let us wait until the buffer had what we wanted before proceeding. This lets the buffer fill up with +OKs one at a time. Now we got the DMA buffer to fill up with bits and pieces of our packet but not the entire thing. It is set to circular so it should start at the beginning of the buffer if it overflows but it isn’t. Got it working and the buffer now fills with the entire packet.
Visuwanaath wrote some more cohesive code to print packet info to the OLED once it was received and it works now.
Next we have to test this code on the LoRa module on the PCB.
Entry 8: -----------------------------------------------------------------
Date: April 17thStart Time: 12:30pm
Duration: 1.00 hours
Going to write the bitmap and window size functions. They are written now but i don’t know if they work. I based them off of similar functions that the tutorial mentioned. Here they are:
// Set the display window
void OLED_SetWindow(uint8_t start_x, uint8_t end_x, uint8_t start_y, uint8_t end_y)
{
// Set column address range
Command(OLED_CMD_SET_COL_ADDR);
Data(start_x);
Data(end_x);
// Set row address range
Command(OLED_CMD_SET_ROW_ADDR);
Data(start_y);
Data(end_y);
}
// Draw the bitmap array onto the OLED
void OLED_DrawBitmap(uint8_t x, uint8_t y, const uint8_t *bitmap)
{
// Set the drawing window
OLED_SetWindow(x, x + OLED_WIDTH - 1, y, y + OLED_HEIGHT - 1);
// Start RAM write
Command(OLED_CMD_WRITE_RAM);
// Calculate total bytes (each byte contains 2 pixels)
uint16_t total_bytes = (OLED_WIDTH * OLED_HEIGHT + 1) / 2;
// Send bitmap data
for (uint16_t i = 0; i < total_bytes; i++)
{
Data(bitmap[i]);
}
}
Entry 7: -----------------------------------------------------------------
Date: April 16thStart Time: 10:30am
Duration: 3.25 hours
Going to do my best to understand what Visuwanaath and Cullen have been cooking up the past two weeks. I first read this article they used to get their DMA working.
I looked through Visuwanaaths code on the Github. Seems to be the start of some very complex stuff but I understand most of it. I do need some clarifications:
-
Clarifications I need from Visuwanaath
- storeBeaconsInFlash
- Flash erase should be after flash program
- addBeaconToBeaconArray
- Should check all elements before adding or changing
- No check if array is already full
- Strncpy with length limits instead of strcpy
- Flash is rewritten on every write, why?
- Packet 7 and 2 do the same thing?
Cullen’s code is pretty simple; it looks like he didn’t change much. He is now using a DMA receiver function though, which should take some load off of the CPU.
I am watching some Youtube videos now on how to implement LVGL in STM32CubeIDE. At some point they all involve uploading drivers. I’m asking ChatGPT for examples of what a driver file would look like because I couldn’t find any online for our specific OLED. Luckily, the datasheet isn’t that long and the commands are pretty straightforward and explained well. I am turning my current initialization process into a more refined driver file. I found a font file for ASCII online so I will use that. Here are the functions I currently have:
#include "driver.h"
#include "font.h"
#include
SPI_HandleTypeDef *OLED_hspi;
uint8_t OLED_buffer[OLED_WIDTH * OLED_HEIGHT / 2]; // 4-bit grayscale (nibble per pixel)
// Send Command
void Command(uint8_t cmd)
{
HAL_GPIO_WritePin(OLED_DC_PORT, OLED_DC_PIN, GPIO_PIN_RESET); // Command mode
HAL_SPI_Transmit(OLED_hspi, &cmd, 1, HAL_MAX_DELAY);
}
// Send Data
void Data(uint8_t data)
{
HAL_GPIO_WritePin(OLED_DC_PORT, OLED_DC_PIN, GPIO_PIN_SET); // Data mode
HAL_SPI_Transmit(OLED_hspi, &data, 1, HAL_MAX_DELAY);
}
// Hardware reset
void OLED_Reset(void)
{
HAL_GPIO_WritePin(OLED_RES_PORT, OLED_RES_PIN, GPIO_PIN_RESET);
HAL_Delay(1); // Minimum 200us
HAL_GPIO_WritePin(OLED_RES_PORT, OLED_RES_PIN, GPIO_PIN_SET);
HAL_Delay(1); // Minimum 200us
}
// Initialize display
void OLED_Init(SPI_HandleTypeDef *hspi)
{
OLED_hspi = hspi;
OLED_Reset();
Command(OLED_CMD_SET_SLEEP_MODE_ON); // Display off
// Clock divider and oscillator frequency
Command(OLED_CMD_SET_CLOCK_DIV);
Data(0x91); // Divider = 1, Freq = 0x1
// Set MUX ratio
Command(OLED_CMD_SET_MULTIPLEX_RATIO);
Data(0x3F); // 64 MUX (for 64 rows)
// Set display offset
Command(OLED_CMD_SET_DISP_OFFSET);
Data(0x00); // No offset
// Function selection
Command(OLED_CMD_FUNC_SELECT);
Data(0x01); // Internal VDD regulator
// Set re-map (memory addressing)
Command(OLED_CMD_SET_REMAP);
Data(0x14); // Horizontal increment, column address 0 mapped to SEG0
Data(0x11); // Enable COM split odd/even
// Master contrast current control
Command(OLED_CMD_MASTER_CONTRAST_CURRENT);
Data(0x0F); // Maximum contrast
// Set contrast current
Command(OLED_CMD_SET_CONTRAST_CURRENT);
Data(0x9F); // Medium contrast
// Set phase length
Command(OLED_CMD_SET_PHASE_LENGTH);
Data(0xE2); // Phase 1 = 15 DCLKs, Phase 2 = 5 DCLKs
// Set pre-charge voltage
Command(OLED_CMD_SET_PRECHARGE_VOLTAGE);
Data(0x1F); // ~0.6*VCC
// Set VSL
Command(OLED_CMD_SET_SECOND_PRECHARGE);
Data(0x08); // Second precharge period
// Set VCOMH voltage
Command(OLED_CMD_SET_VCOMH_VOLTAGE);
Data(0x04); // ~0.8*VCC
// Set display mode to normal
Command(OLED_CMD_DISP_MODE_NORMAL);
// Clear display
OLED_Clear();
// Turn on display
Command(OLED_CMD_SET_SLEEP_MODE_OFF);
}
// Clear display buffer
void OLED_Clear(void)
{
memset(OLED_buffer, 0, sizeof(OLED_buffer));
}
// Update display from buffer
void OLED_Update(void)
{
// Set column address range (0-127)
Command(OLED_CMD_SET_COL_ADDR);
Data(0x00); // Start column
Data(0x7F); // End column
// Set row address range (0-63)
Command(OLED_CMD_SET_ROW_ADDR);
Data(0x00); // Start row
Data(0x3F); // End row
// Write RAM command
Command(OLED_CMD_WRITE_RAM);
// Send entire buffer
for (uint32_t i = 0; i < sizeof(OLED_buffer); i++)
{
Data(OLED_buffer[i]);
}
}
// Set pixel in buffer void
OLED_SetPixel(uint8_t x, uint8_t y, uint8_t brightness)
{
if (x>= OLED_WIDTH || y >= OLED_HEIGHT)
{
return;
}
// Each byte contains two pixels (4 bits each)
uint32_t index = (y * OLED_WIDTH + x) / 2;
if (x % 2 == 0)
{
// Even pixel - upper nibble
OLED_buffer[index] = (OLED_buffer[index] & 0x0F) | (brightness << 4);
}
else {
// Odd pixel - lower nibble
OLED_buffer[index]=(OLED_buffer[index] & 0xF0) | (brightness & 0x0F);
}
}
// Draw character at specified position with given brightness void
OLED_DrawChar(uint8_t x, uint8_t y, char ch, uint8_t brightness)
{
// Check if character is in font range
if (ch < FONT_START || ch> FONT_END)
{
return; // Character not in font
}
// Get pointer to character data
const uint8_t *char_data = font_5x7[ch - FONT_START];
// Draw each column of the character
for (uint8_t col = 0; col < FONT_WIDTH; col++)
{
uint8_t col_data=char_data[col];
// Draw each row of the column
for (uint8_t row=0; row < FONT_HEIGHT; row++)
{
if (col_data & (1 << row))
{
SSD1322_SetPixel(x + col, y + row, brightness);
}
// else: leave pixel as background (don't clear it)
}
}
}
// Draw string
void OLED_DrawString(uint8_t x, uint8_t y, const char *str, uint8_t brightness)
{
while (*str)
{
OLED_DrawChar(x, y, *str++, brightness);
x +=6;
// Advance cursor (adjust based on font width)
if (x>=OLED_WIDTH - 6)
{
x = 0;
y += 8; // Move to next line (adjust based on font height)
}
}
}
// Draw line (Bresenham's algorithm)
void OLED_DrawLine(uint8_t x0, uint8_t y0, uint8_t x1, uint8_t y1, uint8_t brightness)
{
int16_t dx = abs(x1 - x0), sx = x0 < x1 ? 1 : -1;
int16_t dy = -abs(y1 - y0), sy=y0 < y1 ? 1 : -1;
int16_t err = dx + dy, e2;
while (1)
{
OLED_SetPixel(x0, y0, brightness);
if (x0==x1 && y0==y1)
{
break;
}
e2 = 2 * err;
if (e2>= dy)
{
err += dy;
x0 += sx;
}
if (e2 <= dx)
{
err +=dx;
y0 +=sy;
}
}
}
// Draw rectangle
void OLED_DrawRect(uint8_t x, uint8_t y, uint8_t w, uint8_t h, uint8_t brightness)
{
OLED_DrawLine(x, y, x + w - 1, y, brightness);
// Top
OLED_DrawLine(x, y + h - 1, x + w - 1, y + h - 1, brightness);
// Bottom
OLED_DrawLine(x, y, x, y + h - 1, brightness);
// Left
OLED_DrawLine(x + w - 1, y, x + w - 1, y + h - 1, brightness);
// Right
}
// Fill rectangle
void OLED_FillRect(uint8_t x, uint8_t y, uint8_t w, uint8_t h, uint8_t brightness)
{
for (uint8_t i=x; i < x + w; i++)
{
for (uint8_t j=y; j < y + h; j++)
{
OLED_SetPixel(i, j, brightness);
}
}
}
// Turn display on
void OLED_DisplayOn(void)
{
Command(OLED_CMD_SET_SLEEP_MODE_OFF);
}
// Turn display off
void OLED_DisplayOff(void) {
Command(OLED_CMD_SET_SLEEP_MODE_ON);
}
Entry 6: -----------------------------------------------------------------
Date: April 16thStart Time: 3:00pm
Duration: 2.75 hours
Sophie, Visuwanaath and I are investigating the power issue with the OLED. We couldn’t get the checkoff. Sophie soldered the wires but it didn’t help. Actually it doesn’t even turn on now.
Dr. Walters came over and we showed him the issue. He immediately noticed the 1.3 Amps that it was drawing and said it was a short. We told him the micro still booted fine but he said that it should only be drawing a few mA. I touched the micro and yea it was like scalding so definitely a short. I just wish we knew that earlier before I sunk like 4 hours into “debugging” this OLED when it was a micro problem. Sophie also showed off the buck converters that weren’t working. She said that yesterday they were but now they weren’t. We chatted a bit more about some other issues like the STLink and such. Just after they left Sophie crashed out and left. Totally justified ngl I’d be pissed.
Visuwanaath and I will work on the LoRa software as best we can until the hardware decides to work again. I am setting up the prototype with a new folder in the CubeIDE. It’s not working even though it's the exact same code. Been changing settings for like 20 mins now and it still won’t work. We might have a second crashout in the group if this doesn’t work soon. Ok finally it turned on. Visuwanaath showed me around the github repo and what he and Cullen have done. He told me to look over a document about how the DMA works also so I will do that tonight.
Entry 5: -----------------------------------------------------------------
Date: April 16thStart Time: 11:45am
Duration: 0.50 hours
Going to keep battling that issue I left off yesterday. Power seems to be the primary issue as the 3.3V and GND cables keep shifting every time I touch the PCB which gives a different result. Changing the prescaler doesn’t fix anything in the IOC file. Nothing I change fixes anything so I think the software works fine. It's just that the power to the board is fluctuating or something. I will talk to Sophie later in the lab to see if we can get a buck converter to power the micro and the OLED to give some consistency.
Entry 4: -----------------------------------------------------------------
Date: April 15thStart Time: 4:30pm
Duration: 4.50 hours
Cullen and I are going to test the OLED today after class. We are having problems with the USB connection. The OLED only seems to turn on when the STLink is connected which is weird because it doesn’t provide any power. Yup checked multiple times and it has to be power cycled WITH the USB plugged in. That is so weird. We are wiring up the STLink manually with wires for each pin and pulling them out one by one. After getting to the last pin, we pulled it out and the OLED is still on. Ok I guess the problem resolved itself. The definition of insanity is trying the same thing and expecting different results. We are trying the same thing AND getting different results. What is happening?
We are moving on to that tutorial I found from the article about setting up the simulator. Got everything set up now. I should be able to design a screen now. Actually getting it onto the OLED through the CubeIDE will be a pain in the ass I fear though.
I don’t really want to work on the design today so I will try to figure out how the OLED displays its pixels. I am getting code from the manufacturer of the OLED to display their logo. I tried implementing it and it still just displays static. It seems that the OLED is capable of displaying 16 shades from white to black, but in the code they only use black and white, which makes sense for a logo. I am spending forever just making random changes and not getting anywhere. Just static.
I got it to display the logo for a split second by removing the delay between SPI packets. That might be an issue I will have to explore more. Perhaps the HAL command doesn’t play nice with HAL delays.
I cannot get the logo to stay. Sometimes it just prints halfway then starts spamming random pixels. I suspect that it might be a power issue. Something to note, after flashing the code it doesn;t start displaying code immediately, I have to power cycle it. Setting the CS pin myself doesn't change anything. Setting RAM to read only after displaying doesn't fix it. I think the RAM is getting set but then the SPI just keeps sending data which it uses to overwrite the image. Don't have any proof yet for that hypothesis. Will work on getting an image to consistently display tomorrow.
Entry 3: -----------------------------------------------------------------
Date: April 15thStart Time: 1:30pm
Duration: 2.75 hours
I am going to start where I left off yesterday and continue finding out why this OLED doesn’t work. The power issue is the obvious first thing I need to look at.
I am testing on the pins coming out of the OLED and it seems that the OLED isn’t getting power or ground actually. I checked the cable and it seems that that is the issue. The cable is not supplying power which means that I probably put it in wrong. I looked up how to insert the cable and I think I just had it upside down so I feel stupid. Now, the cable is getting 3.3V to the OLED but the 3.3V pin on the OLED isn’t getting powered.
Sophie walked in and I showed her the issue. She was confused that I was putting my cable in upside down but I told her that was the only way it was getting power to the OLED. I realized that maybe the connector on both the PCB and OLED were different and after I checked it out I realized that the connector on the OLED needs the pins facing towards the board and the connector on the PCB needs pins facing away from the board. This is an issue because if we were to flip it the correct way the pins would be switched. Luckily Sophie just said she has the other version of the connector. She said that she could get me a new version of the board with the correct connector soon so that I could keep testing the OLED.
She went upstairs to solder so until class at 4:30 I will look up how to use that graphical interface software I found earlier this semester for the software formalization report. I am looking into the LVGL software and there is a simulator I can set up so I can see what my code does before it gets put onto the OLED. I am going through github repos right now trying to figure out how to install it.
Sophie just came back down with the proper header soldered onto one of the boards. I plugged in all the cables again and OH MY GOD IT WORKS LETS GOOOOOOOO. Very excited that the code is being downloaded properly. The OLED turns on which historically has been the hardest part of programming one this semester.
I will keep researching how to set up that simulator. I found a tutorial that said it was only 4-clicks but gave me some errors. I found an article that will help me set it up on VSCode which is exactly what I need. I will work on that just after class.
Entry 2: -----------------------------------------------------------------
Date: April 14thStart Time: 3:30pm
Duration: 3.25 hours
Sophie and Cullen are both in the lab with me now and we are talking about all the booting issues we’ve been having. Sophie brought us two PCB’s with wires soldered to BOOT0 so we could test different boot modes. I brought up the possibility that the STLink could be the issue. Since our NRST pin isn’t connected from the STLink pins to the micro, I’m worried it is trying to do a reset and failing and therefore causing our code to not work. Sophie said that shouldn’t be a problem but I still worry.
Cullen looked through the reference manual while I was probing and found that flashed code should be stored at address 0x0800000 in memory. We checked it and it wasn’t blank, meaning we probably pushed good code to flash. We are both looking through the reference manual now to see if there is anything about the booting modes. We found this chart:
We have only tried to set BOOT0 to ground but it seems there are other settings in software we can set to change the boot modes. We are looking at how to change those. Those option bytes cannot be set in the CubeIDE according to Google but can be set in the STM32CubeProgrammer software. Hopefully we don’t need to download more software. Cullen found that the reference manual tells us what address the bytes are set at, address 0x40022000, so we can see what they currently are. Since the nBOOT0 pin is high and the nSWBOOT0 pin is low, it says that we should already be booting into flash.
Cullen and I are going to test one of the newly soldered micros to see if changing the boot0 pin matters. According to the chart, it shouldn’t matter. We hooked everything up and will test the PCB with BOOT0 pulled to ground and pulled up to 3.3V. While we we’re setting this up, we talked to a TA about what our issue might be and told him about the error we were having and he told us to talk with team 16 or with prof. Walters. Both pulling BOOT0 high and low doesn’t change anything which is very concerning.
Cullen realised that I was setting the pins as pull-up pins, which we learned only pulls the pins high if they are GPIO inputs, and we had them set as outputs. I feel kinda dumb but it's a learning experience for sure. We are now getting voltage on the pad. We are swapping to the old board to see if the code works. The old board doesn’t work, so I think it's genuinely broken somehow. We will continue testing on the new board. Pulling BOOT0 to ground seems to work better than 3.3V (even though it shouldn’t matter) so we'll roll with that but it still gives some errors.
I set up the OLED now that the code works. It didn’t turn on. The OLED isn’t getting voltage from the power pin and the ground pin doesn’t stay at 0V very well. I will diagnose this problem more tomorrow but I think it's a connection problem with the cable.
Entry 1: -----------------------------------------------------------------
Date: April 14thStart Time: 10:30am
Duration: 1.50 hours
I am in the lab alone and am going to see if maybe the PCB I'm testing could have an issue. I will swap it out for a different PCB and test that micro. I just did a quick test on the current PCB and no surprise it still doesn’t work. I will swap it out for the new PCB. The new PCB is actually an old PCB that Sophie soldered but that we aren’t going to use anymore. Wiring up the new one now. It doesn’t have a programming header so I am going to wire them to the STLink with wires. Not sure if this is perfect but it will have to work.
The STLink wires surprisingly let us code the micro with no issues but I am still not getting a response from the micro. I am just trying to pull up a pin so that the touchpad should be 3.3V. It shouldn’t be anything that micro couldn’t do easily if it worked.
Sophie came down, and I explained the situation with the BOOT0 pin that I learned about on Friday. She said that if it was hovering around 100mV like I measured it around then it should be ground anyway but that she could solder a wire to the pin so we can ground it to be safe. She also said to be careful when putting a wire to the pin directly, like I was doing to test the new micro, as holding the wrong pins to ground could destroy the micro.
Well, in any case, the new PCB doesn't work either so I am now very worried about getting code to run. It could be that we are booting into system memory and trying to run that. I don’t really know where to go from here but I will keep trying to diagnose this issue.
=============== Week 13: =================
Entry 6: -----------------------------------------------------------------
Date: April 13thStart Time: 1:00pm
Duration: 5.75 hours
In the lab today alone. I am going to work on getting the OLED working today. I was getting frustrated trying to get the PCB to boot on Friday so I will work on this to get my mind off of things. Since the PCB doesn’t work and the PCB is the easiest way to program the OLED, I will have to improvise. Yesterday while I was lounging around I thought of possibility of just taping the wires to the OLED cable and just using on of the prototypes to send the initialization commands so I will use my ECE 362 breakout board to send the SPI initialization commands to the OLED to see if it will turn on.
I just built the prototype by using painters tape to tape the SPI wires to the pins on the wire. This is probably the most scuffed breadboarding job I have ever done so I’m curious if this will work.
The initialization code didn’t work so I am wiring it up to the oscilloscope to make sure SPI is sending data properly. The oscilloscope doesn’t seem like it is catching any SPI signals but I could just have it on the wrong settings. I hooked it up to the old OLED to see if the SPI works.
The old OLED, which was hooked up to the same SPI signals works fine, so I will pretend that the signals are all correct for the time being. I am going to keep trying to make small changes until the new OLED works. I am also going to switch from the 362 board to the board we’ve been using for prototyping cause the 362 board is pissing me off with its finicky functionality. Sometimes, pins just don’t go high that I’m setting. I’ve now wired up all the OLED pins again. Ok it just flashed on for a second but I don’t know what I did. I think that means the code is fine if it can turn on like that.
Ok I actually got the new OLED to turn on long enough to get a picture. I have to put pressure on the wires for it to happen though, like A LOT of pressure. Probably points to a connectivity issue but that was kinda obvious given the setup.
I think I narrowed it down to just a few pins. The power pins and the Data Command pin aren’t held super tight against the cable by the tape, so if I put pressure on just those three pins the OLED turns on.
I have to go now but I am relieved that the OLED showed signs of life, even if it was just for a second and only displaying static. I cannot reasonably program it with this setup, but at least we can use this code once we get our actual PCB working. Now we just need to get code to run on our PCB, which is terrifying to me right now.
Entry 5: -----------------------------------------------------------------
Date: April 11thStart Time: 3:00pm
Duration: 1.75 hours
I am going to start from scratch today. I made a ton of setting changes to the point where I don’t know what I did anymore so I will just start a new project and go from there. Just set everything up with the serial wire mode and set a test pin as pull up. Got no signal.
I keep getting the error “Break at address "0x1fff34c8" with no debug information available, or outside of program code.” which Google says could be caused by a floating BOOT0 pin. I am probing the pin now and it is getting 100mV. That isn’t a ton but it’s still more than the other pins which without being set are 1-8mV. I suspect that this is the problem and we will have to ground this wire. Google says either wire it straight to ground or with a 10kOhm resistor. I will solder a wire and a 10kOHM resistor together but I don’t trust myself to solder a wire to such a small pin on the micro. I really hope Sophie can.
I called Shivam over to get his opinion and he said the same thing and that it’s weird the pin isn't grounded already. I will have to convince Sophie to help me with soldering that wire next.
Entry 4: -----------------------------------------------------------------
Date: April 10thStart Time: 4:30pm
Duration: 2.75 hours
Cullen, Visuwanaath, and I are in the lab after class. They are working on LoRa and I am still trying to push code to this stupid micro. During class I was looking through the schematic and realized that I should be setting the SYS_JTMS-SWDIO and SYS_JTMS-SWCLK pins on the micro. Now I’m confused how we are expected to set the programming pins of the micro only after we program it. I hope they 're already set up prior to shipping because that would not be fun. I just looked it up and apparently the SWD interface is already set up.
I am going to write a script to see if I can send power to a touchpoint. That didn’t work so I don’t think our code is making it to the micro. Going to look up some things I can do to change that. Since our reset pin isn’t connected from the header to the micro, someone on a forum recommended changing the reset behavior to none. I’m looking up what the “System Wake Up” setting should be. Google says it should be preset 2 because we are using a serial wire and just the two pins to download our program.
I’m just going to keep trying new things until this code changes something. Don’t know how long that will take but hopefully it will get done this week.
Entry 3: -----------------------------------------------------------------
Date: April 10thStart Time: 2:00pm
Duration: 2.50 hours
I’m joining Cullen in the lab. He is working on getting the DMA set up so we can send and receive LoRa messages without using the micro. I will work on getting the OLED to connect with the micro and turn on. Before I do that I want to see what Cullen is up to so I am going to see what his progress is. He is having some trouble getting the prototype hooked up to the lab computer but I’m sure he’ll figure that out soon.
I got the OLED out with its cable Looking through the datasheet right now to see what bytes I need to send to turn it on. I am writing the initialization code right now. The code calls for sending both data packets and command packets. I will just assume they are the same thing. Pushing the code didn’t do anything. Looking back at the datasheet right now. I might be stupid because I didn’t realize the D/C pin is what differentiates data vs command packets.
void OLED_WriteCommand(uint8_t cmd) {
HAL_GPIO_WritePin(GPIOB, GPIO_PIN_14, GPIO_PIN_RESET); // DC = 0 for command
HAL_GPIO_WritePin(GPIOB, GPIO_PIN_12, GPIO_PIN_RESET); // CS low
HAL_SPI_Transmit(&hspi2, &cmd, 1, HAL_MAX_DELAY);
HAL_GPIO_WritePin(GPIOB, GPIO_PIN_12, GPIO_PIN_SET); // CS high
}
void OLED_WriteData(uint8_t data) {
HAL_GPIO_WritePin(GPIOB, GPIO_PIN_14, GPIO_PIN_SET); // DC = 1 for data
HAL_GPIO_WritePin(GPIOB, GPIO_PIN_12, GPIO_PIN_RESET); // CS low
HAL_SPI_Transmit(&hspi2, &data, 1, HAL_MAX_DELAY);
HAL_GPIO_WritePin(GPIOB, GPIO_PIN_12, GPIO_PIN_SET); // CS high
}
void OLED_Init(void) {
HAL_GPIO_WritePin(GPIOB, GPIO_PIN_11, GPIO_PIN_RESET); // RESET low
HAL_Delay(1);
HAL_GPIO_WritePin(GPIOB, GPIO_PIN_11, GPIO_PIN_SET); // RESET high
HAL_Delay(1);
OLED_WriteCommand(0xAE); //display OFF
OLED_WriteCommand(0xB3); //set CLK div. & OSC freq.
OLED_WriteData(0x91);
OLED_WriteCommand(0xCA); //set MUX ratio
OLED_WriteData(0x3F);
OLED_WriteCommand(0xA2); //set offset
OLED_WriteData(0x00);
OLED_WriteCommand(0xAB); //function selection
OLED_WriteData(0x01);
OLED_WriteCommand(0xA0); //set re-map
OLED_WriteData(0x16);
OLED_WriteData(0x11);
OLED_WriteCommand(0xC7); //master contrast current
OLED_WriteData(0x0F);
OLED_WriteCommand(0xC1); //set contrast current
OLED_WriteData(0x9F);
OLED_WriteCommand(0xB1); //set phase length
OLED_WriteData(0xF2);
OLED_WriteCommand(0xBB); //set pre-charge voltage
OLED_WriteData(0x1F);
OLED_WriteCommand(0xB4); //set VSL
OLED_WriteData(0xA0);
OLED_WriteData(0xFD);
OLED_WriteCommand(0xBE); //set VCOMH
OLED_WriteData(0x04);
OLED_WriteCommand(0xA6); //set display mode
OLED_WriteCommand(0xAF); //display ON
}
I have to go to class now but this is very concerning if we can’t program the micro. Next step is obviously to figure out why we can't push code.
Entry 2: -----------------------------------------------------------------
Date: April 9thStart Time: 3:30pm
Duration: 2.75 hours
The whole team is in the lab today and prof. Walters came over right away to talk with us. We talked about the duplicate order problem which he told us not to worry about for the time being. We discussed some of the worries about connection with the micro and some of the troubles we’ve had with the STLink. I’m still worried about it. We could have the best software in the world but if we can’t push it to the micro we’re cooked.
Sophie has been soldering a ton and if I can be honest, is making a huge mess everywhere. The team might be able to work in chaos but I can’t. I will spend the day today cleaning up the lab station.
That took way longer than I thought. I had to put away lots of unused prototyping parts. I also threw away a lot of packaging. I organized all of our ordered parts into their separate boxes and separated our old PCBs from our new ones. I also just put away many many unused cables we just had lying around. I feel bad that I didn’t do any actual work today but I feel a whole lot better about my productivity at this desk this week. Tomorrow I will start work on the OLED code.
Entry 1: -----------------------------------------------------------------
Date: April 8thStart Time: 5:30pm
Duration: 1.75 hours
Cullen and I are in the lab and plan to work on getting the lora function written now that we know how to send data. Sophie just asked if someone could write a script to blink the heartbeat LED on the pcb to see if our micro could have code pushed to it. I will work on that instead.
Sophie used the same programming header as the ECE 362 dev board which is fine except that from previous testing, it does not work with the STM32CubeIDE. I will try to use the real (non bootleg) STLink V2. I am wiring that up to the 2x5 cable we will use.
I am going to build a prototype with the 362 board just to see if the STLink works. Then I’m going to write a simple script to turn on an LED. Here is the prototype:
It doesn’t work. This stupid (real) STLink hasn’t worked a single time. I'm sick of it. I will try to find a way to use the fake STLink. I found this Youtube video which got the (fake) STLink to push the script:
Now that we know we can push code. I will try to flash the heartbeat LED on the actual PCB so we know if the micro works or not. Since we don’t have a buck converter soldered onto this prototype yet, I am using the power supply to provide the voltage to everything.
I am writing another simple script to just turn on the heartbeat LED. The code I just flashed didn’t turn on the LED so I am going to probe everything to figure out what the issue is. It seems that the Resistor on the same trace is getting power, which means the micro is getting the code and setting the proper pin. That is a relief. After probing the trace, it looks to me like the LED isn’t getting power at all, which points to a soldering problem or a faulty LED. I will have to concult Sophie about how to resolder an LED next if that is the case.
=============== Week 12: =================
Entry 4: -----------------------------------------------------------------
Date: April 3rdStart Time: 7:00pm
Duration: 4.50 hours
I’m guessing I won’t have a lot to write about in the journal about part two of this report. Whichever TA is reading this, if you want to know what I worked on today, read the analysis report, I’m not going to rewrite everything here.
I copied all schematic diagrams from our midterm design presentation and will look for anything that could go wrong and what effect it could have on the usability of the device and the safety of the user. I think some changes have been made since then, but nothing that would be a safety concern.
I just reached out to Sophie about the buck converter because I don’t know what each individual capacitor and resistors do. She just responded saying that the worst that any discrete component could do was cause the output voltage to be incorrect, which would cause our design to work but not harm the user. Unless the voltage causes the device to get too hot, which I should consider now that I think about it. Just need to wrap the second half up then I can submit.
Entry 3: -----------------------------------------------------------------
Date: April 3rdStart Time: 12:30pm
Duration: 3.25 hours
I am continuing to work on the safety and reliability report. I am struggling to find the other variables as there isn’t an exact fit for our micro and I have to look up what everything means. This manually is so outdated nothing from our current micro matches exactly what is in the handbooks tables. Nowhere in the manual does it state how many logic gates our micro has.
I’m having trouble with our LoRa module. It is made up of many smaller components withing its packaging. Nothing, except the included micro has a section in the handbook so I will just do the analysis for the micro inside, the STM32WLE5CCU6.
Moving onto the magnetometer now. Don’t know what type of microelectronic this would fall under in the military handbook. It is labeled as an IC but there isn’t a section for those, at least none obvious to me. I will just use the same formula for microcontrollers for this module.
Finished up the reliability analysis and the summary, and later I will have to finishe up the second half of the report.
Entry 2: -----------------------------------------------------------------
Date: April 2ndStart Time: 3:30pm
Duration: 3.75 hours
Cullen, Visuwanaath, and I are in Manlab today. Cullen and I want to get the two prototypes to communicate over LoRa so we are debating which sections of our code work and which don’t. Cullen is working on the initialization, and I copied his code into my IDE and am trying to figure out why his code works. He is continuously setting both the transmit interrupt and the receive interrupt. His code does allow my prototype to communicate with my LoRa module, but we don’t yet know in which loop iteration things happen, which is concerning. Ideally, we only want to activate each interrupt once and make that into a function.
I am going to start helping him with the lora initialization function, where we have to set the address, network ID, and some other details. We should be getting a “+OK” response back when each of the 4 initialization commands is sent. Our current implementation has a buffer that is set up to receive data sent back from our lora module, including the “+OK” responses.
We are getting the first +OK, but the second doesn’t display on my prototype. I figured out that in the buffer, after the first +OK is written, the second is written later in the buffer just after the first. Even though I tried clearing the buffer after getting the first response, the bits are clear, but the receive HAL function still doesn’t write to the start of the buffer. I am looking online for a solution to this problem, but all the solutions just tell me to use memset, which I already do. I am going to worry about this another time because we are at least getting the correct responses. For now, the buffer fills up with the +OK messages.
Cullen and I want to get the two prototypes communicating with each other. Together we are setting up his code to transmit a message and mine to receive it. I am just displaying the entire buffer and hoping that his message will eventually show up. We are having some timing problems where he is sending before mine is ready to receive which messes up my initialization procedure. After a few tries we just got it working.
We both have to leave lab now but here is the code I currently have for receiving a message:
void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart) {
// memset(buffer, 0, sizeof(buffer));
// huart2.pRxBuffPtr = buffer;
HAL_UART_Receive_IT(&huart2, buffer, sizeof(buffer));
}
void LoRa_init(){
char displayBuffer[100];
uint8_t address[16] = "AT+ADDRESS=110\r\n";
uint8_t network[16] = "AT+NETWORKID=3\r\n";
uint8_t band[19] = "AT+BAND=915000000\r\n";
uint8_t parameter[23] = "AT+PARAMETER=12,7,1,4\r\n";
memset(buffer, 0, sizeof(buffer));
HAL_UART_Receive_IT(&huart2, buffer, sizeof(buffer));
// memset(buffer, 0, sizeof(buffer));
memset(displayBuffer, 0, sizeof(displayBuffer));
HAL_Delay(1000);
HAL_UART_Transmit(&huart2, address, sizeof(address), 100);
// while(buffer != "+OK\r\n");
HAL_Delay(500);
snprintf(displayBuffer, sizeof(displayBuffer), "Buffer1: %s", buffer);
OLED_SendString(displayBuffer);
// memset(buffer, 0, sizeof(buffer));
memset(displayBuffer, 0, sizeof(displayBuffer));
HAL_Delay(1000);
HAL_UART_Transmit(&huart2, network, sizeof(network), 100);
// while(buffer != "+OK\r\n");
HAL_Delay(500);
snprintf(displayBuffer, sizeof(displayBuffer), "Buffer2: %s", (char*)buffer);
OLED_SendString(displayBuffer);
// memset(buffer, 0, sizeof(buffer));
memset(displayBuffer, 0, sizeof(displayBuffer));
HAL_Delay(1000);
HAL_UART_Transmit(&huart2, band, sizeof(band), 100);
// while(buffer != "+OK\r\n");
HAL_Delay(500);
snprintf(displayBuffer, sizeof(displayBuffer), "Buffer3: %s", (char*)buffer);
OLED_SendString(displayBuffer);
// memset(buffer, 0, sizeof(buffer));
memset(displayBuffer, 0, sizeof(displayBuffer));
HAL_UART_Transmit(&huart2, parameter, sizeof(parameter), 100);
// while(buffer != "+OK\r\n");
HAL_Delay(1000);
snprintf(displayBuffer, sizeof(displayBuffer), "Buffer4: %s", (char*)buffer);
OLED_SendString(displayBuffer);
}
Entry 1: -----------------------------------------------------------------
Date: April 2ndStart Time: 1:15pm
Duration: 1.25 hours
I am working on the Reliability and Safety report today. The components that are most likely to fail are the micro, magnetometer, GPS module, and LoRa chip. I plan to use the lambda formula for microelectronic circuits seen in the lecture. I am looking through the military handbook for C1 and C2 values for the micro. This handbook seems out of date because it only has flash values in the KB ranges, whereas ours has 4 MB of flash. I found C1 in section 5.1 and C2 in section 5.9 but I will still have to find the rest of the values later.
=============== Week 11: =================
Entry 3: -----------------------------------------------------------------
Date: March 27thStart Time: 5:30pm
Duration: 2.50 hours
I attended the soldering workshop just after class today where I learned how to drag solder. Sophie is already an expert at it and I hear Cullen did well so I will likely not need to solder anything but it’s good to know.
I kept trying to get my code working but no matter what I tried I just couldnt get it working. Cullen and I plan to meet next week to figure out how he got his to work and why my code doesn’t do the intended operations. Here is what I have so far:
memset(buffer, 0, sizeof(buffer));
HAL_UART_Receive_IT(&huart2, buffer, sizeof(buffer)); // Non-blocking RX
while (1){
OLED_SendString(waiting);
uart_tx_done = 0;
HAL_UART_Transmit_IT(&huart2, message, sizeof(message));
while (!uart_rx_done){
OLED_SendString(waiting);
}
if (buffer[0] == '+') {
OLED_SendString(success);
} else {
OLED_SendString(failed);
}
}
void HAL_UART_TxCpltCallback(UART_HandleTypeDef *huart) {
uart_tx_done = 1;
OLED_SendString(tx_done);
}
void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart) {
uart_rx_done = 1;
OLED_SendString(rx_done);
HAL_UART_Receive_IT(&huart2, buffer, sizeof(buffer));
}
Entry 2: -----------------------------------------------------------------
Date: March 27thStart Time: 2:30pm
Duration: 2.00 hours
I am working on getting the LoRa to verify a send. To do this, we are sending a hal function to transmit the function and a hal function to receive it. Both functions are interrupts which need extra interrupt handling code to use. I am understanding how each of them work currently. Now I am proceeding to not understand how Cullen got his functions “working” as he seems to be setting his interrupts in the wrong order. Here is his code:
uint8_t message[10] = "AT+MODE?\r\n";
uint8_t buffer[10];
while (1) {
HAL_UART_Transmit_IT(&huart2, message, sizeof(message));
HAL_Delay(1000);
HAL_UART_Receive_IT(&huart2, buffer, sizeof(buffer));
if (buffer[0] == '+') {
OLED_SendString(buffer);
} else {
OLED_SendString("Waiting for LoRa...");
}
}
void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart) {
HAL_UART_Receive_IT(&huart2, buffer, sizeof(buffer)); //You need to toggle a breakpoint on this line!
}
Entry 1: -----------------------------------------------------------------
Date: March 26thStart Time: 3:30pm
Duration: 2.50 hours
We are in the lab for ManLab today and the first thing on the agenda is getting the LoRa modules working. I am wiring up my prototype to include the LoRa module just like the other and setting it up in the IDE.
I was planning to start on that today but Visuwanaath and I got sidetracked when Cullen started asking about how many bytes we would need for each packet. We started writing out what info, with their respective number of bytes, we would need for each packet. We realized that for message packets we couldn't send 300 characters within the allotted 240 byte sending limit. We will need to ask Prof. Walters if we can lower the number of characters on our PSDR from 300 to 200 so that we don’t have to deal with sending two packets per message. We then got to talking about how many of each packet we would have to send for each functionality. We quickly realized that our “time to live” proposal would result in hundereds of messages being sent between all beacons on a network just to maintain a nearby beacons list on each device. Visuwanaath and I decided that a graph storing nearby beacons would be much easier than forwarding those same packets a thousand times.
We also found an edge case to think about. If a beacon is on the nearby beacons graph and it moves out of range, we will have to delete if out of the graph and research the graph for another path the beacon can be reached. See the right side of the above picture to see our notes on that. Next we will need to get the LoRa functions working quickly so that we can worry about the data structures part of the software. We can also solder the lora module onto the PCB and start testing there.
=============== Week 10: =================
NO WORK DONE OVER SPRING BREAK
=============== Week 9: =================
Entry 5: -----------------------------------------------------------------
Date: March 13thStart Time: 3:00pm
Duration: 1.00 hours
Added all pics and journal entries to the website.
Entry 4: -----------------------------------------------------------------
Date: March 12thStart Time: 3:30pm
Duration: 5.75 hours
The team is in the lab now. Cullen and I plan to get a coherent message on the OLED today. The goal being to send messages between two prototypes over LoRa then display the messages on the OLED to prove we get them transferred successfully. We are trying different methods of moving the cursor around the screen. I figured out earlier that if you wanted to move the cursor one place you would add 4. Cullen just figured out that if you got it to the bottom row you only needed to add 1. Something is not right about this cursor movement. Adding these numbers randomly is flipping bits that aren't supposed to be flipped because the oled sometimes glitches and displays japanese characters.
I brought my lab kit from ECE 362 so that I could build another prototype and work alongside Cullen on a second device. Got the prototype built on the breadboard now. Just copied the code over to a CubeIDE project but when I go to flash it using the cable from 362 it tells me I need to update it. Just googled the problem and found out that the 362 class gets cheap clones of ST-Links and they don’t work with the CubeIDE. I would like to have a nice conversation with whoever made that decision. I got out the real ST-Link that Visuwanaath was trying to use a few weeks back, and am hooking up all the same cords between my device and the micro. No luck. I am going to check out another STM32L476 dev board that the others are using and just build another prototype.
I built a second prototype and am now working with the code I had this morning. I really don’t have much to report now, its just minor code changes that work, then don’t work, then work perfectly, then I unplug the micro and it breaks when you plug it back in. I’m tired. This micro sometimes works when you push code, but if you unplug it and plug it back in and push the EXACT same code it breaks. I don’t understand. Ok I finally figured out how to move the cursor. I dont understand how it works but sending 0x06 to the SPI1->SR register instead of adding 0x04 to it like I was previously doing moves it consistently. I just tried random bits from the datasheet until I got it working.
Now I can get the micro to display an entire line of text as long as they are all characters.
I am now converting the code snippet and turning it into a function where you can input the code to the function as a character string and it prints it all out, no matter how long the string is. Converting a 8-bit character string into a 16-bit int proved to be a challenge but it works now. I am now able to display a message over multiple screens.
Here is the final code. I don’t understand why we need to keep sending 0x06 to the SPI1->SR register, it is done in the initialization so we shouldn’t need to do it again. If I comment it out, it works, but unplugging and replugging breaks the code if you push it again. I am so so confused why that is but I really don’t care anymore. It works. Here is the function.
char myString[] = "This OLED can now display an infinite amount of characters!";
OLED_SendString(myString);
void OLED_SendString(char *myString) {
// Initialization commands
uint8_t init_cmds[] = {0x38, 0x08, 0x01, 0x06, 0x02, 0x0C};
for (uint8_t i = 0; i < sizeof(init_cmds); i++) {
HAL_SPI_Transmit(&hspi1, &init_cmds[i], 1, 100);
}
// Convert 8-bit characters to 16-bit and add 0x200 to print to OLED
uint16_t size=strlen(myString);
uint16_t charList[size];
for (uint16_t i=0; i < size; i++) {
charList[i]=(uint16_t)myString[i] + 0x200;
}
// Print string in chunks of 32 characters
uint16_t start=0;
while (start < size) {
// Clear the display
SPI1->DR = 0x01;
HAL_Delay(10);
// Move cursor to the first line
SPI1->DR = 0x80;
HAL_Delay(10);
// Move the cursor forward after each character
// ** Hunter thinks this isn't necessary but removing it breaks everything
// ** DO NOT REMOVE IT WILL BREAK AFTER MICRO IS UNPLUGGED
SPI1->DR = 0x06;
HAL_Delay(10);
// Print the first 16 characters of current chunk
for (uint16_t i = start; i < start + 16 && i < size; i++) {
SPI1->DR = charList[i];
HAL_Delay(10);
}
// Move cursor to the second line
SPI1->DR = 0xC0;
HAL_Delay(10);
// Print the next 16 characters of the current chunk
for (uint16_t i = start + 16; i < start + 32 && i < size; i++) {
SPI1->DR = charList[i];
HAL_Delay(10);
}
HAL_Delay(500);
start += 32;
}
HAL_Delay(2000);
}
Entry 3: -----------------------------------------------------------------
Date: March 11thStart Time: 3:00pm
Duration: 1.25 hours
Cullen and I are in the lab now. I explained what the issues were with what we were doing and we are going to keep trying to get it to display a message. We keep running into the issue where the display only displays the first character.
We are trying to manually move the cursor with some success. We can now display text on the first line but it doesn’t wrap around to the second line it just goes into the void I guess. We screwed something up now and it went back to displaying just the first letter again. We are looking at the 362 lab 6 starter code and they don’t manually move the cursor so I don’t know how what they do works but ours doesn’t. We are still in limbo as far as getting a coherent message displayed but here is the code we are working with so far.
/* Initialize all configured peripherals */
MX_GPIO_Init();
MX_SPI1_Init();
/* USER CODE BEGIN 2 */
// INITALIZATION COMMANDS
uint8_t init_cmds[] = {0x38, 0x08, 0x01, 0x06, 0x02, 0x0C};
for (uint8_t i = 0; i < sizeof(init_cmds); i++) {
HAL_SPI_Transmit(&hspi1, &init_cmds[i], 1, 100);
HAL_Delay(100);
}
/* USER CODE END 2 */
/* Infinite loop */
/* USER CODE BEGIN WHILE */
SPI1->DR = 0x01; // CLEAR DISPLAY
while (1){
/* USER CODE END WHILE */
// DATA COMMANDS
uint16_t display[34] = {
0x002, // Command to set the cursor at the first position line 1
0x200+'E', 0x200+'C', 0x200+'E', 0x200+'3', 0x200+'6', 0x200+'2', 0x200+' ', 0x200+'i',
0x200+'s', 0x200+' ', 0x200+'t', 0x200+'h', 0x200+'e', 0x200+' ', 0x200+' ', 0x200+' ',
0x0c0, // Command to set the cursor at the first position line 2
0x200+'c', 0x200+'l', 0x200+'a', 0x200+'s', 0x200+'s', 0x200+' ', 0x200+'f', 0x200+'o',
0x200+'r', 0x200+' ', 0x200+'y', 0x200+'o', 0x200+'u', 0x200+'!', 0x200+' ', 0x200+' ',
};
uint16_t charList[] = {'M', 'e', 's', 's', 'a', 'g', 'e', ' ', 'R', 'e', 'c', 'e', 'i', 'v'};
uint16_t size = sizeof(charList) / sizeof(charList[0]);
SPI1->DR = 0x01; // CLEAR DISPLAY
HAL_Delay(50);
uint16_t cursor = 0x02;
for (uint16_t i = 0; i < 34; i++) { while(!(SPI1->SR & SPI_SR_TXE));
SPI1->DR = cursor;
// SPI1->DR = 0x200 + charList[i];
SPI1->DR = display[i];
HAL_Delay(50);
// FOR THE TWO LINE-SET COMMANDS
if((i != 0) || (i != 17)){
cursor += 4;
}
}
HAL_Delay(100);
/* USER CODE BEGIN 3 */
}
Entry 2: -----------------------------------------------------------------
Date: March 11thStart Time: 10:45am
Duration: 2.25 hours
I met with Niraj for this morning because if anyone knows how to get this OLED working, it’s him. I brought the prototype into his office and we reviewed the code I did have. He recommended that I use baremetal commands to make it easier to debug so I am implementing that now.
We still can’t get it to turn on so we are going down to the lab to see what signals are being sent to the OLED via the oscilloscope. The STM32CubeIDE LOVES to reset parameters I have set so it reset the number of bits per packet to 4 instead of 10. That was an issue for a minute but it still wont turn on even with the change.
I showed Niraj what pins I had set on the micro and he noticed that I was using a GPIO pin for Chip Select (NSS) which he told me to set to NSS mode. I was under the impression that Chip Select would remain high for the entire time but he explaied that it should only go high for a short period BEFORE the message was sent, then go low again. I think that the reason the OLED wasnt turning on before was because we held the chip select high the entire time, basically telling the OLED that we were about to send a message, but never actually sending one. With that change, the OLED turned on.
I am going to play around with it to see if I can get it to display a sentence. I can get it to display a single character of my choosing now but nothing more that that. I will need to come back later and try to get it to display an entire line of text. We plan to use the oled to display messages that we are sending and receiving.
Entry 1: -----------------------------------------------------------------
Date: March 10thStart Time: 3:30pm
Duration: 3.00 hours
I am in lab now trying to get this stupid OLED working. Niraj told us in our design review that the ECE362 OLED used 10 bit communication, not 8 like we were trying. I am playing around with the code now to see if I can get anything working. I am looking through the 362 manual and I can’t find anything wrong with what we are doing, even with 10 bit SPI. All the initialization commands are the same. Sophie is now in the lab and is making some finishing touches to the PCB now. Our first order came in, so we are opening our project box to make sure our sizing is correct for the PCB. She printed out a 1-1 print of the PCB. It appears to be a little too small.
We just compared the size of the print and the size of the PCB design on Kicad and the print is definitely a few mm off. We just looked at the actual size and it seems like the PCB she was designing was a few mm off the exact measurements on our project box websites. She just fixed that along with the mounting holes shifting slightly. She printed it out again and it looks to be close to the exact size. Since the printer is still a few mm off we will just assume that everything is exactly where it needs to be because it sure looks that way. I scheduled a meeting with Niraj for tomorrow morning so the next step is to meet with him to get this OLED to turn on.
=============== Week 8: =================
Entry 4: -----------------------------------------------------------------
Date: March 5thStart Time: 2:45pm
Duration: 1:25 hours
The team met in the lab for an hour before the presentation to practice and flesh out any bumps in the presentation. I just reviewed what I wanted to say for the schematic slides, mainly focused on exactly what language to use with the buck converter. I also explained the software flowchart to Visuwanaath so that I could practice and he could get a better understanding of the software functions that I was envisioning. Sophie just gave me the rundown of all the minor changes she made to the PCB since earlier this week and everything that still needed to happen. Next step is to deliver an absolutely flawless presentation in front of our peers and definitely get a 100% on our perfect design review.
Entry 3: -----------------------------------------------------------------
Date: March 4thStart Time: 5:45pm
Duration: 2.00 hours
Cullen, Visuwanaath, and I are in the lab now trying to finish up most of the presentation. Cullen wants to to update the block diagram so I will do that now.
I am reformatting a lot of the slides and recoloring some text. I am helping Cullen format his major components slides to fix the spacing. Cullen saw Sophie earlier and she said she was still working on the PCB so I’m just a wee bit worried about that. I will have to talk with her before our presentation to make sure I understand any changes she has made since yesterday. I just got a message from the procurement office that they duplicated our order. I sent them an updated list, since they indicated they hadn’t ordered anything yet, and they reordered everything. They really need to read their emails. I even replied to the original email saying that this was an update and we did not want two of everything. Now we have to send back some digikey parts. I don’t know what the old system was but this has not been a pleasant ordering system. They do not communicate in a timely manner.
Entry 2: -----------------------------------------------------------------
Date: March 4thStart Time: 1:45pm
Duration: 2.75 hours
I just received confirmation that the procurement office ordered our matrix keypad. It is quite concerning that they haven’t ordered anything else. I fear this new process is actually a downgrade rather than just buying stuff ourselves. Not happy with them at the moment. I ordered 5 LoRa modules with our personal funds for $85.60. The shipping cost was $30 no matter how many we ordered so Sophie and I agreed yesterday to just order 5 and pray we don't need more than that.
I am now working on the presentation. About an hour in now and I don’t have a ton to write about, I just pasted pictures of the schematic on the slides and wrote out notes on what to say for each slide. Another hour and a half now and and about halfway through the software status flowchart and again am writing out what I want to explain for each slide. I just finished and I plan to meet with the team tonight to practice. We still need to do a good chunk of the presentation.
Entry 1: -----------------------------------------------------------------
Date: March 3rdStart Time: 3:45pm
Duration: 4:25 hours
Cullen and I are in the lab and will start grinding out our midterm design presentation. He just assigned me the software development status slides and I will probably just take the current software flowchart I made for the software formalization report and recolor it to show what is done and what is being worked on. I just recolored it into green for done, yellow for working on it, and red for not started yet. Most of the flowchart is for the menu which we haven’t started so unfortunately most of it is red. Darn. Sophie just got here so I am pivoting to help her with the PCB. She finished the schematic over the weekend and made good progress on the PCB design. I am now helping her edit the pcb layout to include the screw holes and match the shape of the box better.
She was not super happy that the screw holes messed up our GPS ground plane, which was supposed to be 50mm x 50mm, as specified in the datasheet, but now has to be 45mm x 45mm. Either way the size now matches and we can go about adding everything else onto the board. She will probably be making edits up until our presentation tomorrow so Cullen just told her to worry about the PCB slides of the presentation and left the schematic explanation slides to me.
Cullen and I continued to make formatting changes to the design review presentation. He updated the website and added a fun little addition to our team home page. I need to remember to update our website completely before the presentation Wednesday afternoon. We have changed many parts since it was last updated. Tomorrow I will need to complete my sections and begin practicing the presentation with the team.
=============== Week 7: =================
Entry 4: -----------------------------------------------------------------
Date: February 28thStart Time: 2:45pm
Duration: 2.75 hours
I am in the lab alone today, and I will continue trying to get the OLED to turn on. I found the datasheet for the OLED that Cullen had pulled up two days ago and checked that all the wires were correct. I booted up my STM32CubeIDE and now set pins on the MCU in the software. Cullen sent me the code we were using yesterday, so I had a good starting point, but I also watched the first few minutes of this Youtube video to refresh my memory on how to set up pins in the IDE. I tried messing around with different packet types and setting GPIO pins high/low to see if I could even get the screen to turn on. I spent about 2 hours of googling different ways to set up spi on an OLED this was the code I have now. The only real surprise was that for half of the time, I was sending bits in 4-bit mode when it should have been in 8-bit mode.
int main(void){
/* USER CODE BEGIN 1 */
/* USER CODE END 1 */
/* MCU Configuration--------------------------------------------------------*/
/* Reset of all peripherals, Initializes the Flash interface and the Systick. */
HAL_Init();
/* USER CODE BEGIN Init */
/* USER CODE END Init */
/* Configure the system clock */
SystemClock_Config();
/* USER CODE BEGIN SysInit */
/* USER CODE END SysInit */
/* Initialize all configured peripherals */
MX_GPIO_Init();
MX_SPI1_Init();
/* USER CODE BEGIN 2 */
HAL_GPIO_WritePin(GPIOE, GPIO_PIN_10, GPIO_PIN_RESET); // RES LOW
HAL_Delay(50);
HAL_GPIO_WritePin(GPIOE, GPIO_PIN_10, GPIO_PIN_SET); // RES HIGH
HAL_GPIO_WritePin(GPIOE, GPIO_PIN_12, GPIO_PIN_RESET); // CS LOW
uint8_t init_cmds[] = {0x38, 0x08, 0x01, 0x06, 0x02, 0x0C};
for (uint8_t i = 0; i < sizeof(init_cmds); i++) {
HAL_SPI_Transmit(&hspi1, &init_cmds[i], 1, 1000);
}
/* USER CODE END 2*/
/* Infinite loop */
/* USER CODE BEGIN WHILE */
while (1) {
/* USER CODE END WHILE */
uint8_t character='A' ;
HAL_SPI_Transmit(&hspi1, &character, 1, 1000);
HAL_Delay(1000); // Delay for readability
/* USER CODE BEGIN 3 */
}
/* USER CODE END 3 */
}
Entry 3: -----------------------------------------------------------------
Date: February 26thStart Time: 3:00pm
Duration: 3.25 hours
For ManLab today we will try to finish the schematic and correct our already-made PCB design. Sophie was looking at our keypad on amazon, as it didn’t have a datasheet. She noticed that it required 12V, which we could not do. That is totally my bad for not checking. I had just assumed that a directional keypad made for an Arduino WOULDN’T REQUIRE 12 VOLTS. Anyway that sucked and so now we will go with our original plan for designing our directional keypad with regular pushbuttons. I’m moving over to help Cullen with getting our OLED1602-SPI display working on our prototype now that Sophie is in a good place to finish the schematic. He has been unsuccessful so far and we are trying to send several packets to the OLED over SPI to wake it up. It doesn’t help that the OLED we used in 362 has an awful datasheet. We have been trying different packet types and byte combinations for the past hour and nothing seems to work. The current method of sending packets we are trying is this:
uint8_t TX_Buffer_init[6][8] = {{0, 0, 1, 1, 1, 0, 0, 0},
{0, 0, 0, 0, 1, 0, 0, 0},
{0, 0, 0, 0, 0, 0, 0, 1},
{0, 0, 0, 0, 0, 1, 1, 0},
{0, 0, 0, 0, 0, 0, 1, 0},
{0, 0, 0, 0, 1, 1, 1, 1}};
for(uint8_t i = 0; i < 6; i++){
HAL_SPI_Transmit_IT(&hspi1, &(TX_Buffer_init[i]), 8);
HAL_Delay(1000); HAL_GPIO_WritePin(GPIOE, GPIO_PIN_12, GPIO_PIN_RESET); // CS LOW
HAL_SPI_Transmit(&hspi1, &TX_Buffer_init[i], 1, HAL_MAX_DELAY);
HAL_GPIO_WritePin(GPIOE, GPIO_PIN_12, GPIO_PIN_SET); // CS HIGH
HAL_Delay(1000);
}
