Shop OBEX P1 Docs P2 Docs Learn Events
QuickStart compatible cpu board Prime — Parallax Forums

QuickStart compatible cpu board Prime

ErNaErNa Posts: 1,742
edited 2016-01-15 09:07 in Propeller 1
New Year, next board. As it will take some time to have a P2, there is a board containing two P1 and an additional XMC Cortex M0. This board contains a propeller on top and bottom, those are daisy-chained. The XMC 1100 serves as flash memory to boot and gives some more extras like ADC's and I/O-pins
State of the project: components are ordered, after verification of all dimensions and space restrictions, there will be a few prototypes to see if the expectations are met.
SnSh17.10.2015-23.50.2217.10.2015-23.53.0013.1.2016-17.09.35.gif
1309 x 921 - 94K
SnSh17.10.2015-23.50.2217.10.2015-23.53.0014.1.2016-14.56.11.gif
1436 x 949 - 28K
SnSh17.10.2015-23.50.2217.10.2015-23.53.0014.1.2016-14.52.01.gif
1327 x 1033 - 23K
SnSh17.10.2015-23.50.2217.10.2015-23.53.0014.1.2016-14.51.26.gif
1455 x 981 - 39K
SnSh17.10.2015-23.50.2217.10.2015-23.53.0015.1.2016-10.17.48.gif
1267 x 851 - 73K
SnSh17.10.2015-23.50.2217.10.2015-23.53.0015.1.2016-10.16.15.gif
1300 x 986 - 98K
«134

