I guess we can't get very far without that, I will check with my NXP contacts.
I don't want to muck with Parallax github, so I won't post the code there, I guess I could setup a parallel one, though I really haven't been tracking code changes and my stuff was based on version 0.30.0.
I'm not sure why the version of PropGCC matters. This board has an ARM chip on it, right? Anyway, I played around with the module some more last night but have yet to see any signs of life from it other than a bright blue LED. It locks up my Win10 machine but then almost everything locks it up so I doubt that's the board's fault. I tried connecting to it using Win7 on a VirtualBox VM running on my Mac but couldn't get the drivers sorted out. And I was unable to find a Mac driver at all. If you'd like me to send the module to someone else who can give you better feedback I'd be happy to.
I have an email into the author of the Windows USB driver, should hear from him in a day or so (he travels a lot). Later I will fire up an old Win7 machine to make sure I am not chasing ghosts on Win10 (ie if it works there, I'll wait)
I just tried a virgin Win7 desktop machine and it was unable to find a driver for the VCOM port exposed by your module. I tried selecting both of the driver directories in your CBasic.zip file but it couldn't load drivers from either. It also couldn't find a driver on the net. I don't think this is just a Win10 problem.
I am bringing up an old XP machine and WIn 7 machine, neither of which have had this board plugged in, so will test that out.
On the Mac side got this from NXP --
For OSx and linux have built-in CDC driver support. The embedded side FW is written to work seamlessly. If you have a board which is not enumerating properly on OSx and showing up as serial port. Then we need to fix the embedded side.
Wow, I guess I don't have a Win7 system anymore. But my XP netbook sees and communicates with the board in TeraTerm and a Tcl based program, but Qt does not. My other desktop that I thought had Win7 on it is now linux/WinXP. Maybe I should clean up my office, another PC might be buried somewhere.
It does enumerate as ttyACM0 on my linux system. Have not tried to talk to it yet, seeing if it works on the Mac mini I have.
From a terminal emulator
ctl-C -- soft reset, you should see a welcome message
@ XXXX will dump memory at XXXX --- hex address
! XXXX YYYY will write to memory at XXXX
? -- sends back a set of vectors for the BASIC compiler
It does enumerate as ttyACM0 on my linux system. Have not tried to talk to it yet, seeing if it works on the Mac mini I have.
From a terminal emulator
ctl-C -- soft reset, you should see a welcome message
@ XXXX will dump memory at XXXX --- hex address
! XXXX YYYY will write to memory at XXXX
? -- sends back a set of vectors for the BASIC compiler
I can try Linux in a few minutes. My Mac did see the module but I couldn't connect to it using CoolTerm. I kept getting a message that it was already in use by some other program.
I plugged the module into a Ubuntu Linux box and got a /dev/ttyACM0 device but using minicom to talk to it doesn't seem to work. I typed a bunch of control-c characters but got no response. Are you sure there is firmware flashed into this module?
Moved one back over to the PC, OK on TeraTerm and Tcl based tool. The firmware is in the /Cbasic directory as BASIC.bin. You can reload it by removing the device, short pins 3 and 4 together and plug back in. It will appear as a disk drive to a PC. You can remove the firmware.bin file and copy any ARM .bin file. This is how mbed boards load applications.
I'll hook up the JTAG while the Stamp is hooked to a PC/Linux box, there is a debug version of the board for that.
In the meantime I ported the compiler to the Mac. It runs on my mini, though I get a warning about gets() being unsafe. You can use it as a BASIC emulator on the Mac.
I'll hook up the JTAG while the Stamp is hooked to a PC/Linux box, there is a debug version of the board for that.
In the meantime I ported the compiler to the Mac. It runs on my mini, though I get a warning about gets() being unsafe. You can use it as a BASIC emulator on the Mac.
When running as an emulator, ctl-C or QUIT will end it. Actually QUITDUMP outputs the ARM hex file for download. Other than that pretty vanilla BASIC. Though not real useful as a BASIC, we use it to debug the compiler, as it is convenient to type short snippets of code.
When running as an emulator, ctl-C or QUIT will end it. Actually QUITDUMP outputs the ARM hex file for download. Other than that pretty vanilla BASIC. Though not real useful as a BASIC, we use it to debug the compiler, as it is convenient to type short snippets of code.
bruce-eisenhards-computer:~/home/BASIC bruceeisenhard$ ~/home/BASIC/a.out
"ARMbasic[9.36k] on OSx Copyright 2016.
"
warning: this program uses gets(), which is unsafe.
print "Hello"
run
"... 0.03K code 0.00K data programmed
"
Executing on OSx...
Hello
... Finished on OSx in 1 ms
That mac is running 10.4.11, probably not enough memory to upgrade. Is there some special way to compile for compatibility mode across Mac OSx versions?
bruce-eisenhards-computer:~/home/BASIC bruceeisenhard$ ~/home/BASIC/a.out
"ARMbasic[9.36k] on OSx Copyright 2016.
"
warning: this program uses gets(), which is unsafe.
print "Hello"
run
"... 0.03K code 0.00K data programmed
"
Executing on OSx...
Hello
... Finished on OSx in 1 ms
That mac is running 10.4.11, probably not enough memory to upgrade. Is there some special way to compile for compatibility mode across Mac OSx versions?
Okay, it's working for me now as well. I think it failed before because I first tried to type "list".
I have minicom talking to the board on Linux, though I have to figure out the configuration to handle just getting a LF. The welcome message is sent long before the program starts up so I don't see that, and it seems like minicom filters the ctl-C character.
By typing @0
I see it dump the memory
Or ?
to see the vectors for the compiler
On my Mac its version does not support the CDC driver, so I'm stuck on that version.
David- sent you a PM about a Tcl version to download. I have had Tcl versions of the terminal program running for a long time, and will look into using that as terminal/download program until QtSerial seems more stable to me, and I may try Parallax's latest version just to see if they talk to each other.
propterm 0.30 seems to have missing flush like symptoms on Win10, propterm 0.35 seems a bit better, but the program won't close, unless I physically disconnet the module. So there still seems to be issues there with Win10, though TeraTerm and my Tcl based versions seem OK now.
Comments
On the Mac side got this from NXP --
From a terminal emulator
@ XXXX will dump memory at XXXX --- hex address
! XXXX YYYY will write to memory at XXXX
? -- sends back a set of vectors for the BASIC compiler
My Mac is from 2010. What is CDC?
http://www.ccsinfo.com/faq.php?page=linux_cdc
sudo minicom -D /dev/ttyACM0
However, ^C still doesn't produce any output.
In the meantime I ported the compiler to the Mac. It runs on my mini, though I get a warning about gets() being unsafe. You can use it as a BASIC emulator on the Mac.
eisenhard.net/files/ARMbasic.out
That mac is running 10.4.11, probably not enough memory to upgrade. Is there some special way to compile for compatibility mode across Mac OSx versions?
The monitor on the ARM handles writes of the hex file into Flash. bpp is the c-pre-processor edited to handle BASIC style comments
eisenhard.net/files/Linux-arm-basic-pp.tgz
By typing @0
I see it dump the memory
Or ?
to see the vectors for the compiler
On my Mac its version does not support the CDC driver, so I'm stuck on that version.