Using some of the propscope hardware (a2d) still requires me to code some software side.... But I am almost done with the schematic and making the pcb foot prints plus schematic parts.. Since I had to redo most of the propscope schematic, I did it all, plus the pcb.
Now I get to hack it up to fit my need.
So... to start I simply modified the parallax visual basic demo program for the propeller...
To run on the propscope. (so nothing is happening in the code but the AN018 code minus its I/O operations, it just communicates with the pc at 2Mbaud.
But the data that the VB program is receiving/sending is super slow, the code is too slow, so i will need to work on that, (serial port needs to be made into a stream object or something, not sure, gotta read more)
So some code changes are needed. Along with how the serial port is used, its very slow as you can see by the video.
The data on the propside and over the serial, is going much faster than 10hz, but this simplistic vb code only allows that. (the serial function is triggered only every 20ms due to vb timer limits. I don't know enough yet about vb to make it show the 2mbit data displaying rate.
So you think you're getting past a problem, and a new one shows.... hmm perhaps 2Mbit of data dumping into the vb buffer of 1024... might not be so good.. and when i turn the port off... no over flow... hmmm
One would hope the modern visual studio would have better debugging ability.. but it just says that debugging isn't possible.
So some debugging info does show in that popup, but not much, you havta kinda know what your program is doing to guess what its doing wrong.
2018 and ms debugger still just as useless. Its also possible im doing something wrong, or the free version of studio dosen't allow it.
Hmm., actually this looks like im overloading my send buffer...
This post is still yet another post spam as a result of not being able to add attachments to previous posts.
Debugging is a bear no matter the tools you have. Single stepping and logic analyzers work but are incredibly slow. Software debuggers are not much better unless you have some idea of where the problem is. Debug statements or breakpoints in modules and subroutines help but are tedious to add.
One of the neatest ideas back in the day was adc's on the address bus and an oscilloscope in xy mode to see where the program was executing. Later the ADC's and scope were replaced by decoders and leds. Of course that required an external address bus that could be accessed so it is not much use on today's microcontrollers.
One of the neatest ideas back in the day was adc's on the address bus and an oscilloscope in xy mode to see where the program was executing.
Gonna havta try that one day...
I found that the vb project that I based this project on has an old version of CLR put into a config file...
programname.vbproj Has a line in it that looks like this...
If your file has a version that is older, then you need to replace your version, with v4.6.1 in your programs .vbproj file.
Thats assuming you in fact do use the latest visual studio with the latest .net dev framework installed.
This allows debugging while running the program live(you can change the code) if you are on a 64-bit cpu.
(you must turn off native code debugging in the debugger engines) located in your project properties page.)
This is funny, so i did all this to make my clr version able to debug and change code live, but it then says changes are not allowed while running lol. BUT at least my cpu and memory profiler both work now... From what I read, the live code debugger/change dosen't work anyway.
But its nice that my code is now using a later clr version. That is an important thing if your code can handle the new version, it makes sense why the clr didn't automatically change with the new version installed, but when I loaded the old project in vb, studio should have asked me if I want to use the latest version of clr with my project.
Delegates? Did microsoft frame its vb code structure from a convention?
Well, some progress.. much faster serial interfacing code... not sure if its at its max yet... (as far as spin)
505hz ... the amount of serial cycles my program goes through in a second.
(a serial cycle includes the entire serial data packet of
myheader Byte "!P1", 10, 0
Thats seriously fast for a human interface, but seriously slow for any kind of data stream.
Its a good thing i don't know what im doing in vb, because those numbers are entirely too slow to be 2mbit if I understand how much data i am dealing with per serial cycle.
I guess I am in fact re-writing the propscope software,.. after all..
So I purchased a few prop scopes to have more than 2 channel on screen...
Yea, not gonna happen....
From what I can tell, hanno is MIA. Before diggin into this vb and stuff, I tried to reach out to hanno for support on my developer copy of his viewport, but some of his websites are shut down, the forms on sites that do work, the contact page show no email, and doesn't even work... the latest site has the same form for support as the one on the viewport page(the viewport one dosen't work)....
Seriously, multiple instances is literally a check box in vb, sure database might be an issue if its used with multiple instance,,,, but is it even used with propscope...
Yawn.... Time to reinvent the same wheel that oh i dunno 40 other people did... but this time, its open source. no more redoing THIS wheel. Its just gonna take me a long time to do... I have noticed here in the forums, much support for the prop and the code... so ... i think i'll continue to tackle the vb pc side of the interface,,,
I guess I should make the interface look like a scope to begin.. that part is easy.. the functional code.. not so...
But after seeing that multiple instance error, I see the propscope was also written (ironically) in vb.
So my task here is most likely possible, but talk about a mountain to climb.
The prop scope software... Streaming is BUGGED, the Tools-->manage prope is BUGGED, the dial for the resolution is BUGGED, ZOOM and PAN...heh... dont even try those, etc...
Do I want to do this? No, it makes it easier for the propscope to be copied, but this software has ran me into a brick wall for the last DAMN time.
But don't think making abandon-ware is a very nice thing to do to products that are still on the market.
The hardware alone tho is worth it, especially when they are on sale for 50% off. Nice probes, nice bnc connectors, the usb cable feels like it has nice conductors inside...
In my opinion, the propscope is a hardware product for developers who wish to make hardware like it, or software to run it.....,it also has "free" software for demonstration of the hardware, free usually means no support.
Also the propscope is a great platform for testing 6.25mhz programs, the pcb is a 4 layer pcb with ground planes, the analog and digital grounds are separated(for the most part).
It has a metal body for better shielding...
Anyway.. for those that hate vb.....
Don't worry, i'll port it.
And if I can't, I'll rewrite it in c once i do the more simple vb. (i found lots of opensource vb scopes that have tons of functions to be ripped)
Me and whos army?
"You want me to hack the planet? You're dreamin', pal! Oh, there are Hot Pockets involved? Time to get serious."
I'll just end up with vb code that looks like this...
And then finally realize what kind of learning curve I have encountered.
Sometimes it is easier (and better) to analyze the old software or interface to discover the basic functions it performs and then use a modern well supported language you are familiar with to reproduce those functions.
In many cases I have discovered that the effort needed to understand software someone else wrote well enough to make changes to it has been much greater than it would have been to start from scratch.
Sometimes it is easier (and better) to analyze the old software or interface to discover the basic functions it performs and then use a modern well supported language you are familiar with to reproduce those functions.
In many cases I have discovered that the effort needed to understand software someone else wrote well enough to make changes to it has been much greater than it would have been to start from scratch.
I even found out that the same applies to software I wrote myself 25+ years ago...
I haven't looked at Hanno's Software in detail, but the Software loads the PropScope every time, it is supposed just to have Calibrations in ROM.
So we are able to intercept the load and catch a binary. The important part will be in assembler and it should not be soo problematic to find cog-images.
Has anyone a P1 disassembler? Never thought about that before.
Umm, I would say, that you probably shouldn't disassemble the current software for the propscope or the binary.
Clearly up to this point the writer of the software has failed to see the benefit that opensource gains you in the long run.
And such, has chosen to not open it.
SO technically, reverse engineering it and using the current binary could be illegal if I chose to base this project on any of it.
I am not basing this software on anything related to the current propscope software, the fact that its VB is MERELY COINCIDENTAL (parallax offered AN018, which contains the vb code that this project is based on.)
I see what you mean tho, the FUNCTIONS the hardware does is not dependent on the software, and documenting those functions using the free software is what you are talking about.
I plan to do much more than the propscope software allows, since i am seeing so many o-scope vb opensource programs with all the code already done for all those functions.
Time to adapt it all, and then write spin/pasm code to do it.
I am, in fact, rewriting the pc software and the prop scope hardware (but like you say i will use OPENSOURCE code that I find on the net from other peoples vb oscopes.)
Unless the writer of the current binary just opens it, its pointless to rev engineer it when that still limits you to using a locked packed binary.
I want to, and am going to, make the propscope firmware a modifiable thing, with the possibility that a communication protocol could be used that aligns with labview protocols.
I AM going to need LOTS of help making the firmware and software as my programming techniques knowledge isn't polished, right now im "opening a can of beans with a rock".
I have looked into the subject of using the current firmware, ....
I don't know what I would do if I couldn't read the prop code that I have written, and still figure out whats going on for the vb computer side of the link.
Without seeing the Prop code(and inserting debugging), so you can identify issues with your own code, its virtually pointless to use locked firmware.
From what I can tell, you knowing programming, know that its probably easier just to re-write the prop firmware.
Plus then its all open and can be improved upon by the community. (and will probably be, since I am not fluent in algorithmics.)
Speed, yum. Hey, this is kinda fun. Thanks to all the people who put code on the net to let people learn.
I don't mind causing arithmetic overflows... when im testing the loop speed possibilities of multi threads...
I guess i can't turn the thread.sleep(0) off.
(i didn't realize telling a thread to sleep for 0 would have any difference... i guess its the sleep function its self, preventing the overflow)
I suppose no delay counting loops are the next step for better granularity... state machines with threading.
Perhaps im missing it but i see no built in function in vb with a sleep of less than 1ms. Thats funny.
Time to get the send and receive loops in their own threads.. that should speed things up alot...
Gotta love having 1.6ghz looping capability... mmmm threading...
To test the spin limits I decided to test at different baud rates only.
I also set 2 stop bits for these screen shots to see if i could get more stable header.
115.2K
250K
500K
750K
1M
1.5M
2.0M Spin tops out at 2Mbit, (the serial port no longer slows spin down, its the other way around)
2.5M
DOSEN'T WORK. (bad header sync) Odd...
3.0M
I AM able to get 3MBit connection with sync. I wouldn't have sync if the data wasn't really 3mbit.
The serial loop rate isn't any faster at 3mbit because spin is doing the data send, and can't go faster.
I will need to do my data cycle and serial send in pasm. Hmm, yet another language..
Technically, i can code the vb to take any data rate and not even touch the propscope's code (until the vb interface is done), as long as i know how my data is organized ... this then just leaves the prop side to run the main propscope i/o (spin), package the a2d and chunk it out to the pc(pasm).
Verdict: VB is plenty fast. VB interface can be done. Spin propscope interface can be done.
No idea how to do: a2d pasm and serial data frame send/recieve pasm.
Its easier to develop my little rail tool now, than to redo the propscope software and firmware.
For the latest developments, I have investigated more.
I found that the sdxn136ps decoder model has a big issue with its transponding circuit or code, and its very bad.
All the best features of this decoder, transponding, ops mode readback, etc... are useless.
This is what is known as a true lemon, in the manufacturing world, since all 13 of my sdxn136ps decoders do this.
It affects the programming track also and will report its id as random ids that are in the system.
The transponder is normally only supposed to squak at the proper time, but the sdxn136ps decoders transponder will squack at random times, this causes devices like the bxp88 and the bld +rx4 to report incorrect locomotive id's in the zone that the sdxn136ps decoder is in.
I have multiple sdxn136ps decoders that all do this, personally i think its a bug in the design of it.
This is partly why i am trying to develop this tool, its hard to see what is going on, on the rail.
If I can't get these sdxn136ps decoders fixed, I am going to reverse engineer them, desolder all the parts, and make my own transponding sound decoder with the propeller chip and a micro sd card.
(i think i may just do that anyway, it would be awesome to have my own transponding sound decoder, and one that was open source for everyone too )
Everyone already did the (deep code)sound work for the propeller, so i just need to bring it all together(multiple systems integration), and I am pretty good at that, i am not so good at pasm.
A screen shot of a sdxn136ps decoder stealing the id's of any in the slot list. VERY BAD. Its an identity thieving decoder.
This shot shows the program jmri controlling my layout. The engine 3780 is located in zone8 and has a sdxn136ps decoder in it.
You can see the reports show that all 3 locomotives in zone 8, that is because of the sdxn136ps bug.
The locos in zone1 (333) and zone 4 (1412) are perfectly working dz123 non-sound decoders, they do transpond properly.
They are not making reports that are false.
@"Clock Loop" said:
To test the spin limits I decided to test at different baud rates only.
I also set 2 stop bits for these screen shots to see if i could get more stable header.
Is this VB interface based on the "QuickStart Communicator" app I wrote back in 2010? Just curious...I don't see that app anywhere on here, but the interface looks familiar.
Comments
I found some info about open scope ...
They have some info...
https://github.com/rosco-pc/OpenScope
Hmm...
Now I get to hack it up to fit my need.
So... to start I simply modified the parallax visual basic demo program for the propeller...
To run on the propscope. (so nothing is happening in the code but the AN018 code minus its I/O operations, it just communicates with the pc at 2Mbaud.
I had to find a full duplex serial plus object and Jonathan Dummer(lonesock) made one that has killer speeds using two cogs. NICE! THANKS!
"Fast Full-Duplex Serial"
http://forums.parallax.com/discussion/comment/1212013/#Comment_1212013
Heres v1 of FFDS1
http://forums.parallax.com/discussion/143514/fast-full-duplex-serial-1-cog-a-k-a-ffds1
But the data that the VB program is receiving/sending is super slow, the code is too slow, so i will need to work on that, (serial port needs to be made into a stream object or something, not sure, gotta read more)
http://www.parallax.com/downloads/an018-communication-pc-application
So some code changes are needed. Along with how the serial port is used, its very slow as you can see by the video.
The data on the propside and over the serial, is going much faster than 10hz, but this simplistic vb code only allows that. (the serial function is triggered only every 20ms due to vb timer limits. I don't know enough yet about vb to make it show the 2mbit data displaying rate.
One would hope the modern visual studio would have better debugging ability.. but it just says that debugging isn't possible.
So some debugging info does show in that popup, but not much, you havta kinda know what your program is doing to guess what its doing wrong.
2018 and ms debugger still just as useless. Its also possible im doing something wrong, or the free version of studio dosen't allow it.
Hmm., actually this looks like im overloading my send buffer...
This post is still yet another post spam as a result of not being able to add attachments to previous posts.
One of the neatest ideas back in the day was adc's on the address bus and an oscilloscope in xy mode to see where the program was executing. Later the ADC's and scope were replaced by decoders and leds. Of course that required an external address bus that could be accessed so it is not much use on today's microcontrollers.
Gonna havta try that one day...
I found that the vb project that I based this project on has an old version of CLR put into a config file...
programname.vbproj Has a line in it that looks like this...
If your file has a version that is older, then you need to replace your version, with v4.6.1 in your programs .vbproj file.
Thats assuming you in fact do use the latest visual studio with the latest .net dev framework installed.
This allows debugging while running the program live(you can change the code) if you are on a 64-bit cpu.
(you must turn off native code debugging in the debugger engines) located in your project properties page.)
This is funny, so i did all this to make my clr version able to debug and change code live, but it then says changes are not allowed while running lol. BUT at least my cpu and memory profiler both work now... From what I read, the live code debugger/change dosen't work anyway.
But its nice that my code is now using a later clr version. That is an important thing if your code can handle the new version, it makes sense why the clr didn't automatically change with the new version installed, but when I loaded the old project in vb, studio should have asked me if I want to use the latest version of clr with my project.
Meh.
Well, some progress.. much faster serial interfacing code... not sure if its at its max yet... (as far as spin)
505hz ... the amount of serial cycles my program goes through in a second.
(a serial cycle includes the entire serial data packet of Thats seriously fast for a human interface, but seriously slow for any kind of data stream.
Its a good thing i don't know what im doing in vb, because those numbers are entirely too slow to be 2mbit if I understand how much data i am dealing with per serial cycle.
So I purchased a few prop scopes to have more than 2 channel on screen...
Yea, not gonna happen....
From what I can tell, hanno is MIA. Before diggin into this vb and stuff, I tried to reach out to hanno for support on my developer copy of his viewport, but some of his websites are shut down, the forms on sites that do work, the contact page show no email, and doesn't even work... the latest site has the same form for support as the one on the viewport page(the viewport one dosen't work)....
Seriously, multiple instances is literally a check box in vb, sure database might be an issue if its used with multiple instance,,,, but is it even used with propscope...
Yawn.... Time to reinvent the same wheel that oh i dunno 40 other people did... but this time, its open source. no more redoing THIS wheel. Its just gonna take me a long time to do... I have noticed here in the forums, much support for the prop and the code... so ... i think i'll continue to tackle the vb pc side of the interface,,,
I guess I should make the interface look like a scope to begin.. that part is easy.. the functional code.. not so...
But after seeing that multiple instance error, I see the propscope was also written (ironically) in vb.
So my task here is most likely possible, but talk about a mountain to climb.
The prop scope software... Streaming is BUGGED, the Tools-->manage prope is BUGGED, the dial for the resolution is BUGGED, ZOOM and PAN...heh... dont even try those, etc...
Do I want to do this? No, it makes it easier for the propscope to be copied, but this software has ran me into a brick wall for the last DAMN time.
But don't think making abandon-ware is a very nice thing to do to products that are still on the market.
The hardware alone tho is worth it, especially when they are on sale for 50% off. Nice probes, nice bnc connectors, the usb cable feels like it has nice conductors inside...
In my opinion, the propscope is a hardware product for developers who wish to make hardware like it, or software to run it.....,it also has "free" software for demonstration of the hardware, free usually means no support.
Also the propscope is a great platform for testing 6.25mhz programs, the pcb is a 4 layer pcb with ground planes, the analog and digital grounds are separated(for the most part).
It has a metal body for better shielding...
Anyway.. for those that hate vb.....
Don't worry, i'll port it.
And if I can't, I'll rewrite it in c once i do the more simple vb. (i found lots of opensource vb scopes that have tons of functions to be ripped)
Me and whos army?
"You want me to hack the planet? You're dreamin', pal! Oh, there are Hot Pockets involved? Time to get serious."
I'll just end up with vb code that looks like this...
And then finally realize what kind of learning curve I have encountered.
In many cases I have discovered that the effort needed to understand software someone else wrote well enough to make changes to it has been much greater than it would have been to start from scratch.
I even found out that the same applies to software I wrote myself 25+ years ago...
Mike
So we are able to intercept the load and catch a binary. The important part will be in assembler and it should not be soo problematic to find cog-images.
Has anyone a P1 disassembler? Never thought about that before.
Enjoy!
Mike
Clearly up to this point the writer of the software has failed to see the benefit that opensource gains you in the long run.
And such, has chosen to not open it.
SO technically, reverse engineering it and using the current binary could be illegal if I chose to base this project on any of it.
I am not basing this software on anything related to the current propscope software, the fact that its VB is MERELY COINCIDENTAL (parallax offered AN018, which contains the vb code that this project is based on.)
I see what you mean tho, the FUNCTIONS the hardware does is not dependent on the software, and documenting those functions using the free software is what you are talking about.
I plan to do much more than the propscope software allows, since i am seeing so many o-scope vb opensource programs with all the code already done for all those functions.
Time to adapt it all, and then write spin/pasm code to do it.
I am, in fact, rewriting the pc software and the prop scope hardware (but like you say i will use OPENSOURCE code that I find on the net from other peoples vb oscopes.)
Unless the writer of the current binary just opens it, its pointless to rev engineer it when that still limits you to using a locked packed binary.
I want to, and am going to, make the propscope firmware a modifiable thing, with the possibility that a communication protocol could be used that aligns with labview protocols.
I AM going to need LOTS of help making the firmware and software as my programming techniques knowledge isn't polished, right now im "opening a can of beans with a rock".
I have looked into the subject of using the current firmware, ....
I don't know what I would do if I couldn't read the prop code that I have written, and still figure out whats going on for the vb computer side of the link.
Without seeing the Prop code(and inserting debugging), so you can identify issues with your own code, its virtually pointless to use locked firmware.
From what I can tell, you knowing programming, know that its probably easier just to re-write the prop firmware.
Plus then its all open and can be improved upon by the community. (and will probably be, since I am not fluent in algorithmics.)
I don't mind causing arithmetic overflows... when im testing the loop speed possibilities of multi threads...
I guess i can't turn the thread.sleep(0) off.
(i didn't realize telling a thread to sleep for 0 would have any difference... i guess its the sleep function its self, preventing the overflow)
I suppose no delay counting loops are the next step for better granularity... state machines with threading.
Perhaps im missing it but i see no built in function in vb with a sleep of less than 1ms. Thats funny.
Time to get the send and receive loops in their own threads.. that should speed things up alot...
Gotta love having 1.6ghz looping capability... mmmm threading...
My variables are smoking...
8 bits + 1 start and 1 stop = 10 bits per serial loop.
1 serial loop for every set of the header(4 bytes) and the data (16 bytes)
Byte 1 is where bit0 to bit7 is stored.
VB counts when the bit transitions from 0 to 1.
Byte 0 and byte 2 to 16 is un-used but still transfered data.
maths..
20 bytes * 10 bits per byte = 200 bits.
200 bits * 1.5khz serial cycle rate =
Total data rate:
300,000 bits per second.
The prop isn't sending data fast enough.
Spin is my limit here..
PRI PC_CommsTX | index1 ' Declare private method and 2 local variables serial[0].start(RX_PIN, TX_PIN, PC_BAUD) ' Start UART (FullDuplexSerial) cog Repeat serial[0].str(@myheader) 'send header index1 := 0 SendData := SendData + 1 ' Rotate/fill second byte of array dataout[1] := SendData Repeat index1 from 0 to 15 ' Send 16-byte packet to PC serial[0].tx(dataout[index1])I noticed bit0 is 1/2 the total serial cycle rate, makes sense..
750 transitions times 2 bit states times 200 bits is 300kbps.
750 x 2 x 200 = 300000
I also set 2 stop bits for these screen shots to see if i could get more stable header.
115.2K
250K
500K
750K
1M
1.5M
2.0M Spin tops out at 2Mbit, (the serial port no longer slows spin down, its the other way around)
2.5M
DOSEN'T WORK. (bad header sync) Odd...
3.0M
I AM able to get 3MBit connection with sync. I wouldn't have sync if the data wasn't really 3mbit.
The serial loop rate isn't any faster at 3mbit because spin is doing the data send, and can't go faster.
I will need to do my data cycle and serial send in pasm. Hmm, yet another language..
Technically, i can code the vb to take any data rate and not even touch the propscope's code (until the vb interface is done), as long as i know how my data is organized ... this then just leaves the prop side to run the main propscope i/o (spin), package the a2d and chunk it out to the pc(pasm).
Verdict: VB is plenty fast. VB interface can be done. Spin propscope interface can be done.
No idea how to do: a2d pasm and serial data frame send/recieve pasm.
For the latest developments, I have investigated more.
I found that the sdxn136ps decoder model has a big issue with its transponding circuit or code, and its very bad.
All the best features of this decoder, transponding, ops mode readback, etc... are useless.
This is what is known as a true lemon, in the manufacturing world, since all 13 of my sdxn136ps decoders do this.
It affects the programming track also and will report its id as random ids that are in the system.
The transponder is normally only supposed to squak at the proper time, but the sdxn136ps decoders transponder will squack at random times, this causes devices like the bxp88 and the bld +rx4 to report incorrect locomotive id's in the zone that the sdxn136ps decoder is in.
I have multiple sdxn136ps decoders that all do this, personally i think its a bug in the design of it.
This is partly why i am trying to develop this tool, its hard to see what is going on, on the rail.
If I can't get these sdxn136ps decoders fixed, I am going to reverse engineer them, desolder all the parts, and make my own transponding sound decoder with the propeller chip and a micro sd card.
(i think i may just do that anyway, it would be awesome to have my own transponding sound decoder, and one that was open source for everyone too
Everyone already did the (deep code)sound work for the propeller, so i just need to bring it all together(multiple systems integration), and I am pretty good at that, i am not so good at pasm.
This shot shows the program jmri controlling my layout. The engine 3780 is located in zone8 and has a sdxn136ps decoder in it.
You can see the reports show that all 3 locomotives in zone 8, that is because of the sdxn136ps bug.
The locos in zone1 (333) and zone 4 (1412) are perfectly working dz123 non-sound decoders, they do transpond properly.
They are not making reports that are false.
Is this VB interface based on the "QuickStart Communicator" app I wrote back in 2010? Just curious...I don't see that app anywhere on here, but the interface looks familiar.