Shop OBEX P1 Docs P2 Docs Learn Events
Can I do this complex multi-threaded task on propeller, without much hassle? — Parallax Forums

Can I do this complex multi-threaded task on propeller, without much hassle?

CuriousOneCuriousOne Posts: 931
edited 2014-12-25 05:15 in Propeller 1
We have some chip, this chip should be able to do following tasks altogether, without one task causing problems to another one.

Drive and multiplex 4 digit, 7 segment display, pretty much like MAX7219 does, but without using any additional hardware, such as shift registers and so on.

Constantly monitor voltage on 4 inputs and calculate some dependencies from these values.

Work with 4x4 matrix keyboard.

Constantly measure pulse width and quantity on 2 pins.

generate PWM signal on 4 outputs, based on some internal data.

drive some logical level outputs

an additional "core" should interpret all the data received, and send data to display unit, outputs and pwm module, according to calculations.


Is this all possible with propeller?

Technically, I know I can do it all with PICbasic and some 18F high end chip, but interrupt management from picbasic is pain in the back.
«1

Comments

  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2014-12-16 23:34
    CuriousOne wrote: »
    We have some chip, this chip should be able to do following tasks altogether, without one task causing problems to another one.

    Drive and multiplex 4 digit, 7 segment display, pretty much like MAX7219 does, but without using any additional hardware, such as shift registers and so on.

    Constantly monitor voltage on 4 inputs and calculate some dependencies from these values.

    Work with 4x4 matrix keyboard.

    Constantly measure pulse width and quantity on 2 pins.

    generate PWM signal on 4 outputs, based on some internal data.

    drive some logical level outputs

    an additional "core" should interpret all the data received, and send data to display unit, outputs and pwm module, according to calculations.


    Is this all possible with propeller?

    Technically, I know I can do it all with PICbasic and some 18F high end chip, but interrupt management from picbasic is pain in the back.

    I think that practically almost all of that could be done even in a single core, but certainly depending upon the frequency of the pulse width measurement that might go on it's own cog and of course having an application cog simplifies things too.

    As for the 7 segment display and keypad matrix that can be easily run from the one cog along with monitoring voltage etc as your scan time has to be fairly slow and so it may as well monitor voltage while it's sitting around. The multi-channel PWM can run from one cog and I can get up to 32-channels of 8-bit 7.6kHz PWM from the one cog.

    cog #1 PWM
    cog #2 keypad + display + monitor voltage
    cog #3 measure pulse width
    cog #4 application cog which also drives outputs
    cog #5 free!
    cog #6 free!
    cog #7 free!
    cog #8 free!

    You still have the option to split cog #2 up but the scan loop for that is non-critical and very easy to implement.


    btw, your requirements are not at all complex but certainly they are simple to implement on the Propeller.
  • Cluso99Cluso99 Posts: 18,069
    edited 2014-12-16 23:36
    Nothing here is complex for the prop.
    But...
    Do you have enough I/O pins?
    What current do you require for the 7seg LEDs - the common anode/cathode may require a transistor driver depending on the total current.
    You will need to do ADC for the voltage inputs, requiring an extra pin - see the ADC app note. I have decoded a touch screen using 5 pins.
    From what you describe you should have enough cogs.
  • Mike GreenMike Green Posts: 23,101
    edited 2014-12-17 09:13
    If you split up the cog #2 functions so that one cog does the keypad, one does the display, and one does the voltage monitoring, you'll further simplify the coding. One of the beauties of the Propeller is that, by assigning one function to a cog, the code becomes linear and pretty straightforward. The cogs communicate with each other via shared variables. The keypad cog would simply scan and debounce the keypad. When a keypress is available, it stores it in the shared variable, probably as a value from 0 to 15. The shared variable is initialized to -1. Your main program would check to see if the shared value is -1. If it's -1, there's no keycode available. If it's not -1, it's a new keycode value and the main program would set the variable again to -1. There are I/O drivers (objects) in the Propeller Object Exchange for scanning keypads that you can use as a starting point.

    Here's one OBEX object (http://obex.parallax.com/object/715) for scanning a 4x4 keypad using a few passive components and only 1 I/O pin.
  • bte2bte2 Posts: 154
    edited 2014-12-17 10:14
    My first knee-jerk reaction was "of COURSE you can do it with the Propeller. Easily. In fact, I cannot think of any other way I would WANT to do it". How's that for a testimonial?

    Not trying to sound like a fanboi, but Propeller is good stuff. I started on Motorola assembly and did a lot with that way back then, and I know a thing or two about the 8031 and the Z80s, and it continually blows my mind that the propeller is as versatile as it is.

    Propeller is a fantastic concept that actually works- it is real nice when your project has a nice snappy keyboard, the display is nice and fluid, while it's running 4 serial ports, reading and averaging 8 analogs, outputting to the PC and sending it wirelessly all at the same time.

    Arduino, phooey.
  • pik33pik33 Posts: 2,366
    edited 2014-12-17 10:30
    The pin count can be too low.

    Drive and multiplex 4 digit, 7 segment display - 11 or 12 pins
    Constantly monitor voltage on 4 inputs and calculate some dependencies from these values - 8 pins
    Work with 4x4 matrix keyboard - 8 pins
    Constantly measure pulse width and quantity on 2 pins - 2 pins
    generate PWM signal on 4 outputs, based on some internal data - 4 pins
    drive some logical level outputs - some more pins

    Total 34 plus some more pins... and the Propeller has 28 of them free (these 28..31 pin has to be left for eeprom and uart)
  • bte2bte2 Posts: 154
    edited 2014-12-17 10:34
    pik33 wrote: »
    The pin count can be too low.

    Drive and multiplex 4 digit, 7 segment display - 11 or 12 pins
    Constantly monitor voltage on 4 inputs and calculate some dependencies from these values - 8 pins
    Work with 4x4 matrix keyboard - 8 pins
    Constantly measure pulse width and quantity on 2 pins - 2 pins
    generate PWM signal on 4 outputs, based on some internal data - 4 pins
    drive some logical level outputs - some more pins

    Total 34 plus some more pins... and the Propeller has 28 of them free (these 28..31 pin has to be left for eeprom and uart)

    Okay, but for a negligible bit of silicon he can have a very nice display and knock 10 pins off that count. Maybe not one chip, but as close as can be. Still a win.
  • bte2bte2 Posts: 154
    edited 2014-12-17 10:43
    He could decode the digit selects and scan the 4 digits with two pins.

    I assume there will be other hardware mounted on this board, and I guess I'm confused as to why the aversion to shifting out the display data. Nice elegant solution for 50 cent's worth of silicon. Considering that none of this was possible 20 short years ago, I think that doing what he wants on a board not much bigger than a business card is a miracle. I used to lay out boards with technical pens and vellum.
  • pjvpjv Posts: 1,903
    edited 2014-12-17 11:21
    To keep hardware simple, the analogs can be done with one pin each using a slightly modified Sigma Delta approach. That saves 4 pins,

    And the digit select lines can double as 4 keyboard select lines, saving another 4 pins.

    So that leaves 6 pins left over for other things, and no extra hardware used.

    Cheers,

    Peter (pjv)
  • ErNaErNa Posts: 1,752
    edited 2014-12-17 13:23
    I have tested sigma delta with multiplexed inputs, needs 4+1 pins. I believe: it can be done
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2014-12-17 14:27
    I thought the emphasis was on software ability, not how the hardware would be implemented but I will make a few assumptions then. I would be using an adc chip rather than rely on the Prop's sigma-delta unless I wasn/t worried at all about DCaccuracy. So pick either an I2C ADC = zero effective I/O or an MCP3208 for 3 I/O.
    The 4 digit LED display could be driven from a numberof chips but let's assume it's discrete drive and we have 8 segment drives and 4 column selects, so that's 12 I/O. But wait while we are scanning the display we can also be scanning the 4 columns of the keypad with the same I/O although we need 4 row inputs. So that makes the discrete keypad/display closer to 16 I/O. Also the reason I assigned these to the one cog and due to the slow scan time it can easily read the ADC.

    So far 19 I/O total plus 4 for PWM out = 23.
    Measure pulse width. How many? Let's say two so that's 25 I/O so far.
    Drive some outputs but once again how many? If we give it 3 but once again more can be had over I2C. So that's 28 I/O + 2 for I2C + 2 for serial = 32.

    The greatest hog is the display + keypad and there are many ways of reducing this, even dumb shift registers work well (4 74HCT595s + resnets drive 4 digits directly off 5V).
  • pjvpjv Posts: 1,903
    edited 2014-12-17 15:22
    Peter:

    You are right, the emphasis WAS on the software, and that is easy with multiple cogs, but if there were insufficient I/O pins, then there was little point.

    And, because the OP was asking for no additional chips -at least on the display- I presumed that there was a desire to keep all external hardware to a minimum, and hence I suggested single pin Sigma Delta analog conversion, requiring no extra chips.


    ErNa;

    The Sigma Delta can be done with a single pin per channel by using some twisted code, albeit not with great speed, nor great precision.... probably 8 bits, but can't recall just now.

    Cheers,

    Peter (pjv)
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2014-12-17 15:41
    pjv wrote: »
    Peter:

    You are right, the emphasis WAS on the software, and that is easy with multiple cogs, but if there were insufficient I/O pins, then there was little point.

    And, because the OP was asking for no additional chips -at least on the display- I presumed that there was a desire to keep all external hardware to a minimum, and hence I suggested single pin Sigma Delta analog conversion, requiring no extra chips.


    ErNa;

    The Sigma Delta can be done with a single pin per channel by using some twisted code, albeit not with great speed, nor great precision.... probably 8 bits, but can't recall just now.

    Cheers,

    Peter (pjv)

    Ah, "no additional hardware such as shift registers", yes. Quite unrealistic really, I mean choosing to use a 4 digit 7-segment LED display indicates you need the visibility which at times means bright which means current and that cannot be realistically expected to be sourced from any micro. Even at 10ma/segment average that would still result in 320ma exceeding the absolute maximum ratings of the Prop chip. No, these need extra chips of some kind, so unless he is happy to have it not so bright or state why he needs LED displays so we can consider an alternative then he cannot do it without additional hardware.

    Has anyone really used the sigma-delta for DC other than low precision stuff?
  • pjvpjv Posts: 1,903
    edited 2014-12-17 17:19
    Peter;

    Right with your interpretation. I guess it all depends on what the OP's requirements are. A huge guess from this side.

    Regarding Sigma Delta, I use them in quasi precision work.... thousands of units sensing temperature via thermistor with a few degrees of accuracy, and sensing wheatstone bridge pressure sensor to a few millivolts. Only a few of thos made, but hopefully a big bunch coming up.

    Cheers,

    Peter
  • ChrisGaddChrisGadd Posts: 310
    edited 2014-12-18 05:09
    If pins are the concern, you could use a charlieplex driver for the display, which can handle all four digits with only nine pins.
    Here's an object I wrote and have tested with ten digits - http://obex.parallax.com/object/753
    The displays are quite readable even when driven directly by the Prop pins.
  • AleAle Posts: 2,363
    edited 2014-12-18 09:43
    Yes, I have done that and more :). You may be constrained by the number of available pins. Some helper cheap ICs could save valuable pins (a '164 driven fast enough for the LEDs...) But I used little spin :)

    I had:
      cognew(@c0_start, 0) ' lcd driver
  cognew(@c4_start, @c4_lmm_start) ' screen refresh, user interface
  cognew(@c2_start, 0) ' keyboard reading
  'cognew(@c3_start, 0) ' communications with other propeller
  cognew(@c6_start, 0) ' Oscillator daugtherboard control (2x DDS)
  cognew(@c7_start, 0) ' Output control
  'cognew(@c5_start, 0)
  'repeat
    Cog 0 had the serial debug terminal if compiled, I used bst at the time ;)

    I made the user interface in LMM, not to brag but it was quite cool at the time. I should have used spin... knowledge comes (sometimes) with experience and as time slips away...

    Edit: I look at the code and a tear forms in my eye. I used everything I developed and talked about here at the time: LMM, BCD math and FFT, and bst of course.
  • kwinnkwinn Posts: 8,697
    edited 2014-12-18 10:30
    It's very simple to combine the keyboard and display scan so both only require 12 pins. Done that with common anode displays and for sure it can be done with common cathode displays as well. It also helps a bit with key debouncing.

    Not 100% sure that can be done with charlieplexing, but it might be possible.
  • CuriousOneCuriousOne Posts: 931
    edited 2014-12-20 13:05
    Hello.

    Thanks everyone for detailed explanation!

    Let me clear some things.

    1st, I know how to do all above with additional hardware, maxim even has a chip which can do both led display driving and keyboard scan at same time. So all this is quite old stuff (for me) and I'm interested in alternative ways, because:
    2. as it was remarked, since I need to fit all this in single chip, this might be because I have space constraints, and this also means that 7 segment leds being used are also quite small and need tiny amount of current. It also can be estimated, since I need smallest footprint, want to use led display, this means that I'm doing a rugged device, which should work on temperatures below zero, so, no LCD's welcomed.

    The reason why I asked to split code across the cores, is for better readability and independency of program components.

    Voltages does not need to be monitored with great accuracy - 8 bits will be enough. Pulses will be the sync signal from tv video, so no super speed or accuracy also here.
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2014-12-20 15:44
    CuriousOne wrote: »
    Hello.

    Thanks everyone for detailed explanation!

    Let me clear some things.

    1st, I know how to do all above with additional hardware, maxim even has a chip which can do both led display driving and keyboard scan at same time. So all this is quite old stuff (for me) and I'm interested in alternative ways, because:
    2. as it was remarked, since I need to fit all this in single chip, this might be because I have space constraints, and this also means that 7 segment leds being used are also quite small and need tiny amount of current. It also can be estimated, since I need smallest footprint, want to use led display, this means that I'm doing a rugged device, which should work on temperatures below zero, so, no LCD's welcomed.

    The reason why I asked to split code across the cores, is for better readability and independency of program components.

    Voltages does not need to be monitored with great accuracy - 8 bits will be enough. Pulses will be the sync signal from tv video, so no super speed or accuracy also here.

    Didn't think you were coming back! Still don't know about the extra I/O, however what you want will fit into a Prop but unless you retask the serial and I2C lines there aren't any I/O left over, but it does do what you want.

    COG I/O FUNCTION
    0...4...PWM
    1...16..8x4 LED + 4x4 KEYPAD (4 common)
    2...2...MEASURE SYNCH
    3...5...4 CHANNEL SIGMA-DELTA A/D with common feedback
    3...5...APPLICATION inc SERIAL + I2C + 1 extra I/O
    4
    5
    6
    7
    =...32 I/O
  • CuriousOneCuriousOne Posts: 931
    edited 2014-12-21 07:07
    So if I understand properly, there is no Propeller, with more than 32 I/O available?
  • PublisonPublison Posts: 12,366
    edited 2014-12-21 07:14
    CuriousOne wrote: »
    So if I understand properly, there is no Propeller, with more than 32 I/O available?

    All variants of the Propeller have 32 I/O pins. It has been that way since day one.

    http://www.parallax.com/sites/default/files/downloads/P8X32A-Propeller-Datasheet-v1.4.0_0.pdf

    To add more I/O would require external hardware.
  • kwinnkwinn Posts: 8,697
    edited 2014-12-21 08:28
    Peter Jakacki wrote: »
    Didn't think you were coming back! Still don't know about the extra I/O, however what you want will fit into a Prop but unless you retask the serial and I2C lines there aren't any I/O left over, but it does do what you want.

    COG I/O FUNCTION
    0...4...PWM
    1...16..8x4 LED + 4x4 KEYPAD (4 common)
    2...2...MEASURE SYNCH
    3...5...4 CHANNEL SIGMA-DELTA A/D with common feedback
    3...5...APPLICATION inc SERIAL + I2C + 1 extra I/O
    4
    5
    6
    7
    =...32 I/O

    I am almost certain (99.44%) that you can reduce the number of pins for #1 from 16 to 12 pins by interleaving reading of the keypad with multiplexing the display.

    At the beginning (or end) of each digit select set the 4 digit select pins and 4 of the segment/dp pins to inputs.
    Set 1 of the 4 remaining segment pins that are still outputs (also connected to keypad columns) high.
    Input data from the 4 segment pins that were set as inputs (also connected to keypad rows) and de-bounce/decode any keypress.
    Repeat for each digit select so: col1/ds1, col2/ds2, col3/ds3, col4/ds4.

    Done in pasm the keyboard scan portion of the code would be so fast that it would have very little effect on the brightness of the leds.
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2014-12-21 08:58
    kwinn wrote: »
    I am almost certain (99.44%) that you can reduce the number of pins for #1 from 16 to 12 pins by interleaving reading of the keypad with multiplexing the display.

    At the beginning (or end) of each digit select set the 4 digit select pins and 4 of the segment/dp pins to inputs.
    Set 1 of the 4 remaining segment pins that are still outputs (also connected to keypad columns) high.
    Input data from the 4 segment pins that were set as inputs (also connected to keypad rows) and de-bounce/decode any keypress.
    Repeat for each digit select so: col1/ds1, col2/ds2, col3/ds3, col4/ds4.

    Done in pasm the keyboard scan portion of the code would be so fast that it would have very little effect on the brightness of the leds.

    I wonder if you need to anyway since there are enough I/O already plus there's still the serial and I2C left over that can be repurposed easily enough. If only 28 I/O are needed and the Propeller has 32 then it is a good fit.
  • JRetSapDoogJRetSapDoog Posts: 954
    edited 2014-12-21 15:42
    CuriousOne wrote: »
    So if I understand properly, there is no Propeller, with more than 32 I/O available?

    With 700+ posts, you're joshing us, right? Yanking the 'ole chain. Yes? No? (BTW, I do know that it would be possible to miss that by focusing on applications and so on.)

    But that gets me to thinking: suppose (and I'm just speaking off-the-cuff, here) we had a version of the Propeller with, oh, I don't know, say double the number of I/O pins. And, while we're just dreaming, why not double the number of cogs (to 16), as well. Oh, and more memory would be nice, say on the order of 16X more (for a total of 512KB). Hmm, maybe we should create a webpage similar to the following to discuss such a beast: http://forums.parallax.com/showthread.php/155132-The-New-16-Cog-512KB-64-analog-I-O-Propeller-Chip

    Speaking of which, over on the P2 forum, aren't we about due for an update? But be that as it may, the posters here are right about trying to get the most out of the available resources as possible. And to very loosely paraphrase Ken's "design with what we offer" advice, a Prop 1 in the hand is worth two Prop 2's in the fab.
  • kwinnkwinn Posts: 8,697
    edited 2014-12-21 20:44
    Peter Jakacki wrote: »
    I wonder if you need to anyway since there are enough I/O already plus there's still the serial and I2C left over that can be repurposed easily enough. If only 28 I/O are needed and the Propeller has 32 then it is a good fit.

    What can I say Peter, I'm a firm believer in the "waste not, want not" philosophy, and on top of that I like to keep pins 28-31 free if possible. On top of that I can see that doing the two tasks together saves some duplication of code when compared to doing them separately. To add icing on top of that there might even be code space and time enough left to add a third task to the cog.
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2014-12-22 00:54
    kwinn wrote: »
    What can I say Peter, I'm a firm believer in the "waste not, want not" philosophy, and on top of that I like to keep pins 28-31 free if possible. On top of that I can see that doing the two tasks together saves some duplication of code when compared to doing them separately. To add icing on top of that there might even be code space and time enough left to add a third task to the cog.

    Yes, my IoT5500 module does all that it does with SD filesystem and network servers in basically one cog, although another one is used for serial console receive and another for background timing functions. So with the OPs requirements I don't see a problem with handling keypad and display in one cog since they are I/O linked and can just do what they do in sequence. But if the OP finds it's easier to use more cogs, well then, that must be easier.

    BTW, I never like to repurpose my I2C and serial but some may never use serial normally and I guess the I2C could be used for column selects etc but in this situation there are sufficient I/O anyway. To me the I2C is a bus, something that some seem to forget and how many times do I see other I/O used for I2C when there are two there waiting to be used. As for the serial, it's my interactive console link for programming, debugging, reporting etc.
  • CuriousOneCuriousOne Posts: 931
    edited 2014-12-23 02:37
    I'm not joking. I'm task-related person. I came to microcontrollers (basic stamp), since I needed control over certain activities, I have evaluated pros and cons and went with BS due to best documentation available, compared to arduino and others. Same now, I'm evaluating propeller, if I'll find that it is suitable my needs, I'll go into deeper details of it.

    Currently, I have two main competitors - on one side there's Propeller with Spin, and on the other side, PIC18F45K22 with Picbasic pro. The later seems to be more easy to study, since 99.99% of basic stamp code can be directly used, but multitasking appears to be very tough task with picbasic pro, so this is why I'm looking into propeller.
  • ErNaErNa Posts: 1,752
    edited 2014-12-23 03:50
    Your project seems to me like a prototype to many others. So, if you are going to more precisely document your requirements, this could easily be made a common project. I just write a demo for a 8*8 LED matrix, I have a buttons object, that needs some house keeping, pwm objects are just around the corner: And, as you try to do it with as little hardware as possible, it could be done on an QuickStart Board, for example
  • kwinnkwinn Posts: 8,697
    edited 2014-12-23 07:26
    CuriousOne wrote: »
    I'm not joking. I'm task-related person. I came to microcontrollers (basic stamp), since I needed control over certain activities, I have evaluated pros and cons and went with BS due to best documentation available, compared to arduino and others. Same now, I'm evaluating propeller, if I'll find that it is suitable my needs, I'll go into deeper details of it.

    Currently, I have two main competitors - on one side there's Propeller with Spin, and on the other side, PIC18F45K22 with Picbasic pro. The later seems to be more easy to study, since 99.99% of basic stamp code can be directly used, but multitasking appears to be very tough task with picbasic pro, so this is why I'm looking into propeller.

    Over the years I have worked with a lot of uC's, starting with ttl based systems built around the 74181 and on to 8008, 8080, Z80, 65xx, 68xx, 1802, and so on. On most of those projects whether the base high level programming language was some form of Basic or something else I ended up coding some part of it in the chip's assembly language. Getting the assembly code and hll code working together was always a hassle.

    Combining spin and pasm is hassle free, and multitasking on the propeller is a breeze compared to an interrupt based system.
  • Heater.Heater. Posts: 21,230
    edited 2014-12-23 07:35
    Curious One.

    There is no competition. Use the Prop. Unless the PIC has some built in peripherals you really need that the Propeller lacks. Or it wins on speed or RAM space. I don't know the PIC but I doubt it. Or unless there are some other pressing needs like power consumption or physical size.

    Spin is as easy to use as any BASIC. Except perhaps if you need floating point numbers.

    Multi-tasking, at least up to 8 tasks, is of course a breeze on the Propeller. Depending on your tasks you can of course do many things in a single COG, much the same way as people manage to combine many functions into an Arduino or whatever single core device.

    As a bonus you get to tap into the huge and willing support network here on the forum.
  • bte2bte2 Posts: 154
    edited 2014-12-23 12:27
    Peter Jakacki wrote: »
    how many times do I see other I/O used for I2C when there are two there waiting to be used.

    I do so hardware problems won't stop the Prop from booting.
Sign In or Register to comment.