Embedded - 113: A Noddy Little Program

Episode Date: August 13, 2015

Clive Turvey (Clive1), master of the ST Forums, talks with us about ARM cores and answering difficult technical questions for fun. Some answers: NVIC Interrupts on the same pin number STM32F4 PWM channel 3 ST's Cortex-M7 Books (though we talked more about these being good authors, these are the ones Chris and Elecia have or want): The Definitive Guide to ARM Cortex-M3 and Cortex-M4 Processors, 3rd Edition (Joseph Yiu, 2013) The Definitive Guide to ARM Cortex-M0 and Cortex-M0+ Processors, 2nd Edition  (Joseph Yiu, 2015) Z80 Assembly Language Programming Paperback (Lance A Leventhal, 1979)  Programming the 6502 (Rodnay Zaks, 1979) A bare metal Scheme interpreter for ARM.

Welcome to Embedded FM, the show for people who love building gadgets. I'm Elysia White, here with Christopher White, and we're going to talk to Clive Turvey about ARM cores and ST forums. Hi, Clive. Thanks for joining us today. Hi there. Could you tell us a little about yourself? Yeah.

So I'm an English electronics engineer. I immigrated to the U.S. when I was 22 and currently work in the field of Internet of Things, cellular and short-range wireless devices and those kind of things. And some of the things that I run into a lot recently is the kind of migration of legacy phone gear. Everyone's getting rid of copper wires, and so I tend to work a lot in that space, trying to migrate people from that to cellular networks. But one of the things you are internet famous for is being the person who answers the questions on the ST forums. The only person?

Well, actually, he's got tags that say, waiting for Clive 1, because people only really want answers from him. Yeah. I'm not, that's kind of creepy sometimes. Yeah. So I'm, I'm him. And I do answer a lot of questions there. And there's probably about like half a dozen of us, I think that kind of regularly participate and kind of try and try and field some of the questions uh kind of happened into it uh I worked on forums for for many years probably going back to the the old CompuServe days and uh worked a number of them

for many years and uh kind of them in some respects. And sometimes you get people there that just kind of make it unpleasant to be there. But I'd worked a lot with the STM32 parts and some of the prior parts that they had made and kind of happened on there and played around with it a bit when they first came out. And it was just a very homely place to be. There wasn't a lot of kind of participation on ST's side. And so it, and people's questions were kind of left hanging. So I stepped up a little bit and tried to kind of help things along and try to leverage some of the experiences I've had over

the years to kind of solve and troubleshoot people's questions. And so this is very much an unofficial support role. Yes. Is it work for you? I mean, is it part of the business that you're in or is it more of a hobby? It's more of a hobby. It's a kind of an idle time thing, kind of a challenge to the mind, let's say. When I'm thinking about other things and trying to how I can solve my problems, I go and look and see what other people's problems are and see how those map to things that I've played with and experiences I've had and whether I can solve the problem. So people do crosswords and Sudoku and things like that in their idle time. And I tend to kind of look at this and see what I can do. But you answer really detailed questions. I mean, about interrupts and, well, there's one here about the LSM-303-DLHC data-ready interrupts for the STM-32F3 discovery. And it's in the data sheet, and it says one thing, but the forum poster asks something,

and you just cough up an answer, you know? It has two interrupt pins that can be mapped. And then you say, go read the documentation and you do it gracefully. It doesn't sound like, I don't know, a lot of forum posts sound angry and yours sound like, oh, well, here's the basic information you need. Now here's where you should go check the next thing. What are the best questions you've got? What are the best answers, things you're most proud of answering? I don't know. I go back and look at things over the years,

and I'm kind of impressed sometimes with some of the answers they come up with. But I basically leverage all the experience I've gotten over the years. And a lot of these STM32 parts, they're different, but there's more of them that are the same than anything else. I guess I've mellowed over the years. I might have said, read the manual years and years ago and the RTFM response, but generally I find that's not very helpful. And people, I think, I grew up at a time

when a lot of the technology was just evolving and basically all you had was manuals. So you learn to be pretty good at reading them and kind of skimming through them and kind of extracting the pertinent information. And today I suspect that, yeah, some people are lazy, but on the other hand, I think they're overwhelmed with just the volume of the information.

It's like, where do I start? Where do I find where these things are? I've always looked through lots of books and I have quite an extensive library and tend to skim things so I know where the information is, which it tends to be more important sometimes than exactly what the information is. Where is this information? How does it correlate with other information that I have? So telling someone to go read the fine manual doesn't really, doesn't solve their problem. And so it struck me that it would just be a much more helpful if you try to just kind of point them in the right direction. And sometimes I try not to be overly verbose with some of the answers. It's like, if all they need is like, no, you're looking in the wrong place, look over there, is the response.

And that's probably the best way to go. I'm thinking about that question you asked. And yeah, there was like, I think it was one of these accelerometers or something. And I don't think that I've particularly used that part. But I've used other parts in similar kind of families. And yeah, they usually have like a million configurations and a couple of interrupt registers and so forth. And they can be a nightmare to configure. But it's like saying there isn't an interrupt for it.

That's not really the answer. So I knew that it had interrupts and I just kind of Googled the document and thumbed through it briefly and just it's like yeah there's there's two here and there's definitely pins there and thumb through the registers and yeah looks like there's there's there's some kind of routing there and I'm not going to solve the problem and write the code because that would take a significant amount of time but just kind of finding the pertinent information

typically doesn't take that long and some of these I guess going back to the questions it's like when you see people they've said well I've been doing this for like three or four days and I'm just kind of getting nowhere and it's like those are the kind of those are the kind of questions I kind of look for because it's like okay you really should have asked a bit earlier about this but here here's here's where you should look or here's how something should work and this is what makes sense that should work it's like some people would say well i'm doing this that and the other and you think well that doesn't make any sense at all.

It's like silicon doesn't function in that fashion. You need to kind of step back because computers and silicon are often a lot stupider than people think. It's like they do very, very predictable things. And so sometimes you see people that have done this for a while or been thinking about things for a while. And it's like, you know, you're just overthinking this. So try to address those kind of things. I don't know if I necessarily look for particular questions or particular people asking questions. As I say, there's probably about half a dozen people that I recognize on the forum

who answer specific types of questions and they have certain specialities so it's like if i see something that that's probably better suited to them i'll let it sit for a while and come back to it but um what you said earlier about uh you know when you first started out learning to read manuals and digest information kind of goes to a joke I often say or something that I often complain about in that I can't remember how I used to do things before Google. At work, figuring out a difficult problem or looking up some language-specific thing in code. How did I ever get that done before we had all these search tools and forums and other ways of looking up information and asking about it?

So I guess my question is, do you think we're losing something in that people who have longer-term experience are used to knowing how to synthesize information from various sources and answer their own questions instead of just running to a forum, Stack Overflow, Stack Exchange, the ST forum, and just asking the question.

And I guess I'll leave a follow-up after that, but what do you think about that? I mean, do you think that's a problem? Well, in some respects, yeah. I use Google in a very similar fashion, but people have always commented that I seem to find things that they don't. But I think about things that would be on the page, not necessarily what the question is,

