Shop OBEX P1 Docs P2 Docs Learn Events
TACHYON O/S V3.0 JUNO - Furiously Fast Forth, FAT32+LAN+VGA+RS485+OBEX ROMS+FP+LMM+++ - Page 71 — Parallax Forums

TACHYON O/S V3.0 JUNO - Furiously Fast Forth, FAT32+LAN+VGA+RS485+OBEX ROMS+FP+LMM+++

16869717374109

Comments

  • Hello everybody!
    I've got a problem with TACHYON O/S and BOA Board
    I'am used latest version of TACHYON:
    08/26/2015 08:21 PM 406,406 Tachyon V2.7.spin
    08/26/2015 08:34 PM 109,995 EXTEND.FTH
    Tachyon.spin was load to EEPROM successfully; but trying to
    EXTEND forth via HyperTerminal I've got this error:
      Propeller .:.:--TACHYON--:.:. Forth V27150720.2030
     Cold start - no user code - setting defaults
    ----------------------------------------------------------------
     CREATE EXPLORER         ( if not needed then enter a \ before loading this modu
    le, otherwise this sets the default )  ok
    CREATE SMALL             \   ok
    TACHYON   Propeller .:.:--TACHYON--:.:. Forth V27150720.2030
     ok
    0000  ok
    0001  ok.fth )
    0002  okTEND.fth
    0003  ok
    0004  ok
    0005  ok
    0006  okCLR              \
    0007  ok
    0008  ok
    0009  ok
    0010
    0011
    0012  ok
    0013  ok
    0014  ok
    0015  ok
    0016  ok
    0017  ok
    0018  ok
    0019  ok
    0020  ok
    0021  ok
    0022  ok
    0023
    0024
    0025  ok
    0026  ok
    0027  ok
    0028
    0029
    0030  ok
    0031  ok
    0032
    0033
    0034  ok
    0035  ok
    0036  ok
    0037  ok
    0038  ok
    0039  ok
    0040  ok
    0041  ok
    0042  ok
    0043
    0044
    0045  ok
    0046  ok
    0047  ok
    0048  ok
    0049  ok
    0050  ok
    0051  ok
    0052  ok
    0053  ok
    0054
    0055
    0056  ok
    0057  ok
    0058
    0059
    0060
    0061
    0062  ok
    0063  ok
    0064  ok
    0065
    0066
    0067  ok
    0068  ok
    0069  ok
    0070  ok
    0071  ok
    0072  ok
    0073  ok
    0074
    0075
    0076
    0077
    0078  ok
    0079  ok
    0080  ok
    0081  ok
    0082  ok
    0298      INCLUDING #9 PIN_I/O_OPERATIONS
    0468      INCLUDING #8 CHARACTER_OUTPUT
    0534      INCLUDING #7 LOCAL_VARIABLES
    0539      INCLUDING #6 FIXED_POSITION_VARIABLES
    0644      INCLUDING #5 MATHS_FUNCTIONS
    0726      INCLUDING #12 NUMBER_PRINT_FORMATING
    0850      INCLUDING #19 ANSI_TERMINAL
    0995      INCLUDING #20 STRINGS
    1070      INCLUDING #21 SAN_FILTER
    1075      INCLUDING #22 MCP3208_8_channel_ADC
    1337      INCLUDING #13  PBASIC_STYLE_SERIAL_I/O
    1375      INCLUDING #14   EXAMINE_SPECIAL_PURPOSE_REGISTERS
    1381      INCLUDING #15   Memory Map Reporting
    1599      INCLUDING #23   COUNTERS
    1887      INCLUDING #10 PWM
    1902      INCLUDING #11 HEX FILE LOAD & DUMP
    1905      INCLUDING #18 COMPILER REPORTING
    2022                     error in lshw at LSIO CR lsregs CR lsi2c  *error*
    ----------------------------------------------------------------
    

    The same TACHYON, the same EXTEND, the same HyperTerminal and Propeller Tool and the QuickStart works fine with no problem.
    Can someone helps me?
  • BTW... if I exclude an EXPLORER by \ before EXTEND I don't get an error. What is an explorer in any case?
  • If it works on the QuickStart then there shouldn't be any difference then but what is your line delay set to? You need 8ms or more per LINE but just in case set it to 15. There is no need to go much higher though. The error is saying it didn't find LSIO which is actually lsio before it converted it to uppercase and tried again.
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2015-08-27 16:22
    Not sure where you got that version of EXTEND.fth but I've just double checked the latest and also updated it in dropbox, version 150828-0215.

    The "CREATE EXPLORER" allows the compilation to detect that this word exists and add in some extras for exploring hardware etc. Those sections that are only included in the Explorer configuration are bounded by "IFDEF EXPLORER" and a closing brace but this configuration should be the default normally.

    Remember that there are the binaries which include all this and are a simple one-click and done operation.
  • DamirXDamirX Posts: 12
    edited 2015-08-27 16:23
    If it works on the QuickStart then there shouldn't be any difference then but what is your line delay set to? You need 8ms or more per LINE but just in case set it to 15
    I've just tried to repeat load EEPROM with TACHYON an EXTEND it with 15 ms line delay and got the same
    1905      INCLUDING #18 COMPILER REPORTING
    2022                     error in lshw at LSIO CR lsregs CR lsi2c  *error*
    ----------------------------------------------------------------
    
    And thank You for Your reply.
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2015-08-27 16:44
    This is the version of EXTEND that you should find in Dropbox but just try this one here to make sure. Make sure you reset the Prop (break or ^C) as if you are loading this in fresh.

    Darn forum won't allow me to attach that so I will try again with a zip.
    /discussion/download/115077/EXTEND.FTH.zip
  • Not sure where you got that version of EXTEND.fth but I've just double checked the latest and also updated it in dropbox, version 150828-0215.

    The "CREATE EXPLORER" allows the compilation to detect that this word exists and add in some extras for exploring hardware etc. Those sections that are only included in the Explorer configuration are bounded by "IFDEF EXPLORER" and a closing brace but this configuration should be the default normally.

    Remember that there are the binaries which include all this and are a simple one-click and done operation.

    Thank You Peter!
    This version is different from prevision, which I'm not sure where I got,
    C:\Documents and Settings\user\My Documents>dir EXTEND.FTH
     Volume in drive C has no label.
     Volume Serial Number is 186C-683E
    
     Directory of C:\Documents and Settings\user\My Documents
    
    08/26/2015  08:34 PM           109,995 EXTEND.FTH
                   1 File(s)        109,995 bytes
                   0 Dir(s)   3,228,446,720 bytes free
    
    C:\Documents and Settings\user\My Documents>dir EXTEND.FTH
     Volume in drive C has no label.
     Volume Serial Number is 186C-683E
    
     Directory of C:\Documents and Settings\user\My Documents
    
    08/27/2015  08:28 PM           111,526 EXTEND.FTH
                   1 File(s)        111,526 bytes
                   0 Dir(s)   3,218,436,096 bytes free
    
    Now, it's OK!
    2577      INCLUDING #18 COMPILER REPORTING
    2767  ok
    2768  ok
    2769  ok---
    2770
    
    46:65:85  End of source code, 2771 lines processed and 0000 errors found
    Load time = 0.000us
    MODULES LOADED:
    1A80: EXTEND.fth          Primary extensions to TACHYON kernel - 150828-0215
    
    VER:    Propeller .:.:--TACHYON--:.:. Forth V27150720.2030
    FREQ:   80MHZ (PLLEN OSCEN XTAL1  PLL16X)
    NAMES:  $55B4...7178 for 7,108 bytes (+4,601)
    CODE:   $0924...3E55 for 13,617 bytes (+9,173)
    CALLS:  341 vectors free
    RAM:    5,983 bytes free
    BUILD:  FIRMWARE BUILD DATE 654545:466585
    BOOTS:  0
    BOOT:   EXTEND.boot
    POLL:
     ok
    ?BACKUP  ok
    

    Now, I'm going to remember FORTH!
  • Good stuff. Thanks.
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2015-08-28 05:29
    Talking about full-duplex serial on another thread got me to thinking about ways to implement multiple serial ports.

    I do believe I can write a 32-channel full-duplex object that runs in a single cog reliably at 115,200 baud. Whaaaa!? "Shirley" you're not serious you might say but seriously don't call me Shirley.

    There's a technique I came up with that involves synchronous oversampling bursts feeding a majority vote with the same burst period as the baud rate that will allow me to capture serial data on up to 32 pins specified by masks. At the same time serial data can be transmitted on up to 32 pins specified with the transmit masks. I might even be able to fit the buffering in there too especially at lower baud rates anyway. There will be no jitter in the transmit and receive as samples and updates are synchronously clocked 32 I/O at a time via waitcnt.

    Receiving data:
    * Burst sample by reading in minimum of n longs of I/O
    * Majority vote and using receive masks write filtered samples to the 32-bit "shift register" comprised of 11 longs in the cog.
    note: 8 bits for data, 1 start, 1 stop, and 1 stop before start (see transmit)
    * If a zero bit is in the end long then accept the data stored in that bit position over 8 longs as "data" providing the most recent sample is high (stop bit).
    - reset that channel to 1's if data is accepted
    - buffer data

    Transmit data:
    note: a channel is idle if that bit position over first 10 longs is empty (1's)
    * Next data is added to the "shift register" distributed in that channel's bit position over 10 longs but from the penultimate shift register long
    note: this leaves room for a previous stop bit to be transmitted before another character

    Burst sampling also detects edges as middle sample in the burst involves two quick samples to help overcome metastability affecting the majority voting. (perhaps)

    Burst sampling (only showing 3 samples for simplicity):
    IDLE  START     BIT 0     BIT1      BIT2      BIT3      BIT4      BIT5      BIT6      BIT7      STOP
    DATA:  11111100000000001111111111000000000011111111110000000000111111111100000000001111111111000000000011111111110000000000
    BURST: 00011100000001110000000111000000011100000001110000000111000000011100000001110000000111000000011100000001110000000111
    VOTE;  .....1.........0.........1.........0.........1.........0.........1.........0.........1.........0.........1.........0
    
    DATA:  11111100000000001111111111000000000011111111110000000000111111111100000000001111111111000000000011111111110000000000
    BURST: 000011100000001110000000111000000011100000001110000000111000000011100000001110000000111000000011100000001110000000111
    VOTE;  ......1.........0.........1.........0.........1.........0.........1.........0.........1.........0.........1.........0
    
    DATA:  11111100000000001111111111000000000011111111110000000000111111111100000000001111111111000000000011111111110000000000
    BURST: 0000011100000001110000000111000000011100000001110000000111000000011100000001110000000111000000011100000001110000000111
    VOTE;  .......0.........1.........0.........1.........0.........1.........0.........1.........0.........1.........0.........
    
    DATA:  11111100000000001111111111000000000011111111110000000000111111111100000000001111111111000000000011111111110000000000
    BURST: 00000011100000001110000000111000000011100000001110000000111000000011100000001110000000111000000011100000001110000000111
    VOTE;  ........0.........1.........0.........1.........0.........1.........0.........1.........0.........1.........0.........
    
    DATA:  11111100000000001111111111000000000011111111110000000000111111111100000000001111111111000000000011111111110000000000
    BURST: 000000011100000001110000000111000000011100000001110000000111000000011100000001110000000111000000011100000001110000000111
    VOTE;  .........0.........1.........0.........1.........0.........1.........0.........1.........0.........1.........0.........
    
    <etc>
    
    	IDLE  START     BIT 0     BIT1      BIT2      BIT3      BIT4      BIT5      BIT6      BIT7      STOP
    DATA:  11111100000000001111111111000000000011111111110000000000111111111100000000001111111111000000000011111111110000000000
    BURST: XXXXXXX000000011100000001110000000111000000011100000001110000000111000000011100000001110000000111000000011100000001110000000111
    VOTE;  ................0.........1.........0.........1.........0.........1.........0.........1.........0.........1.........0.........
    	IDLE  START     BIT 0     BIT1      BIT2      BIT3      BIT4      BIT5      BIT6      BIT7      STOP 
    DATA:  11111100000000001111111111000000000011111111110000000000111111111100000000001111111111000000000011111111110000000000
    BURST: XXXXXXXX000000011100000001110000000111000000011100000001110000000111000000011100000001110000000111000000011100000001110000000111
    VOTE;  .................1.........0.........1.........0.........1.........0.........1.........0.........1.........0.........
    

    It's all in my head at the moment and if it isn't fundamentally flawed it will end up as a Tachyon object which can easily be reworked to integrate with Spin or C etc but certainly a lot easier for me to develop and test in Tachyon. Got to get to work on the code now, may do it in Tachyon to test the concept at 9600 baud then implement the PASM code. Certainly there is no problem with transmitting though, at the very least this will be implemented.

    Testing will involve a few Props all sending data at random intervals and checking the response. So this post is also to help me think it through and get some feedback too, like "you're mad!".
  • MJBMJB Posts: 1,235
    like "you're mad!".

    yes sure ;-) - that's how many a great invention starts

    I sent some feedback via skype
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2015-08-29 16:57
    Regarding the "FDS32" object which allows a mix of up to 32 serial transmit or receive channels:

    Just got around to trying some code in the last couple of hours and started off with the "easy" part of being able to transmit on up to 32 channels. Turns out that even in Forth I have no problem transmitting 32 channels at 9600 baud. Obviously I can't test all 32 channels but definitely 16 of them I am checking but the actual number of channels makes no difference due to the method used, much like the PWM32 object in a way. The tricky part I found was that I when I write a character into a channel that it needs to write to all 9 longs of the FIFO in between transmit shift operations. The transmit shift operation is done at the baud rate and shifts the longs in the FIFO so all 32 channels get shifted in one simple operation.

    Next comes the tough one, the receiver section but so far, so good..... :)

    btw, the timing is rock steady and no jitter no matter how many channels you have.
  • Peter,

    I think in the past you've said you were able to reliably get 2-3Mb serial.
    If so, in this case it sounds like its not so much throughput being the problem, but the very large number of channels which will be tricky to have cycles for.
  • Peter, these amazing results seem to continue with no end in sight. But once again, I'm confused.

    It's nearly impossible to create code paths that are fixed-length in the time domain with the Propeller's architecture. If one does a single reference to memory, latency is variable and so edge stability becomes variable as well unless one uses waitcnt to stabilize things. However, that's not an option for your driver because you cannot stop processing if you're hunting for start bits on receive data.

    So, I see only one of two possible situations:

    Either there is edge instability, perhaps as little as 2 but probably more likely 7 clocks per edge, which at 80Mhz and 9600 baud is one part in 4200 or so; not very much but certainly easily seen with a scope and that lower bound of instability will quickly increase with more memory references, higher baud rates and conditional code paths. Unless the producer thread is responsible for all the work associated with generating the bit stream, you can't avoid variable code paths and so you can't avoid variable edge spacing.

    Or you're using waitcnt and have completely deferred on the challenges of the receiver and once those are comprehended, your edge stability is going the way of the dodo.

    Am I missing something? If so ... what?
  • Mike GreenMike Green Posts: 23,101
    edited 2015-09-01 17:34
    There are two ways to sample for start bits. You can look for the incoming edge with WAITPxx and clock everything from that (assuming it's not too noisy) or you can sample the data line at some multiple of the Baud clock either using fixed-length code paths for timing or WAITCNT. Both techniques have been used for UART objects. For multiple channels, the first technique gets complicated quickly as you have to identify the channel(s) that caused the WAITPxx to continue and you can get timing errors as you miss another start bit while setting up for the one(s) you know about. For the 2nd technique, your timing can be off by up to the sampling multiple and you obviously have to take care of multiple channels by the time the next sample is to be done.

    I'm sure either technique can be used for multiple channels. What I would like to know is the graph / chart showing the maximum Baud vs. maximum # of channels for PASM, Forth given a variety of potential timing errors. That will hopefully come with implementations, documentation, and experimentation.

    In the end, that information is what will determine the usefulness of the technique Peter is proposing. It may turn out to be very useful for multiple serial channels or may be limited to only certain circumstances. It's not very helpful to just come up with objections in principle to what Peter has described so far. I certainly would not base a commercial or even a hobby project on what I've read so far, particularly since there are good solutions for up to 4 channels at fairly high Bauds (Phil's modifications for the 4-channel single cog object). Still, Peter has done good, thoughtful work before and I'm happy to follow the evolving story. Projects needing more than 4 or 8 serial channels are very rare and probably fairly complex. I'm sure anyone considering what Peter is proposing would do their own testing.
  • MJBMJB Posts: 1,235
    koehler wrote: »
    Peter,

    I think in the past you've said you were able to reliably get 2-3Mb serial.
    If so, in this case it sounds like its not so much throughput being the problem, but the very large number of channels which will be tricky to have cycles for.
    that was/is a completely different animal.
    The solution there is based on a dedicated receive COG (the standard Tachyon terminal RX)
    and the send side being handled from the application TACHYON-FORTH COG using a PASM routine for direct sending the bits.

    the MAGIC32 project is something very different ...

    no matter what the outcome ...
    just while going there Peter produces great usable 'side products' like SPLAT

  • MJBMJB Posts: 1,235
    welcome back TACHYON - and test if posting works again
  • Heater.Heater. Posts: 21,230
    Yay, It's back!
  • I need a bit of help with the following construct:
    #P0 4 MASKS CONSTANT DigVal
    #P4 2 MASKS CONSTANT DigSel

    There is a 4-bit digit value and a 2-bit digit position select. What is the proper syntax for sending a value of '7' to digit position '2', for example?

    Been traveling a bit and just got back to this project!

    Thanks!

  • K6MLE wrote: »
    I need a bit of help with the following construct:
    #P0 4 MASKS CONSTANT DigVal
    #P4 2 MASKS CONSTANT DigSel

    There is a 4-bit digit value and a 2-bit digit position select. What is the proper syntax for sending a value of '7' to digit position '2', for example?
    Not quite sure what you mean but if I take a guess you are saying that the 7 gets written to P0..3 while P4..5 hold the 2 for example. As you should know there is no "syntax" as such although we try to follow conventions so in this case I would handle it much the same way we would when we store to memory, we have data, in this case 7, and an address, in this case 2. So applying that:
    pub DIGIT! ( val sel -- )  4 << + $3F OUTCLR OUTSET ;
    
    So we combine the address and the data together and before we can write those bits without disrupting any other pins we just clear that group and then we can SET that bit range P0..P5. That would seem to be the cleanest simplest way to handle that and the code only consumes 8 bytes and takes 8.8us to execute.
  • Thank you Peter. I'm glad I asked, since I was headed down another path, which would have been a dead-end! This works just fine and I have a better understanding of what the masking was doing.
  • I am presently working with a MAX7219-based board I got from ebay, containing 8 7-segment LEDs on it. I think the mode to communicate with it is perhaps SPI, but I need to dig a bit to confirm. It has 5 pins on the board: Vcc, Gnd, DIN, CS, & CLK. That doesn't look like I2C, to me!

    Has anyone fired one of these up with Tachyon yet?
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2015-09-04 05:00
    K6MLE wrote: »
    I am presently working with a MAX7219-based board I got from ebay, containing 8 7-segment LEDs on it. I think the mode to communicate with it is perhaps SPI, but I need to dig a bit to confirm. It has 5 pins on the board: Vcc, Gnd, DIN, CS, & CLK. That doesn't look like I2C, to me!

    Has anyone fired one of these up with Tachyon yet?

    I know MJB has and he also has code for it but I like to keep it simple and treat it just like any other output device so I've taken a few minutes to peruse the datasheet and create a simple driver. I'm assuming for the moment that you are only interested in digits, not alphas and that we are printing numbers right justified as we do for digits.
    Have a look at this code then and I will see about adding the extra functions needed to initialize etc. You should be able to define your pins and then when you use it it will be like this:
    MAX7219 CLKFREQ PRINT CON

    So MAX7219 switches the output to the MAX7219 driver and when Tachyon prints the number it will appear on the display and if we didn't have CON in there then Tachyon would continue to try to talk to you via this display. Of course we could put alphas on there but I wouldn't bother. The driver is updating the display for every character it receives but I may change that so that it waits for a CR perhaps? So in that case after updating the display it can clear its buffer ready for a new number which will update the display on the next CR. Does that sound reasonable?


  • MJBMJB Posts: 1,235
    #P0 4 MASKS CONSTANT DigVal
    start from pin 0 for 4 bits wide create the mask = $F and assign it the constant name DigVal ...
    What is the proper syntax for sending a value of '7' to digit position '2', for example?
    what do you mean with this?
  • MJBMJB Posts: 1,235
    K6MLE wrote: »
    I am presently working with a MAX7219-based board I got from ebay, containing 8 7-segment LEDs on it. I think the mode to communicate with it is perhaps SPI, but I need to dig a bit to confirm. It has 5 pins on the board: Vcc, Gnd, DIN, CS, & CLK. That doesn't look like I2C, to me!

    Has anyone fired one of these up with Tachyon yet?

    here is my code
    similar, but a bit more verbose than Peter's version
  • My thanks to Peter and Markus for the progress I've made! It is now just a matter of getting the main routine to run in the background (on its own cog) and be able to have the whole 'banana' be able to properly recover from a power cycle.

    At this point, the main routine and startup is thus:

    : WxExt ( -- ) \ Main routine to display wind speed & direction on wall display.
    !SP mystk SP!
    BEGIN
    dir-i ConvField W-DIR \ Light up direction LED on compass rose.
    GetSpeed GetDir 7219OUT \ Put speed & direction values to 7219 module.
    AGAIN ;

    ' WxExt TASK? RUN \ Run main routine in its own cog.

    I can run the code between the BEGIN and AGAIN manually and all functions as expected. When I use the ' WxExt TASK? RUN line, the Propeller appears to lock up. The stack space is #10 longs. Am I missing something else?

    Thanks!
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2015-09-07 02:51
    K6MLE wrote: »
    My thanks to Peter and Markus for the progress I've made! It is now just a matter of getting the main routine to run in the background (on its own cog) and be able to have the whole 'banana' be able to properly recover from a power cycle.

    At this point, the main routine and startup is thus:

    : WxExt ( -- ) \ Main routine to display wind speed & direction on wall display.
    !SP mystk SP!
    BEGIN
    dir-i ConvField W-DIR \ Light up direction LED on compass rose.
    GetSpeed GetDir 7219OUT \ Put speed & direction values to 7219 module.
    AGAIN ;

    ' WxExt TASK? RUN \ Run main routine in its own cog.

    I can run the code between the BEGIN and AGAIN manually and all functions as expected. When I use the ' WxExt TASK? RUN line, the Propeller appears to lock up. The stack space is #10 longs. Am I missing something else?

    Thanks!

    Truly hard to say as we have no idea about the functions of any of your definitions, what resources they may use directly or indirectly etc. One of the things to keep in mind if you are running another Forth cog is whether it might need its own task registers. These are the registers and buffers that are used for streaming I/O for printing numbers and strings, for accepting words etc. If in doubt just create some space for these registers, say 128 bytes like this:
    128 BYTES myregs

    Then make sure that your task uses these registers instead of the main console's copy. So copy it first then reassign like this in your WxExt:
    $24 myregs $80 CMOVE
    myregs 7 COGREG!
    So $24 is the default base address of the console's registers which we copy and then 7 COGREG! sets the base address for your task's registers.

    Anyway, you can try that otherwise you will probably need to post all your code (warts and all) so we can make a better recommendation.

    I'm guessing you will be using AUTORUN as well so the ' WxExt TASK? RUN should run inside a startup definition and preferably I like to set the cog number directly such as 6 or 5 rather than using TASK? so that in case startup is run again without resetting, that it doesn't try to use another cog in addition to the one that is already running.

    If you had a look at the MAX7219 code I provided you would have seen an example of running it in its own cog along with its own registers. BTW, that code appears to be okay as I testing it out in my SPLAT logic analyzer!

  • How can I remove a running task seen in the list from .TASKS, other than rebooting the propeller?
  • It is highly unlikely that you need to do this in a working application as if you needed to free up the cog and even if you did you would code it so that it returned to the IDLE loop when instructed. Once a cog is running it does what it's instructed to do and the only options you ever have are coginit or reboot.

    Obviously you would choose a reboot surely but just on the off chance that you made a mistake while testing and it's very important that you don't reboot you could do a coginit but you need a copy of the Tachyon image that gets loaded at boot. However this is no longer available in hub RAM since it is reused for buffers as are any cog images in Tachyon so you need to either get it from EEPROM or from the main cog, copy it to BUFFERS and coginit from there.

    I've never tried it and I doubt very much you should need to but is that what you "need"?
  • Thanks Peter. I was only thinking about using such a 'feature' while doing development, not unlike the Linux "kill" command. I take your point that it's probably better to just reboot, since there hasn't been an issue where I don't want to do so.

    Just added my 2nd Prop board to the 'junk' heap ... it just stopped being recognized by the Prop Tool, even though the OS sees it as a valid device! That being said, I'm in the process of finalizing the hardware for this project and committing it to a Propeller Proto Board.
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2015-09-07 23:28
    K6MLE wrote: »
    Thanks Peter. I was only thinking about using such a 'feature' while doing development, not unlike the Linux "kill" command. I take your point that it's probably better to just reboot, since there hasn't been an issue where I don't want to do so.

    Just added my 2nd Prop board to the 'junk' heap ... it just stopped being recognized by the Prop Tool, even though the OS sees it as a valid device! That being said, I'm in the process of finalizing the hardware for this project and committing it to a Propeller Proto Board.

    Do you mean the OS sees it as a valid device because it sees the FT232 part? Well that is all that the OS could see with or without a Prop but if that is the second Prop you have fried then it may pay to look at your ground and power "feeds" and observe a few precautions which I will try to summarize succinctly:

    #1 Ground for the load should come from directly from the power supply, even if it's a longer path, and not via the Prop circuitry.
    #2 Power for the load, unless light, should have its own regulation and not tap off the Prop's regulators
    #3 Protect any I/O pins even those that stray off the board over lengths of cable by using appropriate series resistors.

    Also be very careful with wiring layout if using any kind of protoboard, even the soldered variety, as they are no real substitute for a properly designed PCB for handling noisy signals and loads.

    BTW, I guess you should know all this if you are a hacking HAM.

Sign In or Register to comment.