1 2 Previous Next 14 Replies Latest reply on Jan 21, 2015 3:42 PM by user_14586677

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

    user_246598725

      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

        • 1. Re: Writing software for PSoC device without the graphical part of PSoC Creator
          user_1377889

          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

          • 2. Re: Writing software for PSoC device without the graphical part of PSoC Creator
            user_246598725

            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

            • 3. Re: Writing software for PSoC device without the graphical part of PSoC Creator
              user_14586677

              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.

              • 4. Re: Writing software for PSoC device without the graphical part of PSoC Creator
                user_246598725

                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

                • 5. Re: Writing software for PSoC device without the graphical part of PSoC Creator
                  user_1377889

                  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

                  • 6. Re: Writing software for PSoC device without the graphical part of PSoC Creator
                    user_246598725

                    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

                    • 7. Re: Writing software for PSoC device without the graphical part of PSoC Creator
                      user_14586677

                      The 8051 will live on forever (ugh) -

                         

                       

                         

                      www.eetimes.com/document.asp

                         

                       

                         

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

                         

                       

                         

                      Regards, Dana.

                      • 8. Re: Writing software for PSoC device without the graphical part of PSoC Creator
                        user_1377889

                        Yes, the 8051 may live forever (sigh)

                           

                         

                           

                        Bob ;-)

                        • 9. Re: Writing software for PSoC device without the graphical part of PSoC Creator
                          user_246598725

                          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

                          • 10. Re: Writing software for PSoC device without the graphical part of PSoC Creator
                            doug.springer

                            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.

                            • 11. Re: Writing software for PSoC device without the graphical part of PSoC Creator
                              user_342122993

                              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

                              • 12. Re: Writing software for PSoC device without the graphical part of PSoC Creator
                                user_1377889

                                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

                                • 13. Re: Writing software for PSoC device without the graphical part of PSoC Creator
                                  user_342122993

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

                                     

                                  odissey1

                                  1 2 Previous Next