but what surrounds the question to the point where I can kind of find it. And yeah, I think Google helps significantly. And obviously with the kind of the death of manuals in a kind of a printed form, I'm used to, I've got like racks of kind of old Intel manuals and stuff. And that really doesn't exist in its printed form anymore. It's really just a lot of kind of PDFs. And I'm much more of a kind of a book guy where I can kind of fold the pages

or stick post-its on things and have several of them open. And when I'm doing things with PDFs, I might have like 20 or 30 PDFs open. So it can get a bit unmanageable on the screen, sometimes kind of raking through that. And I think that Google breaks through a lot of that, that you can get to that kind of information quickly. But on the other hand, kind of teaching, I think, has changed in how people experience this.

Because when I was first doing this, we were very resource-starved in terms of what information you had. You had kind of RadioShack catalogs and you had component catalogs. You couldn't necessarily see a lot of components and you'd have to maybe order manuals and so forth, all these things. So it was more difficult to kind of find that. So you had a much smaller universe, I guess, in terms of what was out there. And for many years, it's like you didn't have that many microprocessors.

Now it's exploded significantly. You don't just have like Z80 processors. You've got the STM32 parts. You've got the NXP parts. And there's hundreds of thousands of kind of32 parts, you've got the NXP parts, then there's hundreds of thousands of different parts and they're all very different in some of the ways they do things, but very similar in others. Do you think vendors have also gotten lazy

in that they know that there's a community out there that will support their parts and so they don't do the work on documentation that they used to. I feel like in certain cases that's true, that the documentation has gotten worse because well, there's some experts out there and there's the internet and somebody will figure it out and answer these questions and we don't have to. That's a depressing question. Well, that and good documentation is hard to do.

And then tangential to that is that there's some expectation of understanding. It's like, do you write it so that you can completely understand all of the concepts or do you remove all of that and push that off into kind of a technical reference manual for the processor or other things and see programming and expect that people have some kind of grasp of kind of the silicon works this way and these are the registers and registers on peripherals don't really act like memory and what you write to one register might not be the same thing you read back somewhere else. And some of those I think are kind of more kind of learned things

or things that you would study from particular books. I grew up with a lot of the kind of Lance Leventhal books and Rodney Zag's books in terms of kind of processes and so forth and you you got a pretty good feel there of how the mechanics of the computer worked and now i think that all of this stuff is kind of buried it's hidden away from you and made very pretty and so you assume that things might be quite easy. But when you dig under the surface, it's really very complicated. How do you get that knowledge if all you've been presented with

are computers with pretty graphical interfaces and a line that you can type into Google? So when we talk about documents, we often talk about the data sheets, which tend to be a little more high level for the software and more electrical. And then we talk about the processor manual, which is usually what you need to program all the registers for using DMA or I2C or any of the processor stuff. And then for the STM32s, usually those are ARM processors. So if you really want to dig into that, then you're looking at the ARM reference manual or other ARM document.

Is part of what you're doing just helping people figure out which document? Or is it, and do you like these documents in the separation? Or do you wish there was just one? Yeah, ST has a certain way of kind of providing their documentation. I can't say that I've looked that deeply into others. And to be honest i think that the the partitioning does make sense because you don't necessarily want to keep revving the the reference manual just because you've come up with a new part that fits in like 32 pins and how

how those are associated because a lot of these these parts are all using the same die. So it's just really a matter of, well, what pins can you actually escape and where do they come out and how are they configured? And so I can see that there's good reason for separation. Yeah, if you had it all in one spot, it might be easier for someone to search around, but then I think it would just become unmanageable in terms of how the documentation is created and distributed. So I can see the reason behind some of those things.

And to be honest, I tend to look at lots of different books and get, like, a different perspective on a problem from different sources. And I think one of my friends used to refer to this as triangulation, that you get many perspectives and then you kind of pull out the kind of salient information and learn from that. And there are some pretty good books for the arm parts. I know that Joseph Yu has an extensive series on the cortex part. A lot of them, again, cover the same material in some respects between different families. And these days, I think if you went for his kind of most recent book, you'd probably get enough coverage there for kind of all the prior ones.

But he works for Arm, and so I think he has an interesting perspective on things, but it's not really as dry as the kind of technical register-level documentation. It's more of a kind of here's how you do something, here's how these interrupts work, here's how these faults kind of occur. So it's a more personable, I guess, kind of perspective on those stuff. And what I try and do is try and understand what someone's actually asking because sometimes they won't ask the right question.

They leave out important details, but you have to kind of like read between the lines in lots of cases and try and figure out what do they what do they really want to know they're asking this question but that's really not the problem it's like they often describe here in my here are the symptoms that they're seeing but it's like that's really not where you should be looking you need to be looking at the kind of the cause for that so you need to step back and go further up the code and try and understand where that is and that's what i try and do a lot of the time is trying to try to figure out what the real problem is what what knowledge would they need to solve that and then if there's particular documents that have that then i'll direct people at that and

sometimes people will come back and they're maybe they're still using the wrong pin for something and you go well you really need to go check the data sheet there because i don't think there's really not the connectivity there i think one of the problems i think with the stm32 parts in general is the ability to escape particular peripheral functions through the pins. And you can't use everything. I think people come to the party sometimes thinking, it's like, well, it's got all these six UARTs and all these SPI ports, but realistically, you can't use all of those things at once.

You've got to pick a subset of those, and then you've got to work through the data sheet and figure out, well, how do I escape some of that? And I think ST's response to that in some respects is this cube software where you can actually kind of plug in, this is what I want to do, and these are the peripherals I have. And it does what I probably historically do with a pencil and paper and a spreadsheet. It kind of says, yeah, you can't do those two things.

It's like you can't use that pin for the SPI and the UART. It can generate some amount of code for them. I am unfamiliar with the ArmCube software. I heard it used as a, why would you do this sort of question? And when I looked at it, it had paper, pencil, maybe an Excel sheet. Can you explain a little more about what it is? Well, it's ST software. So it's specific to the STM32 series of parts.

It's not something that I use a lot because, as I say, it's not really the way I solve problems. But it's one of those, I would describe it as a fitter application. It's like people would use with FPGAs where you've got a certain number of pins and it tells you what you can, what's the optimum way these things will come out. So I think you can go through there and you can check different kind of peripherals and so forth that you need. And it can generate like a framework. And my understanding is that you can add other kinds of drivers for like CAN or USB and select different kind of classes of device. If you want to make a virtual serial port or something, I think you can do that. And you press a button and out pops some code that kind of sort of works and you fight it from there

and i think one of the issues i think people come up with is well what if i change something what if i change the processor or the package and i basically have to kind of re-synthesize all this again and you know either it destroys what I've done before or you have what you did before and you have to kind of merge things back in. So it's not really a tool that I particularly care for. And the other thing that they changed in that same realm was this HAL layer, this hardware abstraction layer.

And they changed the paradigm of how things were working because one of the problems you have across the STM32 parts is they've evolved and they changed the way they did certain things and how pins were configured and so forth. And it tries to deal with the differences in the part under the surface. So the abstraction layer gets a bit thicker in terms of how big it is, and the paradigm becomes a bit more complicated in that it kind of hides the interrupts from you.

