So yeah this will be tough for me but some of you might know. I anticipate being pretty darn stuck on this without knowing the terminology of this or without any explanation.
They take the data structure from the post 2 above this one - struct VesselData
There are 2 main operations they're doing that I don't know how to do in SPIN:
uint16_t * address;
VesselData VData;
byte buffer[256];
address = (uint16_t*)&VData; 'VData is the VesselData struct, or a variable using that struct, or something like that
memcpy(address,buffer,structSize); 'so here if all the checksums etc add up it stores the data
I've never multiplexed before so I don't know exactly what I'm going to use.
I figure I'll be using around say 50 switches and 25 LEDs. I've yet to lay out all the functions since I still don't know if I can get the Prop to even interface.
However getting that data packet is a good sign!!!
50 switches and 25 individual leds is not too bad. I also saw quite a few 7 segment led digits in the video. Each digit should be counted as 8 individual leds for multiplexing.
Ah in that case a lot more LEDs. Hadn't thought of that.
Right now my main problem is figuring out the Floats, and the porting 2 posts up.
Sorry, can't help much with the floats and porting since I have used spin and pasm for everything so far. OTOH a couple of projects have involved reading a large number of switches and outputs to a large number of leds.
How do you handle the LEDs, and particularly the 7 segment displays? I'm currently writing this in SPIN but if I can't get around the Float etc issues I might have to switch to C.
As it happens I buzzed them to obtain a demo. Its installed and I even tried it out today. (Early) I registered for their forum and promptly posted a question in their version of the general portion of the huge forum. It concerns the idea regarding the demo supporting the same plugins that we are curious about here.
I also referred to you, Keith, but not by name, and of course I did not name the platform that you're concerned with. I figured that their general one did not need to know what we are up to.
I figured that after their moderator kerbals accept my post and I get a response, I'll then explain further.
I'm still stuck on this issue of porting these couple of things to SPIN. I'm about to start doing this in C in the meantime and hope someone smarter than me chimes in about the floats, structs, pointers, bitwise and on it, and memcpy.
I don't know why but my gut is telling me this will be better if it can work with SPIN. Part of the reason is the OBEX for any hardware we want to add. For example my Logitech 3D Pro Driver is in SPIN, as are OLED and all that.
As for your plugin, just try putting it in the correct folder and see if it works. It's as easy as unzipping a folder and plopping it in the GameData folder.
If it's working, just when you launch a rocket at the bottom right it should say something about a Display being found or not, or a COM port. Without the plugin that text is not visible to the bottom right.
If the OBEX code is mostly a PASM driver wrapped in a Spin interface, those usually aren't too terrible to move to C as a PASM driver with a C wrapper. If there is significant SPIN logic, then it gets harder to move to C.
This looks like a really cool project and I'm going to stay far, far away because it looks like a GIANT bright shiny thing to distract me.....ooooh, lights and buttons and a simulation????
Makes sense.
I figure I'll follow the plugin writer guidelines for building a demo and seeing what happens. We built a contraption nicknamed by the designers as "Little Joe II", it was a single stage wearing either a Mercury capsule or an Apollo one. The launcher was used by our program to test the escape methods that both shared.
As it happens the escape methods were never used, at least with people on board. They used towers to pull the capsule to safety.
I believe we used the same methods to test the escape methods for the current inheritor for the Apollo program.
Can that be done with SimpleIDE mindrobots? Or do you need special PropGcc Command Line etc stuff to do it?
Even if you're avoiding this like the plague, do you know anything about the problems such as the top post of this page? I really don't know how to get around that struct, pointer, memcpy, etc.
I've just started porting to C in case no one knows how to fix those couple issues.
And I've discovered that the community next door in KSP-land is even stranger then here. One posting and multiple responses. Naturally my replies are moderated, at the moment, but it seems to be a fast turnaround.
They think that plugin support is turned-off for the demo. I'm contending that the only thing different between a demo and the full featured one may be the ability to save multiple objects say, otherwise why wouldn't deliver that empty folder.
They also confused plugins with mods. Those are two completely different things.
How do you handle the LEDs, and particularly the 7 segment displays? I'm currently writing this in SPIN but if I can't get around the Float etc issues I might have to switch to C.
Typically I control individual leds as part of an 8 x 8 array, and a 7 segment displays as one row of 8 leds in the 8 x 8 array. The data for this is stored as an array of 8 bytes in hub. Each byte controls eight leds or seven segments and a decimal point. A single cog can run several of these 8 x 8 modules and by adding a '165 and some diodes you can read back up to 64 switches.
I suppose something similar could be done with a small microcontroller, but since I needed the drivers for the leds in any case I found using the TPIC's, '595's, and '165's worked just as well.
How well this approach would fit with what you are doing would depend on the number of control panels you need and the number of leds, 7 segment displays, and switches you need on each panel.
The code in the cog that sends out the data in the array is pasm, and the code that sets the bits in the byte array is spin. A fairly typical object with PUB's for the various functions.
The difference between 189 and 192 may be the 3 padding bytes after the "id" byte in the struct. Everything else in the struct is aligned correctly, and doesn't require extra padding bytes. You can put the id byte in buffer[0], and then read the remaining 188 bytes into buffer starting at buffer[3]. You would then do a memcpy of 192 bytes from buffer to the struct.
Cool thanks Kwinn. Hopefully someone knows how to solve those float pointer memcpy struct issues so I can use SPIN for this project.
Where can I find your code?
I have the code at home. The root code is an object for an 8 x 8 array of leds and reading an 8 x 8 array of switches. I will post it in this thread when I get home. Not sure when that will be. I am on an install that is not going well.
Do you think the Prop is the right way to handle this? I will be needing a way to effectively get more IO. I think the Prop is right for this.
What language should I use? I think I should use SPIN, assuming I do use the Prop.
You can add a lot of simple IO using by sharing the I2C pins of the EEPROM.
I use Spin, so this may not be very helpful... but here goes. I wrote a WAV file driver some time ago. The WAV header is 44 bytes with mixed sized values inside. After reading the 44-byte header from the file I use bytemove, wordmove, and longmove to extract specifics from the header.
pub get_header(p_filename) | check
'' Opens file at p_filename, moves header (44 bytes) into local buffer
ifnot (mounted)
check := mount_sd
if (check <> OK)
sd.pclose
return NO_MOUNT
bytefill(@header, 0, 44) ' empty buffer
check := \sd.popen(p_filename, "r")
if (check <> OK)
\sd.pclose
return NO_FILE
check := \sd.pread(@header, 44) ' get header bytes
if (check <> 44)
sd.pclose
return BAD_HDR
return OK
pub format | fmt
'' Returns format of WAV file
fmt := 0
wordmove(@fmt, @header[20], 1)
return fmt
pub channels | ch
'' Returns channels in WAV file
ch := 0
wordmove(@ch, @header[22], 1)
return ch
pub sample_rate
'' Returns sample rate (Hz) of WAV file
'' -- uses last opened file
longmove(@filerate, @header[24], 1)
return filerate
pub bits_per_sample | bits
'' Returns bits per sample of WAV file
bits := 0
wordmove(@bits, @header[34], 1)
return bits
pub samples | balign, chunk2
'' Returns samples in WAV file (chunk2)
balign := 0
wordmove(@balign, @header[32], 1) ' block align (bytes per sample)
longmove(@chunk2, @header[40], 1) ' bytes in chunk2 (audio)
return chunk2 / balign
pub audio_bytes | chunk2
longmove(@chunk2, @header[40], 1) ' bytes in chunk2 (audio)
return chunk2
You can use "__attribute__((__packed__))" when defining the stuct to remove the padding, but I wouldn't recommend doing that. Just read the 189 bytes into buffer, and then copy it to the struct as follows:
Or you can do what I suggested in my previous comment and read the first byte into buffer[0] and the remaining bytes starting at buffer[3]. If you do it that way you would copy the buffer to the struct by doing
Will keep you up to date with the design, and hopefully the build will start in January (unless I find out I can deduct the expenses next year since this won't be in use until March or who knows when, in which case I can start building sooner).
Comments
They take the data structure from the post 2 above this one - struct VesselData
There are 2 main operations they're doing that I don't know how to do in SPIN:
Any help will be much appreciated!!!
50 switches and 25 individual leds is not too bad. I also saw quite a few 7 segment led digits in the video. Each digit should be counted as 8 individual leds for multiplexing.
Right now my main problem is figuring out the Floats, and the porting 2 posts up.
Sorry, can't help much with the floats and porting since I have used spin and pasm for everything so far. OTOH a couple of projects have involved reading a large number of switches and outputs to a large number of leds.
I also referred to you, Keith, but not by name, and of course I did not name the platform that you're concerned with. I figured that their general one did not need to know what we are up to.
I figured that after their moderator kerbals accept my post and I get a response, I'll then explain further.
I'm still stuck on this issue of porting these couple of things to SPIN. I'm about to start doing this in C in the meantime and hope someone smarter than me chimes in about the floats, structs, pointers, bitwise and on it, and memcpy.
I don't know why but my gut is telling me this will be better if it can work with SPIN. Part of the reason is the OBEX for any hardware we want to add. For example my Logitech 3D Pro Driver is in SPIN, as are OLED and all that.
As for your plugin, just try putting it in the correct folder and see if it works. It's as easy as unzipping a folder and plopping it in the GameData folder.
If it's working, just when you launch a rocket at the bottom right it should say something about a Display being found or not, or a COM port. Without the plugin that text is not visible to the bottom right.
This looks like a really cool project and I'm going to stay far, far away because it looks like a GIANT bright shiny thing to distract me.....ooooh, lights and buttons and a simulation????
I figure I'll follow the plugin writer guidelines for building a demo and seeing what happens. We built a contraption nicknamed by the designers as "Little Joe II", it was a single stage wearing either a Mercury capsule or an Apollo one. The launcher was used by our program to test the escape methods that both shared.
As it happens the escape methods were never used, at least with people on board. They used towers to pull the capsule to safety.
I believe we used the same methods to test the escape methods for the current inheritor for the Apollo program.
Even if you're avoiding this like the plague, do you know anything about the problems such as the top post of this page? I really don't know how to get around that struct, pointer, memcpy, etc.
I've just started porting to C in case no one knows how to fix those couple issues.
Wow.
So far getting this in SimpleIDE is going smoothly.
And I've discovered that the community next door in KSP-land is even stranger then here. One posting and multiple responses. Naturally my replies are moderated, at the moment, but it seems to be a fast turnaround.
They think that plugin support is turned-off for the demo. I'm contending that the only thing different between a demo and the full featured one may be the ability to save multiple objects say, otherwise why wouldn't deliver that empty folder.
They also confused plugins with mods. Those are two completely different things.
Getting this in to SimpleIDE is fairly smooth so far.
Still hoping someone knows how to fix the float struct pointer memcpy issues porting to SPIN I mentioned above.
Basically what seems to be happening is that by the time KSP blaps out the handshake the Prop hasn't been able to fdserial_open and then rx yet.
This is happening even if I change the order of operations and try to do these things first.
Typically I control individual leds as part of an 8 x 8 array, and a 7 segment displays as one row of 8 leds in the 8 x 8 array. The data for this is stored as an array of 8 bytes in hub. Each byte controls eight leds or seven segments and a decimal point. A single cog can run several of these 8 x 8 modules and by adding a '165 and some diodes you can read back up to 64 switches.
I suppose something similar could be done with a small microcontroller, but since I needed the drivers for the leds in any case I found using the TPIC's, '595's, and '165's worked just as well.
How well this approach would fit with what you are doing would depend on the number of control panels you need and the number of leds, 7 segment displays, and switches you need on each panel.
There's a delay setting in the config file for the plugin that should give it more time.
On top of this when I try
fdserial_txChar(comms, 0xBE) for example I can't get it to send the Hex BE.
It won't even work in Parallax Serial Terminal. Sometimes I can get it to send a symbol which I think is 3/4.
I can't find a way yet to send 0xBE. Also, termios.h doesn't work when I try to include it and just make this work on my own.
So I'm currently stuck in both SPIN and C.
The code in the cog that sends out the data in the array is pasm, and the code that sets the bits in the byte array is spin. A fairly typical object with PUB's for the various functions.
Where can I find your code?
So for example the code sending the data says the size is 189.
My code says the size is 192.
Now one thing happening is the module (written in C#) is sending 3 BYTES.
C and C++ don't have bytes, so I've been trying char unsigned char and uint8_t.
It's almost there is a padding issue or something. Unfortunately the size of data has to match correctly since memcpy is used in the program.
Do any of you know how to fix this? It's in VesselData - VData struct.
I have the code at home. The root code is an object for an 8 x 8 array of leds and reading an 8 x 8 array of switches. I will post it in this thread when I get home. Not sure when that will be. I am on an install that is not going well.
It's currently set to -std=c99
Is there something I can change here to get rid of padding?
My computer is telling me it is sending 189 bytes, while when looking at the same struct SimpleIDE/Prop is telling me the struct is 192 bytes.
There are 3 instances where I'm being sent byte types, which SimpleIDE/Prop doesn't recognize so instead I'm using unsigned char.
Could padding be the issue, and if so, is there a way to get rid of it in SimpleIDE?
You can add a lot of simple IO using by sharing the I2C pins of the EEPROM.
I use Spin, so this may not be very helpful... but here goes. I wrote a WAV file driver some time ago. The WAV header is 44 bytes with mixed sized values inside. After reading the 44-byte header from the file I use bytemove, wordmove, and longmove to extract specifics from the header.
pub get_header(p_filename) | check '' Opens file at p_filename, moves header (44 bytes) into local buffer ifnot (mounted) check := mount_sd if (check <> OK) sd.pclose return NO_MOUNT bytefill(@header, 0, 44) ' empty buffer check := \sd.popen(p_filename, "r") if (check <> OK) \sd.pclose return NO_FILE check := \sd.pread(@header, 44) ' get header bytes if (check <> 44) sd.pclose return BAD_HDR return OK pub format | fmt '' Returns format of WAV file fmt := 0 wordmove(@fmt, @header[20], 1) return fmt pub channels | ch '' Returns channels in WAV file ch := 0 wordmove(@ch, @header[22], 1) return ch pub sample_rate '' Returns sample rate (Hz) of WAV file '' -- uses last opened file longmove(@filerate, @header[24], 1) return filerate pub bits_per_sample | bits '' Returns bits per sample of WAV file bits := 0 wordmove(@bits, @header[34], 1) return bits pub samples | balign, chunk2 '' Returns samples in WAV file (chunk2) balign := 0 wordmove(@balign, @header[32], 1) ' block align (bytes per sample) longmove(@chunk2, @header[40], 1) ' bytes in chunk2 (audio) return chunk2 / balign pub audio_bytes | chunk2 longmove(@chunk2, @header[40], 1) ' bytes in chunk2 (audio) return chunk2You just got me thinking of all the possibilities of that.
VData.id = buffer[0]; memcpy(&VData.AP, &buffer[1], 188);Or you can do what I suggested in my previous comment and read the first byte into buffer[0] and the remaining bytes starting at buffer[3]. If you do it that way you would copy the buffer to the struct by doing Either way should work fine.
Couldn't have done it without you guys!
Will keep you up to date with the design, and hopefully the build will start in January (unless I find out I can deduct the expenses next year since this won't be in use until March or who knows when, in which case I can start building sooner).