I understand what @funkathustra are doing, my issue is that I don't know how to "view" a return in C. So how would I inspect your error variable. I know this is very simple to do, I just can't find it online (probably because it's so basic).
Do you understand, though?
uint8_t error = someFunction();
if(error) ....
You realize that "error" is an 8-bit unsigned variable that holds the "return code" right? You can set a break point on that line, and the moment you step over it (to the next line), the "error" variable will contain the result of someFunction() executing. You said you're not familiar with C — if you come from a high-level language like C#/Java/etc, you're probably thinking of exceptions or something like that; C has no exceptions.
The only thing a function can return is a return value, and you can read this value and assign it to a variable in your source code, as I do above. Once it's assigned to a variable, it will occupy memory, and your debugger can inspect it.
Having said all that....Can we just go big-picture for a second?
Don't take this the wrong way, but you don't seem to really have any idea what you're doing or why you're doing it. You don't seem to be interested in these individual lines of code and what they do (since all you're doing is copying-pasting stuff around into a big mess). I want to pause and say there's absolutely nothing wrong with that, by the way. I'm just stating an observation.
Microcontrollers have registers. Lots of registers. Registers for the SERCOM modules, for the timers, for the GPIO, and for everything else on the chip. You manipulate the bits in the registers to do what you want to do.
You can keep the
SAM D21 datasheet up on your screen, and use the debugger to inspect the peripheral registers to ensure that the correct bits are getting set and cleared for the operations you're trying to perform, as you walk through your code. But you need to know what to
expect to see, at the register level. When you mux the proper pins to the UART, what are the register values you
expect to see? Does it match what your debugger says the actual bits are?
At a very low level, this is how professional embedded developers like us can write and debug this sort of code.
Since you seem more interested in
results, can I recommend you just use
Atmel START? It's an online code-gen tool that will create all your initialization code for you, and provide high-level functions that you can use to get stuff done. It has a pin-mux tool that will let you assign UARTs or I2C pins where you want them, as well as initialize them with proper baud rate settings. You'll also get nice, high-level functions for interacting with them.
I do a ton of consulting work for start-ups and smaller companies, and everyone uses these tools all the time for "basic plumbing" of an application; just to get something up and running to show the boss. Sure, @ataradov will mention that some of these libraries of bugs in them, and some of them are slow — all true. But they *
generally* work well, and they *
generally* let you get away from the nitty-gritty details of your chip, which most people honestly aren't interested in anyway.
I've been in discussions with @ataradov on these forums about this stuff before, and while we agree on a lot of embedded stuff, we have very different perspectives on these things — he's very much opposed to peripheral libraries and code configurators and I think debuggers as well.
I have to disagree with him on those points. It totally depends on the user. Personally, I have no problem working at the register level of modern ARM microcontrollers, but for hobbyists and new users who aren't $200-an-hour embedded engineers, that might not be feasible. That's why I highly recommend code configurator tools — especially for basic projects and when working on parts that need a lot of TLC to get up and running (like an ARM microcontroller or any modern 8-bit or 16-bit device with clock gating, pin muxing, etc).
And I think his recommendation to use pin-toggling instead of a debugger is fucking ridiculous. Debuggers let you step through your code entirely while you're observing
all the peripheral registers of a CPU. It's great for debugging, but it's also great for learning, since you can see exactly what each function is doing to the bits in all the registers.
I think people like @ataradov have a much higher tolerance for dealing with a steep learning-curve when using a new microcontroller than I have, so they're fine with sitting around wiggling pins, seeing if a bit got set or not. No offense to @ataradov, but it also feels like kind of an old-timer "well, this is how I learned it, and it was good enough for me, so it's good enough for you" sort of attitude.
I have no patience for that, so I'm always using a debugger when bringing up a chip and getting peripherals working. Once you know a microcontroller (and a set of peripheral libraries) really well, then sure, you don't need a debugger constantly attached to your system (but since modern MCUs are programmed through the same connection, there's really no difference).
Anyway, please, continue using it, as it's a great tool — at all levels of development.
Home
Help
Search
Login
Register