When you get an interrupt, you have to call back into the HAL, and it in turn calls you back with a callback function. It's just not something that I particularly like. I much prefer the standard peripheral library, which is a fairly thin abstraction and something that ST has been using for, can I figure, a decade or so on some of their earlier parts. And it's very similar to things that I've seen on NXP parts and others. Well, there's the ARM-specified CMSIS. Yeah, I don't know how to pronounce it. I pronounced it Frank.

Yeah, I pronounced it Frank. And is that what you mean by the hardware abstraction, like the older hardware abstraction layer? No, not really. Or is there another one? Well, I think they evolve the, I guess I call it SeamSys or something, but I think they evolved it slightly recently to kind of add kind of a real time operating system into it.

But before that they'd had it as just a kind of a layer that tried to unify parts from different manufacturers so it it had some consistency in how you set up the envic and consistency in how you spoke to the the the debug interfaces and kind of the system ticker and so forth. So they had that. An apparent consistency when you were setting up DMA and serial or I2C, although the actual underlayers were not usually very consistent with what they did. I think that ARM at their level basically told people to try and have some uniformity in how you do this. But that's really where you run into kind of headaches with ARM parts, is that basically the core has a lot of uniformity, but then everyone else has their own take on how to build a user,

how to build an SPI interface, and how the SPI interface generates kind of chip selects and how the DMA interface generates chip selects and how the DMA interacts with things and how wide the counters are and how wide the addresses are. So that's where it always gets very murky in terms of plotting things from one platform to another. And I'm not sure that this necessarily helps with that that much. It definitely brings some consistency,

but then people have had free RTOS and other things, and the Micrium operating systems, they've always been kind of fairly consistent. But the peripheral has always been a battle, and I think it had been a battle with ST as they changed some of their part functionality that you really couldn't port it at a register level. Well, that's kind of where those companies differentiate themselves too

because beyond just implementing a Cortex-M flavor, I mean, the peripherals is where you put in some magic. Oh, I have this DMA mode that nobody else has, or I have support for 27 spies or so it's kind of that's where they want to put their secret sauce so i can understand how it all gets a little bit muddled well and it looks like this with this cube thing they they've run out of that secret sauce and now they're saying well how can we make it so people who don't know what they're doing can do this and even though it might be a little slower to run, that's okay.

We'll just bump them into the next processor with these silly callbacks. And the cube seems neat on the surface, but as you said, when you have to change something, either you have to go into their code and find where to change it, and it's pretty complex. It's not the most straightforward code that's generated. Or you have to regenerate it and hope you didn't make any changes you needed. Yeah, the cube stuff I'm not excited about. The CMSIS, I've used a few times, although I get annoyed when I walk through things

because it's not really written for efficiency. And when I have to walk through that code, it's usually because I'm doing battery-related things, and so I really am interested in them using everything they know about the processor to give us the most optimal solution. And instead, they're providing code that is reasonably readable, which is a different set of criteria for goodness. Yeah, and I think the other problem with Cube has been that

I think it's written by Java programmers. So I think they have a different perspective on the world than your average embedded engineer. Yes, yes. As I say. Java, mixing Java and C or even C Sharp are all supported by the cube stuff, which makes my head explode just a little bit. Wait, Java?

Yeah. Really? Yeah. And you could write with the Microsoft.net micro framework. I've never even heard of that. Yes, it's all in the news to me. I mean, I know what.NET is, but I didn't realize there was a quote embedded version.

That's terrifying. Well, all of those are... Heavyweight. No, they're virtual machine-based bytecode languages. So that's very strange that you'd want to put that on something small. Yeah, I think it's really the familiarity with the development system and pushing it on to different parts. And people have JavaScript.

There's some projects that put JavaScript on STM32s, projects that put Java itself. Elow is another one that I see quite a lot. Didn't you tell me there was a scheme too? That's a different... That's a bare metal scheme

implementation. We won't go there. I'll put that in a link for anybody who cares. Yeah, and I think the motivation there is that the framework vendors, Microsoft, Oracle, really want to get their fingers in everything. And they're seeing people maybe seeing a large explosion in products, Internet of Things devices and so on that they don't have a foothold in.

I mean, Microsoft just released an open-source Objective-C framework for Windows 10, so iOS developers can write iPhone code and then port it immediately to Windows. So there's clearly a desire to just make everything work everywhere. Everyone's rushing to put things on Microsoft phones and tablets. Yeah, and they want to make it quite easy, I guess. Please, please come.

Yes. As I say, it's not targeted to people like us, I don't think. I think it's targeted at people who are like, yes, embedded looks cool. It's like, how do I do that? I want to be able to press this button and select a bunch of things and magically out of the end pop some code but i you run into a trap there that you really

don't know how any of it works and it's like it and the paradigm for doing it is just different from anything that i've i've used actively before i understand the concept i understand the mechanics of of how these callbacks work. And I've dealt with Windows device drivers that had kind of asynchronous callbacks and so forth and all the fun that was involved there. But it just doesn't work well for the way I look at things. And that doesn't necessarily mean it's a bad thing. It just means that someone else is probably going to have to figure it out.

And I've basically on the forum have stepped back from kind of trying to deal with some of those things because it's like, I can tell you what makes sense, but I really can't tell you why that particular piece of code doesn't work. And I'm not going to dig into it. So you did mention much earlier, digging in on a data sheet for an accelerometer you've never used. And that makes me wonder, how much time do you spend answering questions on the forum?

Probably not as much as you think. I tend to work quite quickly in terms of those things. And I've used some Bosch accelerometers before, so I'm kind of interested in that. But a lot of these things, it's like I can leverage against what I do. So knowing what components are out there and what kind of applications people have is of general use to me. Because some of the products that we build are more kind of open platform in that we give you the hardware and some of problems and so many problems to be solved that it's, I'd much prefer someone else to solve their particular problem in the way they want to do. So

a lot of these things with timers and ADCs and DMA and hooking these things up, I've got a lot of that code. And a lot of it's a matter of just kind of cutting and pasting, kind of free riding little bits to kind of glue these things together because I've got enough understanding of the mechanics behind what's happening to kind of know what should work and what won't work and what pieces I need to to pick up and I've probably got 20 or 30 years of kind of code sitting on different machines because I pretty much kept everything that I've I've done over the years so writing something to to do a specific task

is something I do a lot I tend to tend to build tools to solve problems does your day job know or and encourage your forum hobby um i'm not sure that they they they fully understand some of some of the aspects of of things that i do but it's like i've historically worked on forums all the all the years i've been out here and as i say it's more of the one of those kind of idle tasks where you you're thinking about another problem and you haven't got a solution for that. And so you're thinking about things. But in all circumstances, when I've been hired to work at places, they basically came to me because they know of my skills. And so I tend to be the person in the office that people would come talk to.

So if they've had a problem for a couple of days and things just aren't making sense, they come talk to me and I try to fiddle around with the thing in my head and figure out, well, what are they actually doing and why that's the problem. Because they've got some very good problem-solving skills and, I guess, listening and descriptive skills in terms of resolving those kind of problems. So it's a matter of where to look, I think. It's like, how do you understand the problem, where to look so on your profile you do invite donations and you do say that they can email uh for paid support has that led to anything or is that primarily been a way to find new jobs for

