Steve, here's a question that came up: Since you proffered the idea of dragging "modules" onto pins, should the icons be proportional in size to the pins they use?
For instance, SPI uses 4 pins and I2C uses 2, so logically SPI would be twice the size of I2C.
Does this make sense? The icons would then represent the pin usage and the more complicated modules would get more real estate for labels.
It may be in the end that more complicated devices do need to be bigger. I'm not sure.
I was thinking that one could connect pins with "wires" on the canvas. Not sure if that's practical for programming, but it would be practical for use. Often we have shared pins like for I2C RTC and EEPROM. I have a board that has like 5 different devices sharing the I2C SCL pin.
The I2C case reminds me that there are many I2C devices. It makes sense that the icons should have the SCL/SDA pins. Similarly, SPI devices should probably have their pins labeled.
Propeller is flexible and the tool should be too.
One aspect of this whole idea is that someone might have devices that are not defined in a GUI. This requires a "body builder" and complicates things a little, but I think it should be available. Being able to select a basic design with background color and pins would be good. Also when an icon is not available yet, a text box could be used. Of course one would need to be able to at least import an image if not draw one in a device body builder. Interesting problem.
With I2C and SPI, they can be "subclassed" for peripherals. You connect the I2C driver to the chip pins, then connect the devices to the I2C driver. In the software it is likely this is how it would be implemented too.
With I2C and SPI, they can be "subclassed" for peripherals. You connect the I2C driver to the chip pins, then connect the devices to the I2C driver. In the software it is likely this is how it would be implemented too.
Maybe we can have some interface "cradles" which would have pins and names on them. Then one could drop in a picture of the device function.
BOE and RST don't have any software interface, so I don't think they are needed. A crystal shouldn't be hard to come up with.
I've used both BOE* and RST* for chaining propellers together. BOE* is just a pullup or pulldown depending on need.
Generally speaking though, you're right, they have no "software" function. I do wonder about what the RST* description in the data sheet really means sometimes.
Nice work guys! I'm working on "transport" right now. Not sure if these will help. They are B/W for color-masking with the SSD1289 LCD's WriteMask. Hopefully the new displays will ACTUALLY work!
Here's what I have so far. I plan on taking separating the buttons and removing the 1 pixel, corner locates, eventually.
They are 240 x 40, B/W 24-bit BMP. Let me know if these are even close!
Nice work guys! I'm working on "transport" right now. Not sure if these will help. They are B/W for color-masking with the SSD1289 LCD's WriteMask. Hopefully the new displays will ACTUALLY work!
Here's what I have so far. I plan on taking separating the buttons and removing the 1 pixel, corner locates, eventually.
They are 240 x 40, B/W 24-bit BMP. Let me know if these are even close!
Comments
It may be in the end that more complicated devices do need to be bigger. I'm not sure.
I was thinking that one could connect pins with "wires" on the canvas. Not sure if that's practical for programming, but it would be practical for use. Often we have shared pins like for I2C RTC and EEPROM. I have a board that has like 5 different devices sharing the I2C SCL pin.
The I2C case reminds me that there are many I2C devices. It makes sense that the icons should have the SCL/SDA pins. Similarly, SPI devices should probably have their pins labeled.
Propeller is flexible and the tool should be too.
One aspect of this whole idea is that someone might have devices that are not defined in a GUI. This requires a "body builder" and complicates things a little, but I think it should be available. Being able to select a basic design with background color and pins would be good. Also when an icon is not available yet, a text box could be used. Of course one would need to be able to at least import an image if not draw one in a device body builder. Interesting problem.
Maybe we can have some interface "cradles" which would have pins and names on them. Then one could drop in a picture of the device function.
I am visualizing a ball and socket type joint, open socket cradle, socket pin fits in.
Can you make something nice out of this attachment to go with the other icons.
You could probably connect devices to something like it with "pipes".
BTW, we need a crystal with a frequency and PLLx factor. Not sure what to do with BOE* and RST*.
I've used both BOE* and RST* for chaining propellers together. BOE* is just a pullup or pulldown depending on need.
Generally speaking though, you're right, they have no "software" function. I do wonder about what the RST* description in the data sheet really means sometimes.
Here's what I have so far. I plan on taking separating the buttons and removing the 1 pixel, corner locates, eventually.
They are 240 x 40, B/W 24-bit BMP. Let me know if these are even close!
Oops, you posted to the wrong thread.
Joe, they are good icons. My thread is poorly titled though.
I'm looking for illustrations that can be used to represent hardware device concepts like, for example: serial port, PWM, RTC, or even a Midi port.
Of course for every icon, we will need software that implements it. Maybe a midi port icon + Ariba's code is around the corner.
It has also become clear to me that we should also be able to make device icons so that something like an LCD display device is possible too.
Someone had suggested Fritzing, but that is waaaaaaaaay too much for what i'm interested doing with this.
Thanks,
--Steve