Writing software for PSoC device without the graphical part of PSoC Creator

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
RaAl_264636
Level 6
Level 6
50 sign-ins 25 sign-ins 10 solutions authored

Hi,

   

 

   

does anybody know if it's possible to write software for the PSoC devices without using the graphical part of PSoC Creator?

   

 

   

Reason why I ask is that I should get our electronical trainees to the first touch with microcontrollers, and I'm thinking about to use the PSoC devices for education.

   

However, since the PSoC approach of graphical programming/configuration and ready-made APIs is a bit uncommon compared with other microcontrollers, I want to first teach the 'generic way', meaning that the trainees should write the drivers for timers, UART, etc first completely by themselve before allowing them to use the APIs provided by PSoC Creator or using the schematic part of Creator.

   

That means, there wouldn't be any schematic used in the first projects. So, each and every thing must be written manually, beginning at configuring and controlling ports, modifying the internal oscillator, timers, etc.

   

But, I'm not sure if this can be done, especially when thinking about the connection of e.g. timer output to a given pin, etc.

   

 

   

Regards,

   

 

   

Ralf

0 Likes
15 Replies
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

Cutting out the additional hardware from a PSoC chip will leave a mid-sized, average performant embedded. Only the core resources are usable which indeed contain a timer, but even ARM delivers a library to access the M0 and M3 internals.

   

So what you can do is to reduce the contents of the component catalog to the lesson's essential requrements. This will give you the opportunity to just use Clocks, Pins and ISRs and -if you like to- introduce your own components designed with VeriLog. Basic techniques as programmable logic (LUT), gates (no, not Bill), output drivers(oe,pullup/dwn, etc) will be enough to gnaw on for the first bunch of lessions and will be quite common to other embeddeds.

   

Since the design for PSoCs differ from the design of "normal" embeddeds PSoCs can do things that the others cannot perform. Yes, there are common IDEs for the programming of embeddeds like Eclipse, µVision or IAR, but these are just for programming the chip when the components are already defined and set up.

   

 

   

Bob

0 Likes
RaAl_264636
Level 6
Level 6
50 sign-ins 25 sign-ins 10 solutions authored

Hi Bob,

   

 

   

your approach needs at least some schematic actions, so it's not directly what I want to have. However, reducing the component catalog might be the 'plan B' 🙂

   

 

   

Regards,

   

 

   

Ralf

0 Likes
ETRO_SSN583
Level 9
Level 9
250 likes received 100 sign-ins 5 likes given

However, since the PSoC approach of graphical programming/configuration and ready-made APIs is a bit uncommon compared with other microcontrollers, I want to first teach the 'generic way', meaning that the trainees should write the drivers for timers, UART, etc first completely by themselve before allowing them to use the APIs provided by PSoC Creator or using the schematic part of Creator.

   

 

   

Actually ready made APIs are now very common in the industry, to wit Freescale, Microchip.......

   

 

   

Writing drivers means a very deep dive into architecture and register TRM for the part, and I

   

would think constitute a multi year class. Would be very instructive but not a short simple class.

   

 

   

You could work at the gate level, using schematic editor, or use verilog as the basis of gate

   

level design. That I would think would be a very good relevant approach for a student. I started

   

working with processors 42 years ago toggling instructions bit for bit with switches, and punched

   

cards for mainframes, and paper tape for minis, absolutely no desire to go back there.

   

 

   

Regards, Dana.

0 Likes
RaAl_264636
Level 6
Level 6
50 sign-ins 25 sign-ins 10 solutions authored

Hi Dana,

   

 

   

good comment - I see the educational part from my own point of view, where I was educated on the 8051 core, writing firmware in assembler language with a text editor under DOS 😉

   

I don't want to teach them assembler, this shouldn't be really necessary nowadays. But I want them to be able to write own APIs and peripheral drivers, and that's why I want to avoid using the included APIs etc for the early beginning... hmmm... it leads me to the idea to make it a two part process, where I'll use a small 8051 which is pretty easy to understand, let them write some drivers and then switch to Cortex-M0/M3... have to think about it...

   

 

   

Regards,

   

 

   

Ralf

0 Likes
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

I do not want to start the fire (... it was always burning...) but don't you think that the 8051 is a bit old-fashioned to teach? It has got only 256 bytes of stack, a non-regular register architecture and is only 8 bits wide. its design was 1980 and there have been several improvements in processor architecture since. 35 years is a long time for processor design and the alternatives can be found in every cell-phone nowadays: ARM processors.

   

 

   

What is your idea of writing a "Driver" for ie a timer? Where does the timer come from? Where are its properties set?

   

Wouldn't it be a great success for the class to read and understand the timer's datasheet and set it up accordingly to some given requirements.

   

When you want to skip that above step, you might provide the schematics and have the timer set up by the class and programmed to run.

   

 

   

Bob