you um to be honest it really you don't really get much in the way of kind of donations of hardware or anything it's usually people don't read what you've said and they think that they should get some kind of kind of individual hand-holding and i really that's the reason i like the forums is because it has a mechanical advantage in that you can reach a lot of people. You can reach a lot of people with the answers that you give and also people who have the same problem in the future, that they Google into the problem and it solves it there. So I don't tend to like private interactions on specific kind of problems,

and it seems to encourage more people who are like studying, I guess, a lot of students and so forth. Do my homework for me. Yeah, that kind of thing. It's like, I've got this problem. It's like, okay, well, I'm not going to get any of my work done. ST has been pretty good over the years. One of the things that works well with the forum is that they don't really interfere.

And I've gotten various bits of hardware from them from time to time, and that's worked out quite well in terms of how we interact with them and how we buy parts from them. Wait a minute, how your company buys parts or i guess has does st contact you because of your extensive forum posting yeah i've i've spoken i i've got certainly plenty of contacts within st that actually work on the stm32 parts and have had conversations with them in the past. And it's helped in terms of getting evaluation boards and that kind of thing. Do they acknowledge you're doing their job for them?

Well, it is. In some respects, yeah. I think they're pretty proud of the kind of the forum that they have running and the kind of the interactions I have there. But I just generally think that it's a very hard thing to do, to find the people to do that. You really have to kind of have a community, let's say. I don't know. Other peripheral or other Silicon vendors do actually have people that staff the forums and participate. But you sometimes wonder where they fit into things and if they've got the right answers or, I don't know.

Okay. Why the ST forums? There are a lot of forums out there. So why ST? Do you prefer ST boards or ST processors or is it just a good place for generic ARM questions? They have some very good silicon. To be honest, it's like, I used to work for Philips many years ago

and I majored in IC design and worked on kind of IC test and validation and things like that. So I've got like a pretty good perspective on those kind of things. But the ST form just had the right feel to it. As I say, I used a lot of the ST parts

and I do participate in a number of other ARM forms. But they have good parts. They're not constantly revising the silicon. So you don't have to keep track of one part that has four or five different variants and they all behave slightly differently when it comes to the DMA or something. Obviously, they have errata, but they tend to be fairly limited. And as I say, there's not dozens of steppings of the parts. So they're easier parts to, I guess, support.

And as I say, I quite like them as parts, but I've used Atmel parts in the past. I think some of the Atmel products that we have use a lot of ARM9 parts in an embedded Linux perspective, which is a different type of embedded, but I tend to prefer the microprocessor level a lot better. Do you use RTOS as much? To be honest, I don't.

In products I've worked on, we've used free RTOS and Micrium operating systems. But a lot of the stuff that I try to work on, I tend to just have kind of work it through kind of interrupts and interactions between loops and interrupts and data structures. Well, I should ask you a question we sort of failed to answer last week. When do you use an RTOS? When do you decide that an RTOS is necessary?

I think when things get really complicated, if you have file systems and things where you've got a lot of asynchronous activity, it sometimes makes sense to, it would simplify things at that point. And you had lots of different tasks and threads running. Whereas, as i say i i tend to go for the more simpler kind of perspective where i have interrupts that do certain things and

i have state machines and and work problems in in that direction as opposed to just having a task that has one particular thing that it does and then it it waits on a flag before it continues to do other things. But I think if you've got something that fits in that kind of model where it needs lots of threads or processes, that's obviously where you'd probably want to focus on an RTOS. That sounds remarkably similar to what we said. So, cool.

Well, that's scary in some respects. But yeah, a lot of things don't really need that level of complexity. But then, as I say, files and things interact with media where you want to retry things. And you really want to keep that abstraction away from whatever's collecting the data, perhaps, and be able to deal and retry things. And I guess that's one issue I guess I have with some of the ST examples

or examples in general. They tend to kind of ignore what goes wrong. It's like everything works fine if you don't get kind of errors, but when you get an error, everything kind of falls over and breaks. The implementation for the sdio attached to the fat fs it's like if it if one comes back and says yeah i can't read the the sector it's like it blows all the way back up through to the to the application and then the application says oh i just really stuck here whereas more considered i guess approaches would have kind of retries at various levels

and try to figure out well what is this error and is this recoverable is it is it a matter of the cards not installed properly is it is it something that I can reset and try again or is it something that I can I need to try more than once so I guess that's that's one problem with some of these examples and probably the cube stuff that it's like, yeah, it produces some code, but it's not really production ready.

You still have to spend some time and effort to kind of figure out where the flaws are. And that's a good thing to point out. It's really not production ready. And it may not do what you want when you think about the whole system. I mean, sure, it does what you want when you think about all of the pins and what they need to do, but still error handling and, you know, it doesn't care if this is a debug port. And so, you know, if you fail to handle it in time, it's sort of okay, but this port over here belongs to something important, so you must never fail. It's hard to do that programmatically, which is what Qubit is, a programmatic way to do the initialization.

Yeah, I see it as kind of rough plumbing or rough carpentry. It's like, yeah, you've tagged all this stuff together, and it's like, look, it works. And it's like, yeah, you've tagged all this stuff together and it's like, look, it works. And it's like, yeah, well, until I do this. Yeah. So, and I think that's probably a problem that the future generation here is going to have to deal with. It's like, well, it's only getting you halfway. You still really have to understand the mechanics behind it. Sounds like never trust the autorouter.

Yeah. Yeah, it is. like never trust the autorouter. Yeah. Yeah, it is. It's one of those problems. Like, yeah, it can make you a wonderful board, but it's like you take that to the PCB guy and he's like, yeah, you could half the price of this board if you didn't do that. So, yeah, I can see that. So, yeah, at some point you still have to physically understand

how these things work. And I guess that's what I try to do here some of the time is say look it's like yeah that's all well and good but it's like you really need to understand these aspects of how this is going to work well it's sort of like there people say more and more about how hardware and more and more software is like lego blocks and you just stick them together. Except... I wouldn't build my house out of Lego blocks. Exactly. Nobody builds bridges out of Lego blocks. And, you know, that's not even a metaphor at that point.

That's actual mechanical stuff. No offense to Legos. Sure, Legos are great for what they are, but please don't build my house out of Legos. Yeah, well, I've always thought of computers as kind of Lego kits where you can make your own parts. That's generally my philosophy of these things. As I say, I tend to kind of build tools to enable doing other things. And if I'm doing something that I think I'm going to do more

than once, I'll write a script. I'll write a little kind of naughty program that does that particular function or looks at a PLL setting or looks at some PLL registers. And I kind of plug in at one end the kind of clock they want to come out and the clock that I'm putting in. And it can spit out like half a dozen different register combinations to kind of get you to that point. And so that tends to make my life and work easier, that I'm not doing everything manually all the time. You can get a significant degree of mechanical advantage by just letting the computer do the stupid work. I think that's one of the things with being experienced

