1.) This could be a really dumb question, and if it is I’m sorry about that. I am confused about how the FE310 works vs. other MCUs. I’ll use one I’m familiar with as an example: the ATSAMD21J18A (or any atsamX mcu) takes code and then writes it to internal memory (sram or flash I’m pretty sure?) and then executes it. The weird thing I see with the fe310-g002 is that it seems to be executing code I am not giving it.
Here’s an excerpt from my terminal containing it’s output when I run some code:
ATE0–>Send Flag Timed Out Busy. Giving Up.
Send Flag error: #255 #255 #255 #255 AT+BLEINIT=0–>Send Flag Timed Out Busy. .
Send Flag error: #255 #255 #255 #255 AT+CWMODE=0–>Send Flag Timed Out Busy. G.
Send Flag error: #255 #255 #255 #255
METAL SPI Driver Demo
failed
performing spi transfer NOW
The top part of this:
ATE0–>Send Flag Timed Out Busy. Giving Up.
Send Flag error: #255 #255 #255 #255 AT+BLEINIT=0–>Send Flag Timed Out Busy. .
Send Flag error: #255 #255 #255 #255 AT+CWMODE=0–>Send Flag Timed Out Busy. G.
Send Flag error: #255 #255 #255 #255
is where my confusion lies. I’m assuming this is because these chips come with a bootloader on board. Why does it need a bootloader if other chips (like atmel ones) use an ATMEL-ICE or something to just write straight to flash and execute? I know that arduinos usually come with a bootloader on board, but I thought that was only because they want you to be able to flash the board without any sort of real debugger, but we have one (the jlink) so why the bootloader?
2.) This question sort of piggybacks off the last one, and it is where is the hardware initialization happening when it comes to uart/debug terminal? The code samples basically just have this:
#include <stdio.h>
int main()
{
printf(“Hello world\n”);
return 0;
}
And somehow this just… works, but on other mcus I have used, you need to do a lot of hardware initialization like telling the mcu the pins to use, baudrate, parity, etc. How is all of that being handled?
3.) I also notice that in all of the examples (pretty sure all of them), there is no while loop to hold the program that is being executed active, and the return value is being used a lot. Compare this to what I’ve learned about other mcus, and most of the time the return value is being discarded and instead people opt to hold some error value in a dummy handling infinite while loop for debugging error codes. Is there an overarching design choice that I’m missing out on so that using the return values is useful? I know that when writing in c/c++ on a computer with an OS, people use the return value to indicate what went wrong, but since MCUs are supposed to run for an indefinite amount of time and they’re only supposed to be executing that 1 program, the return values seem like a weird way to go. T
These questions probably just because I don’t understand some risc-v stuff, so if anyone can explain some of the differences or just point me in the right direction that would be sick.
