Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

[SOLVED] Typical beginner microcontroller questions

Status
Not open for further replies.

d123

Advanced Member level 5
Joined
Jun 7, 2015
Messages
2,505
Helped
494
Reputation
992
Reaction score
525
Trophy points
1,393
Location
Spain
Activity points
27,148
Hi,

I'm doing preliminary research/reading about using a microcontroller. I see I have a lot more to read before a lot of the fun of e.g. making LEDs blink, but still. The attached picture is if it helps to visualize the basic idea - it's a block diagram concept, not a complete circuit design. I'm posting the thread because before I accidentally spend time going down the wrong path reading and trying to do, I wondered if the basic plan I've come up with is - in principle - workable or I've misunderstood something I have read so far. And I have some pertinent questions.

Background:
ICs I have at my disposal are:
FT245BM (USB to parallel)
AT90S1200
AT90S8515
Assorted logic and so on to fill gaps where needed.

Money to buy interface tools, etc = 0.00

I have a laptop with no parallel port, so that simple-looking to implement programming interface isn't possible.
I've read a lot of the FDTI application notes about the FT245BM and the relevant datasheet, and downloaded the relevant drivers and utilities they provide which will be needed and/or useful. I think I more or less understand it and what it does and what I have to do with it. I still some major doubts about what pins go where on the AT90Sxxxx for parallel programming that are irrelevant questions for the timebeing.
I've read two decent manuals on programming AVRs with assembler code and other related material. I still have to go through the 'avr-instruction-set-manual'.
I've downloaded the Studio 7 program and am halfway through reading the user manual, and I have read a couple of other things that are related to this.
I realised today that I need to learn how to calculate values in hexadecimal as I don't understand that part and the examples of e.g. ADD and ADDC baffle me - again, irrelevant for the timebeing.

Question(s):
I understand it is better to write the code in Assembler language as it is smaller, quicker, etc. But, it looks like the examples I will need to desperately try and fail to understand in e.g. Studio 7 are all in what looks like C of one kind or another. Is it a good idea to start off in Assembler if coding experience is only a little Visual Basic several (many) years ago and a tiny bit of HTML and a tiny bit of Python? Assembler looks managable from the examples I have seen so far, or does it become inscrutable when things are not working as wished for and C+ or C++ is less painful to debug?

re the 'programming board idea - Is that going to/Theoretically, should it work: Studio 7 with projects written in Assembler > USB port > FT245BM >AT90Sxxxx ? Am I missing anything very important from even just a block diagram concept?

Just checking my confusion: The executable code I write goes to the Flash memory (e.g. 'normally do this, if X do that, if Y don't do the other, etc'), the constant values I may need for calculations (e.g. maybe a few constants/values for a bad humidity sensor that drifts enormously with temperature and has a long equation to correct the error) go to the EEPROM?
It is more important not making mistakes with the program code as the Flash is very limited read/write and I should be using the IDE to try to ensure this, so a lot of time is spent developing in the IDE in software and not so much time in-circuit post-programming in hardware? EEPROM gets read/written to much more often and during the execution of a program?

I must say, from what I've read so far, this all seems very time-consuming, convoluted and complicated just to get an LED to blink via a pushbutton, I can do that without the MCU as the go-between and just use my finger instead... (joke).

Pathetic picture:
overview of basic plan.jpg
 

First I would say C is generally more important, productive, easier
to debug that ASM.

I have worked with a few different micros since 70's, and today I spend
most of my time with PSOC because its ARM, has routability (you can wire
up internally and externally various components), lots of digital components
(in PSOC language a component is an onchip resource), and lots of analog stuff
like opamps, comparators, A/D's, Analog Muxes, Vref, PGA, DSP.....So I am a big fan of
them for low to mid range embedded projects.

And using schematic capture and/or Verilog build your own custom components inside
them.

You basically drag and drop "components" internal to the PSOC onto a schematic page,
right click them to config, and linki to datasheet which has prewritten C API calls to
control them in code (rarely do you ever write a driver), and wire up to other internal
components and/or pins. Program done via boards USB debug interface and IDE

IDE (PSOC Creator) and compiler free, good board to start with $ 10 (maybe free will
address this below).


Side note, when using a new board and as a beginner, connect to each pin you are going
to use a 2K - 5K R so that in case you accidentally short a pin or hit it with V > that its power
you can avoid burning out part.

Tons of videos on you tube and at www.cypress.com

Tons of working example projects in IDE you can use/modify for your own purposes.

The board you want is -


Contact either their sales office or a local FAE (Field Applications Engineer) or
sales rep and ask for a sample, explain your situation. I'll bet you could get a free
board. Refer to yourself as a developer in training, thats what you are.

For instrumentation use PC as sig gen and scope. Web has multiple examples.
ABSOLUTE MUST use protection circuits for soundcard input so you dont blow
up your PC.

If you do not have a scope you can get Zeitnitz freebe which turns your
PC into a scope, spectrum analyzer, tone generator. But you have to protect your sound card
inputs to make sure you dont blow up your PC audio channel.
Its good for audio freqs.

Soundcard Scope

Software projects of Christian Zeitnitz
www.zeitnitz.eu

Daqarta - Sound Card Input Range and Limiter Circuits

Project 154

ESP Audio Projects - PC Oscilloscope interface.
sound-au.com

www.nutsvolts.com

Turn Your Computer’s Sound Card into a Scope

Use this free software tool to gain oscilloscope skills, analyze audio signals, and measure digital signals.
www.nutsvolts.com
--- Updated Mar 4, 2021 ---


When you use a scope probe its the ground lead that slips on a board
connecting )using alligator clip) and flops around hitting part pins and
grounding them blowing up parts. Always secure that carefully with that
in mind. That precaution and the series R mentioned absolve will offer
a lot of protection.