and being around for a while is you do accumulate these tools. People sometimes are surprised when I look at the map file and can make it look pretty. Although I've even gotten out of the habit of that because I'm just so used to the map files looking the way they do and I can read them. But for somebody new, that's such a, what's in there? How do I find it? And it gets tough. It's a skill that takes time to learn. Well, you have to have used it a few times for a reason.

You can't just say, well, today I'm going to go look at a map file. Well, the way that I got good at it was writing a tool so that I could see it in HTML probably. Yeah, HTML. And so I could graphically see how big my memory was and then I could find the one that was big. And that got me used to using the map files and that got me to now that I don't need the tool. Well, yeah, I've done similar things

with kind of disassembly listings and map files that you kind of you put them into something and crunch on them and you can come out with like cross-reference data you can come up with kind of sizes of things like you say and and you can kind of obviously if you used html you could probably kind of drill down into different things through the through the browser interface i yeah i've not really i've not really tried that kind of stuff, but it's a familiar sounding thing. And it's, yeah, it's like that you're not scared to kind of write a script in a walk or something else that just kind of munches on the files

and kind of spits it out in a kind of a usable fashion. Especially if you can plug that into a make file so that every time it kind of builds your application it's looking for some kind of critical problem it's like that that your particular routine got too big and that's going to be a problem for for timing or something and i've built things with the the process listing files and like look at the instructions and kind of attribute a kind of clock cycles to it. It's a lot harder to do now with caches and other things,

but with 68,000 processors, you could very easily go through the opcodes and give a pretty good estimation of exactly how many clock cycles something would take and then accumulate that across a subroutine or whatever. So, yeah, I think a lot of people these days just, they're reliant on the tools that they have and really don't understand how they can get the information they want. They're then dependent on the tool vendor to kind of provide something. Whereas I'd look at a.hex file and say, yeah, well,

I can parse that really easily and And I can generate that in a different form, or I can package the firmware up, a couple of firmwares together, I can put checksums across the images that I create and automate that portion of the ROM generation, let's say, in terms of how things are built. And that's not necessarily something that comes with part of the ide but in terms of making something that that works right in production each time it saves a lot of time what compilers do you prefer and what ide is um i've primarily used kyle for a lot of the stuff that i do i've used IAR to some degree. It strikes me as a bit more awkward,

but that's, I think, the familiarity I have with Kyle. Rowley is very good. I think one of the parts we used, the vendor had used Rowley as their tool set. So that tends to drive things a lot too. It's like, well, where is this code coming from? Who's going to use it? What does their management prefer as a tool?

So often people don't necessarily get to pick what IDE they get to use. They pretty much get one pushed on them by someone else. And the other thing that I use a lot is the Microsoft Visual C, just basically a command line compiler. If I was on Linux most of the time, I just use GNU C and build stuff there, but just build like command line applications just to do very simple things. Testing things? And these scripty things that we were talking about?

Yeah, kind of testing things or generating register content. That's one that I, when I read through the kind of reference manuals or the data sheets, it's telling me about certain limits on kind of what the PLL comparison frequencies should be and what are the minimum and maximum values for various things. And so I'll write little applications there that can fit what I want against the four or five different registers that I might have to set, and it will spit out optimum settings

or a couple of different optimum settings for those kind of things. So it might be programs that run like a couple hundred lines, but the sort of things you can kind of write from scratch very easily and don't take a lot of time. I use Excel for that. It's horrible. I mean, it looks horrible. It's horrible code.

It's terrible. But yes, I understand. Yeah, I've not really been a big adopter of Excel over the years. I can use it, but I haven't really used it. My father, he was one of the first guys that had one of these TI calculators, programmable calculators with a, I think it was like a magnetic strip card that you could run through it. And so we always used to think about how those kind of worked.

And he built quite an extensive library for the company that he worked for in a mechanical engineering perspective to kind of compute the size of shafts and tapers on mechanical pieces of equipment. And at some point, he handed off a lot of this kind of algorithm stuff to people that would put it into Excel. So he never actually made the Excel sheets. He understood the concept, obviously. But other people had a much better grasp of,

well, how do I express that in Excel and how can we kind of put an interface on that? And I guess that's probably where I would fall down. It's like, yeah, I can put equations in there, but putting a kind of a menu on the front of it or kind of automating, I think, would probably be a bit more awkward for me. So as I say, I've always used C as that kind of interface.

I've done Pascal before. I've done some Ork. But I've also, when I was at college, we had Linux machines that had the mental graphics I see software on. So I kind of got used to that kind of stuff. And then VAX machines as well. But the common denominator typically was always C, that you could always get something working quickly enough with that.

So from compilers to scripting methods to processors, which processors do you prefer? I mean, ST has a lot, and all of them have a lot, NXP and TI and Atmel. But do you have any ones that you, when somebody says, well, we should use this for a processor, you're like, yeah, let's use that. Or any that you want to talk about that you think oh no not that um well not so much i as i came from a background where we used like 68 000 processors and arm

and uh that had a very uniform and consistent instruction set. And ARM was very much like that. So I like that perspective. And the Cortex parts have made things a lot easier, certainly with respect to kind of interrupts and stuff. So the ARM 7 and ARM 9's got a lot more awkward, both in terms of that and the kind of alignment of data structures and things. And the Cortex fixed a lot of those problems. In terms of what I'm kind of alignment of data structures and things and the cortex fixed a lot

of those problems um in terms of what i'm looking at these days uh the the cortex m7 is is quite interesting that's a big one to run bare metal yeah i think it's getting a bit out a bit bit out there but uh i'm not sure that i like ST's implementation. They went with the single precision floating point which I think is a problem because I think people tend to use floating point as a crutch to solve kind of size issues with the numbers that they're working on but when you get to like 32-bit floating point you don't really have a lot of precision and certainly in the gps arena where i've done a lot of work you really need the kind of double precision

floating point i think that's one place where kind of atmel had made some better decisions in terms of their cortex m7 seven parts because you can pretty much pick different combinations of ip from arm to do that and i understand why st went the way they did because they think that the the the double precision core probably is three to four times bigger in terms of the silicon but on the other hand you you haven't really made that big of an advance over the the m4 part in terms of its floating point so yeah it seems to me if you're going to be running a 32-bit processor with 216 megahertz you said that as if that's a large number it is a large number compared to most of these a megabyte of flash and okay it's only got 320k RAM, but still.

Yeah, I just think at that point you have enough processing power to do lots of things that unless you're a super specialized you go to 32-bit floating point versus 64-bit, or 32-bit floating point versus 32-bit fixed point. You just get different precision. Yeah, well, now your number's got to fit in 24 bits, and it's like, yeah, people see, I think it's the biggest trap for the beginners because they don't think they really conceive of the loss of precision, that they just realize it's like, well, I can put this huge range of numbers in here.

And it's like, well, yeah, but if you start doing any math on those numbers, pretty soon you get the wrong answer and you don't understand why you got the wrong answer. So I don't know. Yeah. Some of these points, it's like, yeah, you're pretty much getting to the point

