Program not running outside 12blocks SOLVED!

[dlevartt]

I have a simple program that runs fine inside 12blocks. But if I try to connect to it through the propeller serial terminal. It does not seem to connect.
I'm running it at 115K which is supposedly the right baud rate but I have tried others with similar results.

Anybody have any ideas?

[dlevartt]

I'm wondering if programs built by 12Blocks can even run outside of the 12 blocks IDE. If not, this will be a severe limitation. I really like the tool, but if I always have to have a pc attached it's not very practical for even teaching, since the range of practical applications will be greatly reduced.

So someone can learn to program propellers, well, if you can't take that knowledge out of the classroom, it's a waste of time since everyone will still have to learn spin and since the spin code created by 12blocks is not clean(won't run in bare propeller environment), learning in 12 blocks could actually be a detriment.

I hope I'm wrong. Please tell me I'm wrong and set me straight. I love this tool and its potential.

[dlevartt]

OK, I have a solution of sorts.

I replaced the terminal object in the spin code with fullDuplexSerial
gutted the vp.config stuff in main
commented out the clear and position function calls since they don't exist in fullDuplexSerial
added a start call to define the usb port parameters and 'tada; Everything works exactly as desired

There might be a better way to pull this off, and if there is, I'd love to know about it, but so far, this is the only one that I've gotten to work.

SPin listing after mods
============================================================
CON
_clkmode = xtal1+pll16x
_xinfreq = 5_000_000 '80 MHz
_motorlpin=0 'Left motor
_motorrpin=1 'Right motor
_micpin=8 'Microphone
_mic2pin=9 'Microphone Dac
_iranodepin=1 'Common anode of ir distance sensors, driven with 38khz signal
_audiolpin=10 'Audio Left
_audiorpin=11 'Audio Right
_videopin=12 'Video
_video2pin=13 'Video
_video3pin=14 'Video
_video4pin=15 'Video
_mousedpin=24 'Mouse Data
_mousecpin=25 'Mouse Clock
_keydpin=26 'Keyboard Data
_keycpin=27 'Keyboard Clock
_eepromDpin=28 'Eeprom Data
_eepromCpin=29 'Eeprom Clock
_vppin=30 'ViewPort Conduit
_vp2pin=31 'ViewPort Conduit

OBJ
_vp :"FullDuplexSerial" 'used to be "terminal" 'terminal+conduit
VAR
long _outp,_inp,_io
long x
long _c0,_c1
pub _main|_s_pub0[70]
_vp.start(31, 30,0, 19200)
'initialize global objects and call global start blocks
_c0:=4
_c1:=4
cognew(_pub0,@_s_pub0)
repeat
_io:=ina
pub _broadcast(msg)
case msg
-1:
pub _broadcastsync(msg)
case msg
-1:
pub _do_state(state)
case state
-1:
'other public functions
pub _pub0'*(24,53):cognew($0,@_s$0)
{prints values to the built-in terminal- click on "view terminal" after loading.}'*:{$}
'_vp.Clear'*:_vp.Clear
'_vp.position(_c0,_c1)'*:_vp.position($,$)
repeat'*:repeat
x:=_vp.rxcheck'* 1:$:=$
if x>0'*:if $
if x=="a" '* 1:if $ %else
_vp.str(string("tada"))'* 1:_vp.str($)
else
_vp.dec(x)'* 2:_vp.dec($)
'data
DAT

[dlevartt]

The reason this was happening is; Because I was using the 'terminal' key pressed, print value, and print text blocks, 12blocks uses viewport as the terminal software. Viewport is not a vanilla terminal object, rather it is used, in this case, as a means to detect pin status and variable contents from within the propeller chip itself. as such, there is more than the usual terminal communications going on. While keyboard strokes are transferred, so are a number of other variables. If you tried to see this in a vanilla terminal program, such as the Parallax Serial Terminal, all you would see is a steady stream of meaningless mumbo jumbo. Your program would appear to be broken, but it is not. while I love the value that viewport brings to the development table, it does get in the way when you need to talk to a 'normal' comm channel.

This only present a problem to those who want to have something communicate with the propeller outside the viewport environment. This could be any number of things. In my case, it's a robot that communicates to an on board PC using proprietary software that is not aware of the viewport protocol. the example above is just a simple test using simple terminal software.

I think 12block should implement a software.xml file that describes the software environment similar to the hardware xml profile. this file could contain a value that would name the object used to talk to the terminal and motion blocks.

For instance; I am using a propeller to drive a robot. The drive used is Parallax's motor with position controller (encoder) kit. because 12blocks only understands pwm motors, I had to write my own motion control blocks, which are identical to the existing motion blocks on the screen, but use my own motor spin obj. It would be nice if these could be dropped in instead of totally new blocks that do the same thing.

All in all, I love 12Blocks. Once I figured out how to get around a couple of issues, I've discovered a great program visualization tool (even if I have to tweak the spin code a little)

[Hanno]

Hi,
Good troubleshooting! Yes, 12Blocks uses the "conduit" to transfer data to/from the program running in the Propeller. This allows you to modify variables and parameters while the program is running and view variables and pin states. When you use terminal blocks, that data is send through the conduit as well.
Since all of this data is going through the same connection you have to use the terminal built into ViewPort or 12Blocks. Using a basic terminal like "hyperterminal" will show you junk.
If you want to speak standard rs232 to a device, there should be blocks in the "pins" section that do that. I also like your idea of extending the configuration options to allow users to specify the behavior of a block. I'm currently doing something similar when the user switches between "tv" and "vga" output- you use the same blocks, but different objects are compiled. For your situation, I think an option to switch between "basic terminal" and "conduit" would resolve things nicely?
Finally, how to best map the "motion"- or in general, all the blocks to the specific hardware used. The hardware directory currently contains .txt files that are used like "templates" to output the code. In the future, each hardware can have it's own directory of object files that override the default files. OK?
Hanno

[dlevartt]

Thanks for all the answers.

Yes, switch in 12Block to switch between conduit ,raw, and terminal modes would be perfect

As far as the motion blocks, I would just expose the spin code in the hardware directory. When you say that there are txt files in the hardware directory, I assume you mean the one you have as opposed to the one we have as I don't have that.


also, your newline block generates a linefeed in spin. you obviously have it matching in viewport but in

Looking forward to the new release. Love the tool Using it to build a mid sized robot around the propeller robot control board and a fitPC All the low level routines are on boars the propeller while the PC handles executive functions. Think of the prop as the central nervous system

cheers.