Regards, Dana.
--- Updated ---

Misc info, projects, attached "
 

Attachments

  • Component List (2).pdf
    278.5 KB · Views: 112
  • PSOC Projects.txt
    580 bytes · Views: 130
Last edited:
Hi,

A huge post..

Regarding hardware:
My personal opinion. You may start with whatever you have. Go through it. Read datasheets and examples.
But then try to find out what in the future want to do (I guess you can't decide this now), what processing power, what memories, what periferals you need.... Then it's very likely you move to another microcontroller.

Regarding programming language.
I've started with assembler and that was good for me. But nowadays sooner or later you will use C.
But even when writing C it will be very helpful if you can read and understand assembler.

Generally I'd say it's not very important with what hardware and what language you start. But be open to change...
Changing from one hardware to another or one language to another will not be that big deal.

Klaus
 
  • Like
Reactions: d123

    d123

    Points: 2
    Helpful Answer Positive Rating
Hi Dana,

Thanks for the articulate reply. What appreciable changes you must have seen re MCUs and interfaces that facilitate your work on several levels... First, 'developer in training' - 🤣 - ...what a sense of humour, if you could see some of the more pathetic moments of my 'home-based training'... There's a reason 'hobbyist' often has a negative connotation, I see it first-hand in myself (when all else has failed, try randomly moving wires around until something works, that or you do the brush the wrong pin with the wrong wire and blow the fuse thing).

You touch upon points I'm very bothered about: I really don't want to damage a USB port - or worse the whole laptop - due to bad design or incompetence. I wouldn't trust myself with the soundcard oscilloscope just yet but sorely need a better one as mine is frustratingly single channel (laborious guessing if signals coincide or not, probing one by one alongside using the ancient technique of LEDs on outputs to see what's happening when...grrrrrr), I have a simple oscilloscope that I could use for 'slow' signals. As I still breadboard most stuff (any SOIC parts etc. on homemade adapter boards), probe ground is a 'short' (3cm) wire wrapped into the crocodile clip that goes in one of the breadboard holes to avoid what you mention at the end. I'll look at the soundcard probe links you posted after this.

I hope you don't mind my saying, the thing with PSOC stuff is that it looks and sounds great (lots of configurable digital and analog in one) but/and it seems to be drag'n'drop design, and before that method I'd like to learn a bit deeper than that with regard to what I need to and can do with the MCUs (plus, I was kindly given them - it would be a waste and a bit rude not to [at least try to] use them). I think PSOC is good if you just want to get a project done quickly, maybe and don't mind some of the limitations related to basic MCUs (e.g. next to no or just a few analog and A/D parts onboard) (?).

I'll bear in mind that you consider C to be preferable for troubleshooting (making is always easier than fixing, IMO) and the other two aspects you say; partly that would be as C can be used elsewhere but Assembler only with MCUs, I guess. That puts me in a fix because I'd like to know Assembler as supposedly it is - besides faster to execute and smaller in size - closer to how the MCU 'thinks' (without trying to learn machine language, obviously). I suppose as I'll have to follow the tutorials which are in C to avoid getting utterly lost at first between code and IDE, I'll have to start with C anyway.