where it's like, yeah, run Linux on it. Have all of that kind of support in terms of kind of operating system and tools and so forth. Obviously, it's going to add some degree of overhead. But if you're running at 200 or 400 megahertz, you've got some to burn. Yeah, and that line keeps moving down. Well, Linux keeps a little thinner, and the cheap processors get a little heftier, so they're meeting more and more.

Did ST make the floating point decision? Did they get to say, well, our power numbers are better? There must have been some trade-off. They said, well, we're going to do it this way because then we can advertise this feature so silicon is money i mean that means that this processor is probably cheaper than the equivalent in a different vendor or better margin it's definitely something i talked to them very early on because it's like when it first came and when they first announced that they were doing it it's like well hang on a second it's like it doesn't really help

me it's obviously the things that i might use it on It's like, well, hang on a second. It's like, that doesn't really help me. Obviously, the things that I might use it on what other people might use it for. But it seems to be like a critical thing to have. If you're doing something with significantly more horsepower, you've got some different expectations for it. So my feeling was really that it just made the die significantly bigger. And it becomes much more critical, I think, in terms of the speed you can run things at and where the critical paths are. I haven't really done any kind of silicon design in that kind of area.

But it strikes me that that kind of thing is going to be frequency limiting. And so just at the back of an envelope, I seem to think that it's probably going to use like three or four times as much silicon just to do that. But the other conversation you have with them is, well, the core is now becoming a very small part of the entire device. If you've got a megabyte of flash on there and you've got 256k plus of ram that's taking a very large amount of space the peripherals are probably taking quite an extensive amount of

space and so where the core fits into that shrinks and shrinks so i i would i would the only thing that i can really think of is probably test time and maximum frequency that they felt that there was a problem there. But on the other hand, Atmel has a part that runs at 300 megahertz and delivers a double precision floating point. So it's hard sometimes to get into people's head about why they made a particular decision about kind of options with with the par and you know how they routed pins i think that's another one of my kind of pet peeves it's like you you've overloaded these pins to the point where i can't escape anything especially if you've got like an lcd or an sd ram on there you've just eaten 40 or 50 pins in a go, and you can't really recover from that in some circumstances. One of the features of this chip, the Cortex-M7 from ST,

is the adaptive real-time accelerator. Do you know what that is? Yeah, it's basically their answer to a caching mechanism. Because one thing that ARM did with the Cortex-M3 parts Yeah, it's basically their answer to a caching mechanism. Because one thing that ARM did with the Cortex-M3 parts was pretty much dispense entirely of a caching architecture. So what ST has done is put something in front of the flash despite whatever they can do with it is intrinsically very slow it probably has an access time in the order of like 35 nanoseconds for any particular line that they pull out and i think that they they have a flash line that's about 128 bits wide so 16 bits wide and what they've done is basically put a cache in front of the of the flash memory so that it can kind of prefetch lines from the flash

and that it can cache kind of more recent accesses. And the other thing that it does with the Cortex-M3 and M4 parts is there's a prefetch on the kind of instruction side to grab the next instruction. And what the cache does in that situation is basically get you to a kind of uh within the same cycle so it's it's not like zero weight state you're basically like a minus one weight state that it it already has the data so it can complete within the the current cycle as opposed to even SRAM cells are going to be one cycle away in terms of putting out an address and getting back the data. So the way the cache works in this situation means that effectively you can run out of flash as fast as and sometimes faster than you can out of RAM.

That's exciting. Yeah, I'm not sure how it works on the M7. I think the M7 has something different because I think architecturally the M7 has some caching kind of designed in at kind of a core level. But certainly on the F4 parts, it made a significant difference because the F1 parts, you were pretty much exposed to the slowness of the flash. And that's always, as I say, it's always been a problem for these guys and for the other IC vendors is that they can't really get the flash speed any higher so if you're if you're stalling kind of three cycles for every read of the flash memory pretty soon you're gonna 72 megahertz processor is running significantly slower and it's like well

why is why why is this got the responsiveness of somebody running like 24 megahertz and you go well that's how fast the how fast the flash runs and so you can't you can't really break out of that other than copying stuff into RAM and running it from RAM. And the RAM being 32 bits wide in lots of these situations, that's a more efficient place to come from. That and other problems.

Well, yeah. And then there's DMAing from your flash to your RAM and then running from the RAM and hoping that you've DMAed it. Well, and you have to have enough RAM to put your code in. There's just so many problems. Caches are nice.

Yes, well, they hide a lot of the ugliness. And I think, I guess one of the things you come upon when you use ARM processes as opposed to Intel x86-based systems is Intel worked through all of the bottlenecks and problems and put lots and lots and lots of silicon in there to kind of fix and hide the very subtle issues, whereas the ARM solution really is, it's like, don't do that. We're not going to put the silicon in there to protect you.

You're just going to have to kind of work around that. And I guess that's one of the issues that we've run into a couple of times with Cortex-M3 and STM32 parts where you have a pipeline processor. And the way it tailchains interrupts is as you're writing to the NVIC to kind of clear the interrupt or writing to the peripheral, I guess, to clear the interrupt that's poking the NVIC, that doesn't happen instantly. So if the last thing you do before you return from the subroutine is clear the source of the interrupt, it pretty much immediately re-enters because it's still signaling kind of down the line that this hasn't occurred and the right buffers haven't kind of gotten out to the peripheral across buses that run at slower speeds. And so you end up with like a phantom interrupt that re-enters

and you wonder why your code is broken if you haven't checked to see that it validated the source. And I guess one of the other ones, what was the other ones? Yeah, the people modifying timer registers. But it's like, yeah, you can't really do anything atomically at the processor level because the peripheral behind it is changing things. I think one of the things they did with the timing status register is that they basically said this,

you only need to write these mask values to this register to clear them. You don't read it and write it back with a kind of read, modify, write type instruction. And a lot of people miss that. But the people making the silicon understood what was going on and specifically accounted for the situation where it's like, yeah, if you do a read-modify-write on this and an interrupt or a status change occurs in between you reading it and writing it back out, you're going to end up kind of clearing that

because you're ending it with something that's not there. So it's like those are the kind of traps that are in there, and you see less of that kind of thing with Intel processors, but significantly more with kind of risk-based processors like the ARM. Switching subjects a bit, although probably another one where we sort of need a whiteboard to get through this. I have a few friends who, if you just say I squared C and ST in the same sentence, their eyes start to bug out in horror. Have you found that ST's I squared C implementation is not as robust as it could be? Oh, it's hideous. It is.

Well, the other thing is that I worked for Philips, as I say, and I did some IC design there, and I did work on my two CBUSes. It's a very clunky interface at the best of times. And then ST tried to kind of manage it within the silicon, and I'm not quite sure where the value of that is. But it seems that the state machine that they have can get into kind of odd states and just it just breaks down so i tend to it's like if i see one of those questions it's like i quietly back away from it because it's like i just there's no good outcome the the at some point i would probably just prefer to kind of bit bang the bus,

because that would be, I know that I can make that work. And I guess that's probably the other thing with kind of experience. It's like, yeah, I know how I can get this to work in a certain timeframe. It's like, I can play with this other thing. And it looks kind of like it might manage it. But it's like, you still have to deal with all of the error states that it might get into or the fact that it locks up these peripherals because the peripherals are pretty stupid. And most of them don't have an asynchronous reset signal going to them. So if you get them all confused,

