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?
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.
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.
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*
----------------------------------------------------------------
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.
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
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):
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!".
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.
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.
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.
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
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!
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?
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?
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?
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!
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.
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.
Comments
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:
The same TACHYON, the same EXTEND, the same HyperTerminal and Propeller Tool and the QuickStart works fine with no problem.
Can someone helps me?
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.
Darn forum won't allow me to attach that so I will try again with a zip.
/discussion/download/115077/EXTEND.FTH.zip
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 freeNow, it's OK!Now, I'm going to remember FORTH!
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):
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!".
yes sure ;-) - that's how many a great invention starts
I sent some feedback via skype
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.
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.
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?
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.
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
#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!
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?
what do you mean with this?
here is my code
similar, but a bit more verbose than Peter's version
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!
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"?
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.