Multiple Props on a board
Harley
Posts: 997
I have an application that needs more I/Os that a Propeller has.
Was contemplating using a PIC and a Prop, but 'thinking in the shower'
suggested using two Props could work.
One would only need one 3.3v regulator, but wouldn't it require a crystal and an EEPROM for each Prop, or not?
Couldn't the XO output of the one with a crystal drive the 2nd Prop XI? They would face each other to keep those lines short.
Could one use the I2C object so the Props could communicate with each other? If so, how would each be addressed so that they could do so during normal operation (not initialization)?
I would also need for one Prop to serial I/O at 19.2 kb or 38.4 kb to another board (already designed and working at 38.4 kb). I suppose the existing Serial I/O object would suffice.
Any sort of guidance here would be appreciated. This is quickly getting over my head, it seems.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko
h.a.s. designn
Was contemplating using a PIC and a Prop, but 'thinking in the shower'
suggested using two Props could work.One would only need one 3.3v regulator, but wouldn't it require a crystal and an EEPROM for each Prop, or not?
Couldn't the XO output of the one with a crystal drive the 2nd Prop XI? They would face each other to keep those lines short.
Could one use the I2C object so the Props could communicate with each other? If so, how would each be addressed so that they could do so during normal operation (not initialization)?
I would also need for one Prop to serial I/O at 19.2 kb or 38.4 kb to another board (already designed and working at 38.4 kb). I suppose the existing Serial I/O object would suffice.
Any sort of guidance here would be appreciated. This is quickly getting over my head, it seems.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko
h.a.s. designn
Comments
It should be possible to use one Propeller to program the other Propeller; I think someone from Parallax posted on this forum a Spin object that will do it.
I wonder if the two Propellers could share the same I2C connection to the EEPROM. Then you could load the same program onto two Propellers, and the program could branch depending on the high or low state of an input pin hardwired to low on one chip and high on the other.
In my suitcase computer project, I'm using 3 Intel 8255's to get 72 I/O lines, but I own another Propeller chip too. I've been vassilating between keeping the 8255's or replacing 1 or 2 of them with my second Propeller. In favor of using a second, slave Propeller is that it will require fewer I/O lines on the master Propeller (I could do it with 2 line serial communication instead of the 16 I'm currently using for parallel I/O), and of course it's always nice to have more processing power. The drawback is that if I did that I would have to come up with a message passing protocol so that the two propellers could communicate, and I would have to program both. Since I have so many pins tied up in hardware on my master Propeller, it might be worthwhile to insert the 2nd Propeller into the chain as an "8255 controller", thus freeing 16 pins on the first Propeller and adding processing power and 16 more unused pins with the 2nd Propeller. I'm also interfacing the 3.3 volt Propeller to the 5 volt 68000 bus; with the 8255's I only need 8 current limiting resistors on the data bus, but if I used a second Propeller I'd need many more resistors, one for each line I connected.
In my estimation the biggest issue is going to be the complexity of getting two Propellers to communicate the way one wants them to (protocol issues). My first attempt at this suitcase computer project had me trying to use a Basic Stamp 2 as an in-circuit debugger connected to a 68000 and RAM, with the Basic Stamp acting as a slave unit, getting its commands over the serial line from a debug console running on a PC. It turned out to be pretty complex because I had to not only come up with a format for sending bits between the PC and the Stamp, but also handle all the special cases like "What if the Basic Stamp is busy when the PC sends a message?" "What if the 'frame' of the messages gets mixed up so that the tail end of an old message and the front of a new message get mixed together?"
I'd been reading about SmallTalk so I thought of it as a message passing problem and ended up coming up with a format that specifies 1 byte as the message "selector", which is a magic number specifying what type of operation is requested; i.e. the method to call, followed by two 16-bit words that hold data arguments. (This is also similar to the way Windows OS messages work.) This doesn't give you a whole lot of room for arguments data but seemed to be the best compromise between flexibility and efficiency, and the Basic Stamp doesn't have a lot of RAM so I couldn't get too crazy with the protocol.
Another funny thing is that I had to make the protocol use ASCII representations of hexidecimal numbers - I couldn't use binary mode communications. This is because with binary, any possible byte is valid, so there is no way to reserve a value to represent the start and stop of a message unless I wanted to use a "crippled" binary mode that reserved some values. Instead, if I sent the numbers as hexadecimal in ASCII, I could use other ASCII characters to mean special things. This way I could prevent the problem of the "frame of reference" getting off by some number of bytes, because it would resync to the start marker with each new message. I used $ to mark the beginning of a message, and ! to mark the beginning of a reply to a message. I required spaces between numbers so a typical communication looked like: $02 0010 2000. This is less efficient than a binary communication mode, but in addition to being more reliable, has the added advantage that you can type commands directly in the Debug Terminal by hand and they will work. (Both human readable and machine readable - kind of like XML.)
Anyhow I didn't want to get the discussion sidetracked into serial protocols but I think you can see that when you have two parties that need to communicate, many issues can crop up. There are probably plenty of other ways to do it that don't need to be nearly this complex; I was trying to come up with a standard format for message passing for serial communications in my projects. I think "$selector arg1 arg2" using ASCII is a good way to do it. (- feel free to steal this idea!) But if you don't have more than one function to do, things can be easier. I ended up starting over using a Propeller and instead of downloading 68000 programs message-by-message over the serial line, I'm just going to include the whole binary program into the Spin file and let the Propeller load the program into the 68000's RAM by itself.
1. Has anyone worked with two or more Propellers yet?_____
I'm wondering how the connections should be for running them at the same frequency. Has anyone seen a schematic for two or more Props?_____
2. What would the ideal communications be between two Props?_____
One Prop doesn't have many spare I/O remaining. Right now, it seems serial i/o, like RS232 w/o the voltage translators, might be simplest to work with. An object already exists for that. Don't know what the highest baud rate could be. Need to study that object.
Dennis, while editing this message I realized yours had arrived. Thanks for the input. Need to reread that tomorrow to understand it all. Bed time for me now.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko
h.a.s. designn
My wishlist includes:
- minimum resources at the slave end (one cog, one pin)
- master has VGA and keyboard,·slave can "print" to screen and "read" from or "wait" on keyboard
- master can write/read slave memory, read/set slave pins etc (debug functions)
- high·speed (MBit, want to do things with video, so assembly coded cogs)
- master -slave protocol, master initiates all communication, multi-slave·adressing
I also came to the conclusion that sending fixed length commands with a scheme·CMD -> PAR -> ACK<-· as Dennis suggested is flexible·and simply implemented. The return path is more complicated·however GET-> data<- ack->, I have not figured out an optimum method·for·the synchronization of slave transmiting data to the master. I am considering two options now.
Option 1: Assuming that the requested data is already in the slave cog, this transfer can be implemented with deterministic timing. However, the slave needs prior knowledge what info will be requested, so a previous command is needed that adresses the requested data. This is feasible but complicates things. The sequence would be CMD-> address-> ack<- ..... get-> data<- ack->
Option 2: the slave fetches·the data after reception of the "GET" command (from·hub memory, so not time deterministic) and initiates the communication to the master. The master however cannot go into·WAITPEQ, in case the slave does not respond. So a pre warning that the slave is going to transmit is necessary (two start bits?). This is·feasible but complex.·Alternative is to·have·a watchdog·timer,·by using·a counter that pulses·a second pin,·to wake up the master cog in case the slave does not respond,·and stop the counter·when the slave responds in time.
Nico Hattink
a pin (or pins) to synthesize a desired frequency (5MHz ... or whatever). This frequency would then in turn supply the "clock" pulse to additional Propellers connected to the master. As far as the master
is concerned, this would not take an additional COG since you can set and forget the CTRa or CTRb to run on it's own, unless you were using the CTRa or CTRb for something else. Any video would be
running in a separate COG by itself anyway and would have it's own CTRa and CTRb to deal with.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe
IC Layout Engineer
Parallax, Inc.
One 5 Mhz crystal for one Prop, let it generate the 5 MHz for the second Prop. Sure takes care of the 'clocking problem' and allows for more separation on a pcb than could if X0 of one drove XI of the second. And they are running at the same frequency.
The Props don't have the same tasks, so one EEPROM probably would not possible. Seems it absolutely would require one EEPROM for each Prop, right?
Wouldn't have any use for video for the end design. However, possibly this would be useful for debugging initially; and maybe for future trouble-shooting. Maybe could use a keyboard port
I'm thinking of using serial comm between the two Props. The 'master' presently serially communicates with another board. There are some values that must be passed between the two Props. I don't suppose there would be any problem with the master having two serial objects to deal with?
There is a 3rd pcb which is all 5v presently, so loads of resistors will be needed at the 3.3v/5v i/f's. Hopefully, some near-30 resistors don't present too much a 'pull-up' current for the 3.3v regulator.
Looks like I'd need two programming i/f's, one for each Prop. Guess that's not too bad. Or one and a switch. (I see the 'snowball' beginning to roll downhill, my way again.)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko
h.a.s. designn
This will probably take two 'headers' to interface to a programmer module, right?____
I would like to use A30, A31 for serial comm with another board, after programming is done. Would a 330 ohm resistor in series with the other board be sufficient isolation?____ The other board provides 5v/ground signalling; no RS232 voltage translator IC is involved as the two boards will be only inches from each other.
Using either PropPlug or PropClip, is there any keying to prevents wrong connections?____ Is the 'arrows' for Tx and Rx referenced to a PC or the Prop i/f?____ I need to know this for pcb layout pinouts, and for clearance to other components; this is assuming pin perpendicular to the pcb.
For Parallax: on a related, though separate subject, will the Prop Protoboard schematic be available far in advance of the boards?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko
h.a.s. designn
2) As far as I know, neither the PropPlug nor the PropClip provide keying other than the appearance of the device (with the logo on top) and the markings. I believe the arrows show data direction relative to the PropPlug/Clip (USB) so Tx is from USB to connector and Rx is from connector to USB.
It probably would take the same amount of board real estate to put in a vertical 4-pin header for each Prop for programming as it would to put in jumpers or a switch. You could use the header for the serial TTL comm connection to the other board. This would make it impossible to affect the other board while programming.
Thanks for the above info. Helps much to have some reference to work with.
1. I will increase the series Rs. Running at 19.2 kb, so don't know how large a value to go to before affecting speed. Boards are cabled with ribbon-type; don't know how low C they are.
2. Looking at Parallax web site pictures, couldn't see anything that would key the device. Maybe if a right-angle header is used, and it is not right at the edge, probably could only put it on one way. Means one sure needs good info on mechanical of the module. I couldn't find anything on the web site for the PropPlug dimensions. Are you aware of any documentation for the PropPlug?___
Since the above mentioned two boards are ribbon-cable connected, the suggested scheme wouldn't work (using the header to connect the serial TTL comm). It is coming from a 16F871 PIC so nothing would affect it during programming. The higher value Rs in series will guarentee that the PIC output doesn't affect the download to the Prop.
Now, hopefully the Propeller can hack the timing requirements. Used to be an all TTL design of about 55 ICs. Introduced a PIC and reduced that to about 28. PIC wasn't fast enough to capture some signalling. Appears the Prop can.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko
h.a.s. designn
I'm attempting to get FullDuplexSerial going; but don't know the variable names to connect with it for Rx and Tx bytes. I've read a number of listings and cannot for the life of me get the 'hooks' right.
So, thought maybe it would be easy to check the state of a line. Prior to the code below, FullDuplexSerial has been started. What I'm looking for is output 16 is driving a LED, however whether I/O 31 is high or low, the LED doesn't change states. This newbie to Propeller is missing something.
dira[noparse][[/noparse]31]~ dira[noparse][[/noparse]16]~~ repeat Temp := INA[noparse][[/noparse]31] if Temp[noparse][[/noparse]31] := 1 outa[noparse][[/noparse]16]~~ else outa[noparse][[/noparse]16]~▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko
h.a.s. designn
James L
Just more code
Actually it wouldn't work because of the "Temp := 1" in the if statement. That at least needs to be changed to "Temp == 1".
Mike
Made the change and it works right.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko
h.a.s. designn
Using suggested series resistor between the Prop and 5v logic, that pullup and series resistor sets the threshold pretty high.
Trying to get FullDuplexSerial working I'm wondering is the reference for 'rxpin' and 'txpin' for pins 31 and 30 respectively?____ As in INPUT to and OUTPUT from the Prop?
In the PUB is the statement
which value of 'mode' would be used for the PropSTICK? Appears 'mode' is a 4-bit value? I note that the MonitorDemo.spin doesn't even use 'mode'!!!
And one other question, does one use 'rxbyte' and 'txbyte' as placeholder to communicate with FullDuplexSerial? I've not been able to determine from any Spin code yet just what is involved. Is there a good reference for this?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko
h.a.s. designn
2) I believe rxpin is the pin for data coming into the Propeller while txpin is the pin for data going out of the Propeller.· The names are placeholders as is mode and baudrate.· These values are stored locally in the FullDuplexSerial object by the start routine and referenced by the other routines including the assembly routine running in its own cog.
3) Look in the comments for the start method for the description of the mode bits.· Two of them control whether the receive and transmit pins are inverted.· One provides for the receiver optionally throwing away a character after transmitting one (in case there's a hardware echo connection between transmit and receive).· I forget what the 4th one is for.
Think I've found the problem. I've drawn up the schematic for this project. But am using a PropSTICK for my first Prop. So far OK.
But looking AGAIN at the Demo and PropSTICK schematics, note that a FT232 or MAX3232 output is driving pin 31. (See modulation at the high level on a 'scope when driving pin 31.) OK for single use on this pin, but even though the Prop is free to use pins 30 and 31 after initialization, what ever drives a signal on pin 31 is also driving into the output of the FT232 or MAX3232. Aarrgghhhhhh! No wonder it works if I do a short to ground but not when driving through a 'decent' value (to protect the Prop). Looks like I will HAVE to use that new Prop protoboard (not yet on the shelves). Or 'cut' the PropSTICK, or get a Prop, crystal, EEPROM and a PropPlug.
I sure do not like the markings on the FT chip. RXD pin to Prop output, TXD to Prop input! The PropClip and Prop Plug seem to be marked the same way. Seems backward, no?
Find the other 'mode' bit is for 'open-drain/source tx' (from FullDuplexSerial source), from the comments.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko
h.a.s. designn
None of the Propeller boards so far except the Wulfden Robot Controller were really designed to allow use of pins 30/31 by anything except some kind of serial adapter for programming use (USB or RS232). It does make the board easier to use for development, but does tie up those pins. Similarly, pins 28/29 are really committed for an I2C bus for the boot EEPROM. If you can get to the pins, you can add additional I2C devices.
Fortunately, if you're not already tying up all the other pins for something else, you can use any other pair of pins for serial or I2C for that matter.
Back to one of your original questions ... You could use I2C for the Propellers to communicate with each other. The I2C bus does allow more than one master as well, but I don't think the routines in the I2C object were written for slave mode which one of the Propellers would have to be in. That doesn't mean it couldn't be added, but it would be new coding. I'd recommend an "open-collector" serial bus using the FullDuplexSerial routines (because of the buffering) in half-duplex open-mode. If you want more noise resistance and want to be able to separate the units, you could use RS485 (or is it RS483?) drivers external to the Propeller. For short distances, just use a current limiting resistor (like 220 ohm) between the Propeller pin and a common bus with a 3.3K (roughly) resistor from the common bus to +3.3V at one end. Look at some of the articles in Nuts and Volts on a Stamp network for ideas for programming.
Took a break to shower, and decided rather than 'cut' anything on precious PropSTICK, just reassign the pins temporarily. We were thinking of the same thing about the same time.
Re: PropPlug/Clip, it still appears to me the Rx and Tx on the label is backwards. Could NOT find any clear reference as to the signal flow from those pins or voltage levels.
I decided to just use FullDuplexSerial for both Props, rather than I2C because of the 'slavery' situation. Thanks for reminding me; most I2C ICs are slave. Hadn't thought about using half-duplex; maybe will work for this design and save a pin; right now the two Props only have 3 spare pins!! The two Props are on the same board; don't need 16 cogs, but do need lots of I/O.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko
h.a.s. designn
5v power measures 4.95v. A small switching module from All Electronics; made by Extron (China) supposedly good for 1 Amp. About 2-1/2" x 1-5/8" x 1". 110v ac prongs on case, several foot long cable to ac adapter plug. Hope if it ever fails it fails shorted rather than >5v.
5v logic uses a PIC for keypad scanner/7-segment LED display and serial I/O. Idle state to Prop is at 4.87v. Series resistor of 10K provides 3.91v at Prop input for FullDuplexSerial object; temporarily using A5 and A4 for Rx/Tx.
3.3v measures at 3.28v. So input is 0.63 above supply; must be silicon drop of pin to substrate clamping. At those voltages, current out of pin is about 0.076 ma. Shouldn't be any damage from that.
Now, to move on to more constructive details.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko
h.a.s. designn
Are FRQA and PHSA required to be defined?
Using a PropSTICK (5 MHz crystal and 16x PLL), so shouldn't the divider be 16 (the 011) and CTRMODE be 00100 for NCO?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko
h.a.s. designn
Use the Frequency Synthesis object located here....
http://ww1.parallax.com/Default.aspx?tabid=65
Make sure and set the "slave" Propellers to XINPUT mode and use the XI·input on them.
·
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe
IC Layout Engineer
Parallax, Inc.
Post Edited (Beau Schwabe (Parallax)) : 10/12/2006 9:26:23 PM GMT
You do have to have FRQA and PHSA defined. The output pin is connected to PHSA31 and FRQA gets added to PHSA every clock cycle. If you set FRQA and PHSA both to $80000000, then the output pin will be toggled every clock cycle. That will produce a clock of 40MHz. You want 1/8th of that, so set FRQA to $10000000 which should produce a clock on pin 24 of 5MHz.
Got the FreqSynth object, and have added the following to my Main:
but get "Expected a subroutine name" error on compile!?___ If I remove the '.start' then get "Expected "." error. What does the Prop Tool expect, I wonder.
Is a 'cogner' required or can the synth be used in the same cog as Main? Lots of new 'gotchas' on a new micro.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko
h.a.s. designn
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
Seems some things are finally working.
Below is a fragment of the program.· I've used part of DScope program·as a start, deleting, changing·as needed; tough for a newbie to do a program from scratch.)· The comments on the right in BOLD are my comments for this message.
PUB StartDisplay cognew(Control1,@stack) waitcnt(clkfreq >> 4 + cnt) repeat until status == StatusIdle ' aquire_fast(0, 0) Fsynth.Synth("A", 24, 5_000_000) ' NO 5 MHz from this???? ' ' PropSer.start(Prop_Tx, Prop_Rx, %0000, Prop_Baud) PICSer.start(PIC_Tx, PIC_Rx, %0000, PIC_Baud) PRI Control1 | i,r,k,keyok status := StatusInit 'set system status to Initialize ' if VGADisplay 'start display ' Display.start(16) ' else Display.start(12) ' Key.start(26, 27) 'start keyboard ' if VGADisplay 'establish new palette ' Display.setcolors(@vga_palette) ' else Display.setcolors(@tv_palette) ' Display.str(string("Control Prop#1; 10 Oct.2006")) 'display startup message gotoxy(CenterAlign(@title),0) Display.str(@title) waitcnt(clkfreq << 1 + cnt) 'wait 2 seconds DisplayHelpScreen 'start in help screen DIRA[noparse][[/noparse]5]~ ' THIS WAS USED TO VERIFY THAT SERIAL INPUT DIRA[noparse][[/noparse]16]~~ ' COULD BE SHOWN ON A LED AND SCOPED ' repeat ' OUTA[noparse][[/noparse]16] := INA[noparse][[/noparse]5] repeat if (c := PropSer.rxcheck) <> -1 ' process a byte from the other Propeller if (c := PICSer.rxcheck) <> -1 ' process a byte from PICSer c := rxbyte Display.hex(c,2) ' HOPED THIS WOULD SHOW SOMETHING Display.str(string(" <= GOT HERE! ")) ' ON THE MONITOR; BUT NEVER GET HERE OUTA[noparse][[/noparse]16] := INA[noparse][[/noparse]5] ' THIS LOOP IS TOO SLOW TO SHOW 38400 BAUD SIGNALS 'PRI stop ' THE REST OF THIS WAS FROM JON WILLIAMS DEBUGGER. MAYBE ' comment ' THAT'S WHY UART TO DISPLAY DOESN'T WORK??? 'uart.stop PRI putc(txbyte) ' comment ' uart.tx(txbyte) PRI hex(value,digits) ' prints a hex value <<=(8-digits) << 2 repeat digits putc(lookupz((value <-=4) & $F:"0".."9", "A".."F")) 'PRI getc : rxbyte ' comment 'rxbyte := uart.rxI'm just realizing that this post being done on my ThinkPad PC appears quite different from my iMac!·
OK (I have my 'bullet proof' jacket on), so everyone, fire away at this coding.· I sure need to get moving on the uart handling end; the Synth business is way down the line (only needed for the second Prop, which isn't needed today).
·PS - ·on a different subject, just noted on Prop Manual, page 17, it shows a Prop with Rx on 31 and Tx on 30, yet the Propeller Plug end of these signals, itshows those signals as TX and RX.· Why are they 'backwards' to me?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko
h.a.s. designn
From the Propeller's perspective P31 is the RX while P30 is the TX
From the Propeller Plug's perspective TX connects to the Propellers RX, and the Propeller Plug's RX connects to the Propeller's TX.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe
IC Layout Engineer
Parallax, Inc.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe
IC Layout Engineer
Parallax, Inc.
Yes,I do have this at the beginning of my program
Many things seem to work OK. Am able to display a whole screen of information; generated by Display.str(string("...text....")) statements. And they don't come up slowly; appears all in one flash. Though don't know how much slower it would appear if the default Prop clock rate were running.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko
h.a.s. designn
Just one thing I noted ... In Control1, you call PropSer.rxcheck without initializing PropSer (it's commented out).
In StartDisplay, you call Synth, then let the cog stop after initializing PropSer. I think that stops the counters.
Put in a repeat as the last statement in StartDisplay and see what happens.
How many objects can be run in one cog?___ Any problem with Synth, both soft uarts and TV_Terminal running in same cog?___ I did a 'Find' and cannot locate any uncommented-out 'stop's. There are two that are commented out.
Re: Synth, I just happened to put my finger on pin 24, supposedly the 5 MHz output pin, and scope shows noise as if it were an input!!! WHAT's going on here? Now that is strange.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko
h.a.s. designn