there's not much hope of recovering from that. That's why you need a FET to their power lines on every GPIO. To make them shut up. I guess that's one of the other issues I had with one of the accelerometers. It had a pin so you could select between SPI and I squared C. And then there were issues with the state of that pin was at reset and how things were pulled up. And it's like, that's just always a bad thing. It's like, yeah, we definitely need to have a pull-up resistor on that.

We'll preferably not connect it to the processor at all because then it doesn't do anything weird when it starts. Yeah, that should just be a resistor. I mean, why would you hook that to your processor? Your processor is going to want to speak I2C or SPI, not choose. To be fair, I2C is always a mess every time I use it anywhere. Well, I think one of the things is it's like a chip select. It's like a

chip select for the, it's the chip select for the SPI and it also selects whether it's I2C or SPI. And so it's one of these kind of nightmare situations. It's an 8-pin part. They're pin limited and the device, yeah,

there's just not a good way of dealing with that. So I've had those kind of frustrations. And I think, yeah. And the other thing is over the years, you learn to recognize where all the traps are. And so the first thing someone says, well, my part doesn't do this, or it's like the software reset doesn't work.

And the first thing you think of is you haven't driven the N reset with a push-pull driver, right? Because that's a bidirectional signal, and your part won't reset properly at all if that's the case. And then other people that assume that they're generating the N-reset signal. And if you've got some other part that thresholds the power supply and drives it low, it resets their entire system. So it's like, well, when you turn off this other modem or whatever, why does it reset my computer? Well, because the power failed on it. The specifications for the part said you always supply power to it,

and you would send this other pin that says turn on and turn off. You don't remove the power from it. You always supply power, and you effectively control it with a different signal, and this end reset comes back because it's figured out that the supply disappeared. So you get those kind of things. But, yeah, there's a lot of those kind of pitfalls and traps that you see someone writing about something, and they're talking about something totally different,

and it's like, no, no, no, you need to step way, way, way back here because your problem is you're doing this one other thing. So there's usually like a couple of things where i see if i see something it's like and i'll bang out like four or five things where i think that that's almost immediately going to fail for some reason or other and see if they can pick one of the four or five reasons that i've supplied for it not working and they'll say well i was doing number four and it's like yeah well that's why it breaks and this is how you kind of remedy that that's such a great i mean i know this is your hobby and i know i understand

doing it because it makes you feel helpful it makes you feel good yes being right is always nice but um do you ever meet people you know from the forum do people buy you at beer at conferences for helping them um i've had one guy that's gonna bought me beers and beers and food is one of the guys on there is reasonably local to us here and there's a couple other guys that i recognize on the forum we we kind of chat out of band occasionally either skype or or email and have our own amusing kind amusing views on things that are going on on the forum. Kind of a behind-the-scenes kind of thing, I guess, where we just kind of chuckle to ourselves. But no, it's more of a kind of not necessarily being right all the time, although that obviously kind of helps and people appreciate that. But I think it's really making a difference because I think it's hard out there and people don't tend to get a lot of help.

And they're kind of thrown into these things, whether it's through their coursework or employment. There's a very high level of expectation of what they should know coming into things. And I think it's sometimes unreasonable to expect people to know all these things. And so being helpful, I think, is the primary thing. Doing good, making a difference, kind of changing the outcome is the way that I look at it. And it's just so much more helpful than calling people idiots

and saying, read the fine manual. Because it's like, yeah, you can be a troll idiots and saying, read the fine manual. Cause it's like, yeah, you can be a troll and that that's really easy to do, but it's like, it doesn't really, it doesn't really advance anything. It's like,

why do you come here? So I looked at the most active users on the ST forum and there's a system account with 2071 posts. And then there are two CliveOne accounts. They're both you, right? Yes. I think I've probably got at least three there. And that, I think, stems from the kind of dysfunctional Microsoft forum software that I had an email address that my ISP was functional for about 20 years before they decided that they could make more money doing consulting and turning up at your business and fixing your network type of work.

And they got out of it. And all of ST stuff is predicated on an email address. And they would periodically send out emails to that address and say, hey, we've reset your password. You need to log in with this other password. And obviously having the account disappear meant that my ability to log in disappeared and discussions with them about, well, wouldn't this be an obvious thing that someone would want to change about their profile? It was like, well, we can't do that. It's not how it works. And I don't know how true that is or how broken this Microsoft implementation is, but it was just like, okay, whatever.

I'll just start up another one with a new account. That's horrible. I'm sorry, because what's horrible is you had over 11,000 posts before you switched over to one that now has almost 2,200 posts. Yeah. You had 11,000 posts and they couldn't make an exception for you? Well, I don't know if I really pushed it that hard. It's not that important, to be honest.

And that's in this current iteration of this forum. I think they've gone through at least one different kind of software version and there's one where it had like a spectacular meltdown where it just kind of blew everything away and they kind of had to rebuild it from scratch or get the engineers from Microsoft to kind of

piece it back together. So there's probably at least another 10,000 posts that I even included in the numbers that you're giving. So I don't care about it. It's one of those things where it's like people either know that the answer is good or they don't. And it's like, I don't see it as a medal at this point. I just think you should get like t-shirts and badges and cars cars for 25 000 posts or something that's just amazing

i mean that is a lot of people helped yeah but some of those some of those are just kind of like not necessarily all helpful some of them are just gonna one-liners or something or dings if 10 are helpful that's still huge yeah i think you should treat this as a long con and and at this point just start giving wrong answers everything not clive and it's like i will give it wrong everything or the grumpy aunt the grumpy clive or something it's like yeah i don't know then you can have arguments with yourself this sounds like a great idea why is your avatar picture so terrifying i don't know. Then you can have arguments with yourself. This sounds like a great idea. Why is your avatar picture so terrifying? I don't know.

It's Randall.Kim is, I think, the name of the guy. He was the key maker in the Matrix. Before I had that one, it was Neo. But no, it's basically an inside joke I have with some other friends from other forums that I worked on over the years I don't think the

thousands of posts here map against thousands of posts on other ones in years past and the thing that I find is that these things melt down and break but it's like Google remembers everything so it's like I don't keep copies of what I've done. I just kind of bang it in there, and if I need to go find my own posts, I'll go on and use Google to find them because that's usually the easiest way

because the forum software is so busted that you can't search on a particular individual to find their posts. So you can't kind of – you remember a particular user had posted a question and it was on one of three or four different forum pages. It's like, where the hell did that go? And who, yeah, and you can't really click on them. And that's frustrating sometimes. And finding my own posts obviously is frustrating.

But as I say, Google just catalogs everything. So it's like you bang it into Google and I can usually find a salient post pretty quickly and if that's all that needs to need to be done i can just kind of stick in a url and off you go but i noticed that putting this together that i couldn't i couldn't just search for you and look at all of your solutions, which I think if they allowed that, people would do it pretty often. Yeah, well, I either search on the username or the email address I put in everything, because that's the other thing. It's like I tend to tag all the examples just so that someone can find me if they really