What I'm seeing is that every part of this type of design (unlike preferred analog/discrete IC circuits where you think of a circuit and can sometimes skim read most of the datasheets involved to get the salient points before implementing the parts, 'though before my time I have a silly fondness for names like National Semiconductor, Harris, Burr-Brown, etc.) from code, to writing program, to programming device, to troubleshooting is a lot of reading before even bothering to think about touching any components (again).

Thank you for answering and your input, and taking the time to put the useful links, much appreciated.
 

A couple additional thoughts. First you can do ASM with PSOC as well, but I would
say it should be inline ASM wrapped in C. Regarding ASM over C performance, not
an expert here but on a number of occasions I have looked at the generated ASM
from C and todays compilers, Freescale, PSOC, ST generate asm so concise these days
the difference is quite small in performance. I found in may case as canonical as ASM.

Another feature that is interesting is what I call codeless design. PSOC has a library
of gates, flops, counters, shifters, LUT, that you can drag and drop onto canvas,
wire up. and w/o writing a single line of code hit the build button and tool generates
the setup code (always done) for the part and your design is done. In fact you can use
the more complex onboard components, doing just the static config with a right click,
and write one line of code, a start instruction, and then build. Thats for cases where
no real time change is being done to the component. Think graphical FPGA like.

Some of the stuff in the part -

1632511869205.png


Using basic gates you can do the learning you seek to create expanded functionality.

And there is a library users have done of 74HC MSI parts....
1632512272782.png


A third capability, I use quite often, is I create a test facility for design in the core
design I am doing, like pulse and timing generation that I can test the core design
I am doing with onchip resources in same part. Super handy. Once I fin design I
simply erase all that GUI HW I created and move on.

Its like having a breadboard in a chip. From basic to complex.

Here is example with very little code in it creating bursting waveforms with DDS
control, all single chip. Its capability included freq, number cycles, waveform shape,
interburst delay, and number of bursts.



Then there is a state machine wizard in it just for that purpose. Here is an example
doing traffic light controller -

Note this can be done on the $10 board I mentioned earlier as well.


Oscilloscope, ever consider building a multi channel scope muxer front end ?



Regards, Dana.
--- Updated ---

As you get experienced. Here I am now training myself to learn Verilog.
In PSOC you can use a mix of schematic capture and/or Verilog to create
your own components. Here is a 64 bit SIPO shift register on a chip.

 
Last edited:

Analog stuff onchip -

1632567214400.png


COM onchip -

1632567466149.png



LCD, DMA.......

Regards, Dana.
 
  • Like
Reactions: d123

    d123

    Points: 2
    Helpful Answer Positive Rating
Hi,

A huge post..