Comments

  • DavidZemonDavidZemon Posts: 2,973
    Cool!! This looks like fun :)
  • Roxanna77Roxanna77 Posts: 18
    This looks exciting, count me in for a couple!
  • David BetzDavid Betz Posts: 14,511
    ErNa wrote: »
    New Year, next board. As it will take some time to have a P2, there is a board containing two P1 and an additional XMC Cortex M0. This board contains a propeller on top and bottom, those are daisy-chained. The XMC 1100 serves as flash memory to boot and gives some more extras like ADC's and I/O-pins
    State of the project: components are ordered, after verification of all dimensions and space restrictions, there will be a few prototypes to see if the expectations are met.
    Sounds interesting! Can you post a schematic?

  • ErNaErNa Posts: 1,742
    David Betz wrote: »
    Can you post a schematic?
    Done, this is the current, certainly not the final version. But the principle should be clear: The top propeller (P0) is connected to the female header, the bottom propeller (P1) to the male header, there is no general connection between top and bottom ( exception: supply, clock, etc) The P0 boots from the XMC (Optional flash) and the P1 lower from flash, but P0 can download to P1.

  • David BetzDavid Betz Posts: 14,511
    ErNa wrote: »
    David Betz wrote: »
    Can you post a schematic?
    Done, this is the current, certainly not the final version. But the principle should be clear: The top propeller (P0) is connected to the female header, the bottom propeller (P1) to the male header, there is no general connection between top and bottom ( exception: supply, clock, etc) The P0 boots from the XMC (Optional flash) and the P1 lower from flash, but P0 can download to P1.

    Thanks!
  • Cluso99Cluso99 Posts: 18,069
    ErNa,
    Looks nice!
  • ErNaErNa Posts: 1,742
    I have added separat screenshots for top and bottem layout. This will be a 4layer board to ensure signal integrity and to allow a compact design. As can be seen: there is plenty of free board space available as a design goal was to keep the # of vias small to have the functions mostly on a single side. That allows to exchange functional block quite easily
  • Heater.Heater. Posts: 21,230
    Cool. Us armchair board designers have talked about a board that marries Prop and ARM for ages. Nice to see some one has actually done it.

    What was the motivation for using the Cortex-M0? Us armchair designers might have gone for an STM32 F4 for it's floating point capability.
  • ErNaErNa Posts: 1,742
    Poor selection process ;-) XMC2Go was at that moment promoted and the first idea was just to replace the flash. Learn to know, how all this microcontroller stuff has to be handled. Now the flash emulator is ready, needs a lot of interrupt stuff and universal I/O configuration, the learning curve was like always, when you deviate from the single true way of controlling the world ;-)
  • Heater.Heater. Posts: 21,230
    Hmm...why bother with a FLASH emulator?

    If you have an ARM and and a Prop on the same board why not just have the ARM download code to the Prop on boot up with the normal serial protocol.



  • ErNaErNa Posts: 1,742
    yes. but that is a flash emulator. If you download the prop from the pc F11, the prop sees the arm as a flash and later can boot from the arms internal flash. But just must program the arm to do this.
  • David BetzDavid Betz Posts: 14,511
    ErNa wrote: »
    yes. but that is a flash emulator. If you download the prop from the pc F11, the prop sees the arm as a flash and later can boot from the arms internal flash. But just must program the arm to do this.
    Is booting the Propeller all that the ARM will be used for? Will there be any way to talk directly to the ARM over the USB2serial interface?

  • ErNaErNa Posts: 1,742
    The idea is to "memory map" other functions into the flash's unused address space. The first idea was to have the XMC as a slave i2c, that can respond to different addresses. But it seems, that changing device ID can not be done dynamically. So the props access to the flash in memory space > 32 k will communicate with other peripheral. An alternative would be to use a second channel, but that would consume additional pins.
  • David BetzDavid Betz Posts: 14,511
    So I guess the ARM acts as a Propeller peripheral after booting?
  • Heater.Heater. Posts: 21,230
    Well, that is the thing. Who is the dog and who is the tail?

    In my mind the ARM would boot the Propeller with whatever firmware is required to do the job.

    No EEPROM required.

  • ErNaErNa Posts: 1,742
    Currently the XMC just emulates a 32 k Eprom. (XMC's flash: 64 k) The XMC firmware is programmed via a debugger. If I understand correctly, Peter J. can program an XMC via a propeller, so it should be possible to load the prop via rs232, the prop flashes the XMC and after this the prop can use XMC as a standard 32k boot flash memory. We will open source this project, so everyone can contribute. Currently, knowledge about ARM processors is a must for any engineer, but creative engineer mustmust know the propeller. Enventually the industry will accept this, but this takes time.
  • David BetzDavid Betz Posts: 14,511
    Heater. wrote: »
    Well, that is the thing. Who is the dog and who is the tail?

    In my mind the ARM would boot the Propeller with whatever firmware is required to do the job.

    No EEPROM required.
    I always figured that the ARM would be the master in an ARM+Propeller setup. The idea would be to have the ARM run the high-level program logic and use the Propeller as a smart peripheral to interface to any external hardware.

  • ErNaErNa Posts: 1,742
    ARM is just a cosmos. While Prop is the niche. In math: Prop = 1/ARM . Now we can take into account, that there are imaginary number ;-)
  • DavidZemonDavidZemon Posts: 2,973
    David Betz wrote: »
    Heater. wrote: »
    Well, that is the thing. Who is the dog and who is the tail?

    In my mind the ARM would boot the Propeller with whatever firmware is required to do the job.

    No EEPROM required.
    I always figured that the ARM would be the master in an ARM+Propeller setup. The idea would be to have the ARM run the high-level program logic and use the Propeller as a smart peripheral to interface to any external hardware.

    It depends on your external hardware, which ARM, and what high-level logic is needed.

    If...
    your external hardware is a bunch of analog values that need to be converted and some I2C or SPI chips
    your ARM is a Cortex-M
    and your high-level logic doesn't include floating point and/or requires some serious parallelism...

    then the Propeller will make a far better master than the ARM.

    If...
    your external hardware is a custom protocol serial bus or an input pin that requires a fast response
    your ARM is an M4F or better (more powerful than Cortex-M series)
    and your high-level logic includes floating point or something else that an 80 MHz propeller can't handle...

    then the ARM makes a better master.
  • David BetzDavid Betz Posts: 14,511
    Well, I guess this board would allow either to be master depending on the firmware flashed into the ARM so I guess it has both bases covered.
  • ErNaErNa Posts: 1,742
    This board to me is: a quickstart board that allows to build multi propeller demos, interfaces to the arm world, so people can have a ARM board and are introduced to the propeller and finally realises a long lasting idea to have an acompanion chip. Unfortunately the choice was not the best one, but that may change. And a way to create forks board with different features on the front side, one is: a three axis stepper driver
  • David BetzDavid Betz Posts: 14,511
    ErNa wrote: »
    This board to me is: a quickstart board that allows to build multi propeller demos, interfaces to the arm world, so people can have a ARM board and are introduced to the propeller and finally realises a long lasting idea to have an acompanion chip. Unfortunately the choice was not the best one, but that may change. And a way to create forks board with different features on the front side, one is: a three axis stepper driver
    Sounds great! When can I get one? :-)

  • ErNaErNa Posts: 1,742
    OK, the components are ordered, we will check that everything fits (e.g. sd-card holder), then order pcb's, assemble, test, .. will take some time. But hope to be ready before P2 is launched ;-)
  • David BetzDavid Betz Posts: 14,511
    ErNa wrote: »
    OK, the components are ordered, we will check that everything fits (e.g. sd-card holder), then order pcb's, assemble, test, .. will take some time. But hope to be ready before P2 is launched ;-)
    Okay, I'll try to be patient. Actually, I have something else to keep me occupied in the meantime: an ESP8266-01 board connected to a PropMini. That should allow me to try out some of my ideas for a hybrid system while I'm waiting for your board.

  • kwinnkwinn Posts: 8,697
    Heater. wrote: »
    Well, that is the thing. Who is the dog and who is the tail?

    In my mind the ARM would boot the Propeller with whatever firmware is required to do the job.

    No EEPROM required.

    Does it really matter, and is it really necessary to designate a dog and a tail? Why not have each one do what it does best. Something along the lines of co-routines, where propeller performs it's functions and functions requested by arm, and arm does its functions and those requested by propeller.
  • Heater.Heater. Posts: 21,230
    kwinn,
    Does it really matter, and is it really necessary to designate a dog and a tail?
    I guess not.

    It's just that my ARM machines run Linux and have internet connections.

    A Propeller is a peripheral to all that.



  • kwinnkwinn Posts: 8,697
    Heater. wrote: »
    kwinn,
    Does it really matter, and is it really necessary to designate a dog and a tail?
    I guess not.

    It's just that my ARM machines run Linux and have internet connections.

    A Propeller is a peripheral to all that.



    Yes, using the propeller as the tail and a PC, Odroid, or Pi as the dog is pretty typical, but it doesn't always have to be that way. Now that arm chips have multiple cores it might be advantageous to offload things like floating point calculations or table lookups to a dedicated core.
  • ErNaErNa Posts: 1,742
    edited 2016-01-15 20:25
    dog or tail, that is the question. If I imagine what efforts Mouser undertakes to run the business to supply me some components, it is incredible. All the world around has to exist just to satisfy me! The only person I know which also works for itself is Chip ;-)
  • Heater.Heater. Posts: 21,230
    I'm not sure but I think that offloading floating point from the Prop to an ARM, or any other device, will be slower than doing it on the Prop in the first place.



  • David BetzDavid Betz Posts: 14,511
    Heater. wrote: »
    I'm not sure but I think that offloading floating point from the Prop to an ARM, or any other device, will be slower than doing it on the Prop in the first place.


    Doesn't it depend on what you're offloading. If you make a request to the ARM for every add, subtract, etc. then it will certainly be slower than doing the same in software on the Propeller. However, what if you offload an entire FFT?

Sign In or Register to comment.