0 Likes
RaAl_264636
Level 6
Level 6
50 sign-ins 25 sign-ins 10 solutions authored

Hi Bob,

   

 

   

I do not want to start the fire (... it was always burning...)...

   

that's why I said I've to think about the two-part approach... you're right, nowadays ARM is everywhere. On the other side, the 8051 is really easy to understand (even with the uncommon memory/register model). It has pros and cons... However, one thing is common to both architectures: they're the only architectures which are produced by multiple manufacturers.

   

 

   

What is your idea of writing a "Driver" for ie a timer? Where does the timer come from? Where are its properties set?

   

The idea is to force the student to take the datasheet & reference manual and read about the needed steps to configure a peripheral like e.g. UART by writing to the SFRs. That needs to understand the effects of the SFR bits, and what happens if some needed SFRs are forgotten to be initialized. But it wouldn't help to understand it if the API or the graphical interface would take care of such things - there's no learning effect if someone can click the configuration as needed. I think it's mandatory that the students know how to do it manually before they use the 'convenient' way.

   

 

   

Wouldn't it be a great success for the class to read and understand the timer's datasheet and set it up accordingly to some given requirements.

   

Yes, that would be a great success. But, again, if they use only the API and the graphical user interface to configure a timer or UART, they won't get in touch with the underlying SFRs, etc.

   

 

   

When you want to skip that above step, you might provide the schematics and have the timer set up by the class and programmed to run.

   

I don't want to skip a step, it's more like to introduce an additional step.

   

 

   

Regards,

   

 

   

Ralf

   

 

   

PS: seems that it's not possible to format the text well on FF

0 Likes
ETRO_SSN583
Level 9
Level 9
250 likes received 100 sign-ins 5 likes given

The 8051 will live on forever (ugh) -

   

 

   

www.eetimes.com/document.asp

   

 

   

Huge legacy code base, so precious......

   

 

   

Regards, Dana.

0 Likes
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

Yes, the 8051 may live forever (sigh)

   

 

   

Bob 😉

0 Likes
RaAl_264636
Level 6
Level 6
50 sign-ins 25 sign-ins 10 solutions authored

It isn't a bad architecture, and as I wrote above, it's one of two architectures produced by multiple manufacturers.

   

I agree that it wouldn't make much sense to teach also the 8051, it should be enough to focus on ARM.

   

 

   

Regards,

   

 

   

Ralf

0 Likes
Anonymous
Not applicable

I hate to say it, but the 8051 was pretty bad even at the time. There were and are far better architectures out there. The 256 bytes of stack is a killer, but the real heartache are some of these archaic tools. When I first came across the Keil compiler my first thought was that I had fallen through a hole in time back to 1980....

   

If you really want to do embedded controllers you can always use something like an AVR - in-circuit programmable with tons of cheap open source and open hardware programmers, GCC tool chain, and anything from inexpensive 1$ parts to really spendy ones.  You won't get programmable hardware like with the PSoC, but it's very simple to build embedded code, and it's very easy to do so as well.

   

If you want programmable hardware, then just do programmable hardware. The trouble with the PSoC is that the IDE only runs on Windows, and is quite limited when going to a professional environment with things like code re-use and version control. It is also more complicated in that it has the CPU/Memory AND the programmable logic.  The idea behind the PSoC is great, and it's nice to see some hardware out there that was a concept over 22 years ago.

   

Can you build all this outside PSoC Creator? Yes, but it's incredibly painful. Ask me how I know.

0 Likes
odissey1
Level 9
Level 9
First comment on KBA 1000 replies posted 750 replies posted

I mean to start new thread, but it seem to be related: is it posiible to instantiate components in code dynamically at run-time without actually dropping component on the page at design time? In some imaginative OOP language it would look like that:

   

 

   

EEPROM_1 = EEPROM.Create;

   

//do something, e.g. save data to EEPROM

   

/...

   

EEPROM_1.FreeAndNil;

   

 

   

regards,

   

odissey1

0 Likes
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

The question is: what happens to the underlying hardware (flash in case of the emEprom) when the component is freed. Memory would be re-used. Bad, when you rely on the values.

   

Yes, it is possible: Each connection,every component and all the UDB sare only manipulated by setting values in some "Registers" you only have to know which register and which bit. This is the software-job of the "Fitter".

   

 

   

Bob

0 Likes
odissey1
Level 9
Level 9
First comment on KBA 1000 replies posted 750 replies posted

can you give some example or maybe direct to other links on howto work through code?

   

odissey1

0 Likes
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

See TRM www.cypress.com/

   

 

   

Bob

0 Likes
ETRO_SSN583
Level 9
Level 9
250 likes received 100 sign-ins 5 likes given

Youc an always drop on schematic a component and then look at API code generated

   

by Creator for example code base. It will be a mix of ASM and C.

   

 

   

Regards, Dana.

0 Likes