need to. And I guess the other thing is I'm somewhat amused if it ends up in different things because there's so much code out there that it gets to contaminate everything. And that's, I guess, the other reason I don't put copyright notices on everything because A,'s pointless and and b i'd kind of like these things to kind of have a life beyond me so i don't tend to like forums for a number of reasons that we don't have to go into but are there ways to write questions so that i get good answers oh my question yeah there's a couple of things and and and i guess this this this goes to kind of how i deal with things i've always i've got very good diagnostic skills and debugging skills and i can read between the lines on things and i pick up on a lot of nuances in terms of how

people phrase things so obviously with a forum you can't really you're not face to face with someone so you can't pick up their gestures and so forth. So I tend to try and look for that kind of stuff. The thing that often frustrates me is that if you're posting a question about something that isn't working and you can't fix it, don't selectively cut and paste the stuff that you think is broken and hasn't been able to fix it with, because that's probably not where it is. That you need to kind of provide enough kind of foundation and context to your question that it can be answered quickly. That I can figure out what processor you're using and I can figure out kind of if you've enabled

the clocks and some of the kind of more obvious things that always make things break. Yeah, I mean, that's good advice because writing out all of that stuff sometimes helps you find the bug. And then you don't even have to push submit. You can just go on and be done. It's nearly the same set of skills that you need as a tester to write good bug reports too yeah yeah well i think that i've always kind of matched out with like being like a car mechanic

it's like there's some pretty good car mechanics out there that are really good at figuring out from random descriptions people give them of noises and kind of how the accelerator or brakes respond that they can say yeah i know what that is it's this thing and you'd think well you could make a really good software engineer because you actually understand the mechanics of things and i people always focus on well it's like computers or electronics or we need to do this in school and this kind of thing and it's like no no you don't need to you don't need to strip out classrooms and put computers in them. You really need to go to the fundamentals of kind of problem solving

and kind of how to express problems in a way that people can solve them and how you can kind of think about problems and logical thinking. And I think that's really the skills that people need. They don't need to know how to Google things or use a word processor or use Excel. It's like those kind of things should be sufficiently evident if you understand the kind of mathematics and the other aspects of things. It's understanding behavior and then sort of looking for patterns in behavior. Yeah, because all these things are just kind of tools. But it's like if you don't know how you need to use the tools of fashion, the thing, then the tools aren't that useful.

People use Excel as an editor for things and they do the wrong, they use it for purposes that it should never have been designed to. Heck yeah. Don't look at me when you say that, because I totally deserve it. So I agree with you. There's a lot of math. There's a lot of reading the manuals and really understanding the broad strokes or being able to get enough from things so that you know where to look but that's a hard thing for people coming out of college or for makers who are got into it through arduino and now want to know how to do it professionally you mentioned uh the you books

joseph you and i'll put some of the links to the cortex ones in the show notes do you have other books you'd recommend uh not, I'm not so sure. For the ARM stuff, a lot of ARM stuff is really good. On a historical basis, I think, and things that still have a great deal of validity to them, a lot of the kind of Lance Leventhal and the Rodney Zaks books from the kind of late 70s and 80s, because they were interfacing interfacing various

bits of hardware and peripherals together and while that's all kind of gotten integrated now into kind of bigger ics the the the concepts really haven't changed a lot and the things and dealing with kind of memory and how memory functions so i guess i guess those would be kind of things that i'd say hey if you can if you can find those out on the internet it's like go pick one of those up it probably cost you three or four bucks but it's like and it's not a processor that you're using but it's the thing that i grew up with and it's it's it's how i got the foundation to understand the kind of more complicated systems and as i say i, I think people today just have, they're just overwhelmed with information. There's just so much.

It's like, where do I start? What should I look at? And I don't think the teaching necessarily helps some of this thing. And how people are drawn into technology. You see people that see it as a kind of a well-paid career thing and that's what they're focusing on whereas i kind of really came to this as like yeah this is really cool i can do these things i can i can i can make my own tools i can make my own computers i can do all these things and i came to it from a very from a very different place i guess so fair enough remember that z80 book the one that we

never get rid of because yeah that was a lance levin thought okay so i haven't found radney sacks yet but we will we will find some books and we will link them to the show yeah they both have like a fantastic number of books i think a lot of them are kind of replication of each other in many respects because they, they deal with the kind of foundational stuff of kind of bits and bytes and registers and, and so forth. And there's over the years,

it's like, there's more similarities in all this stuff than there are differences. It's like, yeah, you have to do slightly different assembler syntax or slightly different kind of mnemonics for various different things but at the heart these things are all like little machines and they all tick in the same way and it's like if you if you if you understand that you're ahead of the game

rodney zacks wrote programming the 6502 which'm looking right at it. Yeah, okay. Well, he wrote 6502 books. He wrote Z80 books. Yeah? I grew up on the 6502 running at 1 megahertz with like 32K of RAM. I think it's the first system I had. That was pretty good for the time. And then I went and I did some Z80. And my brother had an Atari ST with a 68, 68 000 so i kind of did things with that and it was just a it was

a great time for for doing that things back in the kind of early 80s and that's really where the kind of arm evolved from it's the the the guys that arm or the guys at acorn at that point had basically dealt with all those available processes. And they basically cherry-picked the best concepts from all of them and came out with something that was really stellar. And it took a while to kind of percolate to the point where it's in every cell phone, but it's still a hell of an achievement. Yes, and these books are still interesting because if you wonder why it happens this way,

well, because it made sense then and it carried forward because it still made sense. And you can look at something simpler to see why it got pushed that way. So those books are still useful. Yeah, and I think there's ones on kind of interfacing peripherals and building little boards and stuff there was a whole series that they did and i think radio shack had like variants of them and so forth but it's like yeah that that stuff makes sense and and in terms of my perspective on the silicon there's reasons that these things were done in certain ways because it was it's very efficient in terms of the transistors and the digital logic to do things certain ways.

And it's like some of the ways that kind of humans interact with things are just illogical when it comes to computers. So a lot of the fundamentals are based on some pretty kind of clear and simple rules about how to remove complexity. All right. I think we are about out of time. So I should ask you if you have any final thoughts. Well, my final, you asked me to think about this initially. I think really it's, if people want to participate in forums, it's like don't just show up with your questions.

It's like don't just lurk. Join in and kind of add something to the conversation and try to help someone else and improve things. That is such a wonderful attitude, you embody it and I appreciate it. So thank you. Thank you. My guest has been Clive Turvey, ST Forums guru and senior engineer at Janus Remote Communications.

I'd like to offer a special thank you to Dennis Jackson for telling me I should stop whining about forums and do what he does, look for Clive's answers. He wrote, when you're reading through the posts on the ST forums, anything written by Clive1 is gold. And thank you as always to Christopher White for co-hosting and producing and for searching for a new home for us. If we miss a show next week, which we might, I expect it will be because the realtor won't let us record a show during the open house. Clearly, she doesn't know how much this podcast would raise the sale price of our house. And thank you, of course, for listening. I have a final thought from J.M. Bari in Peter Pan. The fairies, as their custom, clapped their hands with delight over their cleverness,

and they were so madly in love with the little house that they could not bear to think that they had finished it.