Regarding hardware:
My personal opinion. You may start with whatever you have. Go through it. Read datasheets and examples.
But then try to find out what in the future want to do (I guess you can't decide this now), what processing power, what memories, what periferals you need.... Then it's very likely you move to another microcontroller.

Regarding programming language.
I've started with assembler and that was good for me. But nowadays sooner or later you will use C.
But even when writing C it will be very helpful if you can read and understand assembler.

Generally I'd say it's not very important with what hardware and what language you start. But be open to change...
Changing from one hardware to another or one language to another will not be that big deal.

Klaus

Hi Klaus,

Thanks. 'Minor' concern is that the Studio 7 program doesn't accept a homemade board as a programming tool ,or does but it becomes too complex a procedure for a beginner to manage to implement, as I sense I am attempting to glue various things together that may not fit together without a lot of knowledge I do not currently have and/or workarounds or copy/pasting code snippets I won't understand just to try to make the programming tool (which I sense is a very big learning curve obstacle in the way of trying the first project for beginners of 'making an LED blink'). I looked at the Microchip manual and the website again today but found no relevant information to know this with certainty, except for a schematic (by someone in Atmel and dated 2006...) for a USB to UART serial 'dongle' using the FT232 - that at least makes me vaguely hopeful about the chances of using the FT245BM as my USB to parallel 'dongle' and it working with Studio 7, when/if I figure out the puzzle of the MCU needing three more signals than the FT245 provides in the basic schematic in its datasheet.

Yes, right now, I just need to try to implement (very) basic projects with available parts to get the feel for a lot of things, not fussy as I expect the related headaches and naïve mistakes will be very informative. I understand why the educational manuals suggest doing the design first, then choose the MCU to fit those needs.

Interesting about C being ubiquitous and necessary. I've noticed that it's Visual Basic language and very similarr to Python.

Many thanks for your comments and so on.
 

Hello!

Very long post indeed and very long replies. I have the impression that we diverge
here, and if we want to stay focused in "beginner microcontroller questions", then
we shouldn't advice using verilog / VHDL modules.

So, back to the basics:
FT245BM (USB to parallel)
AT90S1200
AT90S8515
Assorted logic and so on to fill gaps where needed.

These are only chips, not boards, right?
I would advice to start with a microcontroller board, be it TI, ST or anything else.
Advantages:
- You will probably not break your PC (apparently you are a bit worried)
- You can find many examples online
- There are free tools (compiler, etc)
Drawbacks:
- It will cost you some money. If your budget is really 0, then I guess it will not
be easy, but if you can spend a few euros, then you can have a board, and everything
else is free. Probably you can find somebody to give you one board. I got a few free
boards from TI and ST booths at exhibitions. Even one with a brushless motor development
kit, so it is possible.

So basically if you want a quick start, buy or get a board, and you will see that your
led blink program will be achieved in less than 1 hour, all installations included.

Now one more comment:
I understand it is better to write the code in Assembler language as it is smaller, quicker, etc.

You can indeed learn a little bit about assembler, but most of the time, recent compilers
produce code which is as compact as assembler. Yes, you can save a few bytes, probably.
But is it worth the effort? Beside this, your code will be limited to the processor you
are using, it will not be usable on another platform.

Dora.

NB: that said, your profile says that you are on this site since 2015, that you have
helped many people, etc... which seems to indicate that you are not a beginner.
 
  • Like
Reactions: d123

    d123

    Points: 2
    Helpful Answer Positive Rating
Hi,

concern is that the Studio 7 program doesn't accept a homemade board as a programming tool

Maybe someone has a non_parallel programmer lying around that is not used anymore.
I will PM you if I find one. I wouldn't be surprised.

Klaus

Don't mix "parallel PC port" with "parallel AVR programming mode:

Most AVR programmers use the ISP (serial program downloading port, similar to SPI) while they use USB or serial port for communication with PC.
Even the simple programmers that use the parallel PC port use the serial programming interface ISP.

I never used a programmer which uses the (HV) parallel programming mide of the AVRs.

I guess there are programming SW tools around that use the FTDI in SPI mode.

Klaus
 
Last edited:
  • Like
Reactions: d123

    d123

    Points: 2
    Helpful Answer Positive Rating
Hi,

Jolly good. Good advice, much appreciated.

'You can indeed learn a little bit about assembler, but most of the time, recent compilers produce code which is as compact as assembler. Yes, you can save a few bytes, probably. But is it worth the effort? Beside this, your code will be limited to the processor you are using, it will not be usable on another platform.'

Most illuminating, thanks.

'Don't mix "parallel PC port" with "parallel AVR programming mode:'

:)
No, not that bad, but not far short of that kind of misunderstanding, either...

'Most AVR programmers use the ISP (serial program downloading port, similar to SPI) while they use USB or serial port for communication with PC.
Even the simple programmers that use the parallel PC port use the serial programming interface ISP.

I never used a programmer which uses the (HV) parallel programming mide of the AVRs.

I guess there are programming SW tools around that use the FTDI in SPI mode.'


Right, that's a bit of a pointer of where to progress towards and where not to, thanks. I did children's decimal > binary > hexadecimal and vice versa exercises this morning (and left the ones about fractions and two's complements and carrys for another day when I understand those things more...) and then I spent some of the afternoon with the FTDI documents again and a variety of web searches to understand that a bit better. It's going slowly (fumbling around in the dark for a match!). FTDI app note about synchronous bit-bang data transfer seemed closest to understanding how to parallel program through it. Now I see that the FT245 doesn't perform magic, the code the user writes or copy/pastes tells it how to transfer data to the MCU. I'll re-direct investigations to serial programming, then.

Apart, I noticed that in the things I found about FT245, assorted projects and professionally-made tools all used the USB-B as the board/module connector - is there any special reason for using that one and e.g. not a micro-USB or a USB-A connector?

Actually, also, an FTDI app note said not to connect the USB shield to the PCB ground but instead to the case, and another one suggested connecting it to the PCB ground via either a 0 Ohm resistor or a high frequency capacitor - if the case is plastic, which is preferable: 0 Ohm resistor or low value capacitor?
 

Status
Not open for further replies.

Similar threads

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top