@those trying to understand cost -- Also, we haven't even begun to talk about distribution. Distributors want a 30-50% margin, so that means in many cases we sell a product for NOTHING to the distributor and THEY make all the money. At the end of the day many times 90% of products sales are thru distro's and 10% from website sales, so they make a 40% margin and we make a 5% margin on 90% of sales volume.
So, to put further reality on it, say we have a final unit cost of $40 @1000 units, we want to retail it at $80. 40% off that is $48, so we sell it to the distro art $48, he makes $32/unit, we make $8. And this is just the COGs (cost of goods), I haven't even factored in the development, sales, marketing costs and ammortize them over the products cost. So, that $8 is really more like $3-4 net. So, we break even at 10-20K units
This is why SOFTWARE is so attractive as a business, a 10 cent CD/DVD for $50-100, that's a profit margin that's unheard of. People that develop and manufacture embedded systems especially like we do for education are crazy, since we sure aren't getting rich that much is for certain
The moral of the story is anyone that really wants a taste of manufacturing, go out build a product, keep track of your time and expenses, then build 100 - 1000 of them which will require a debt finance on your part for the stock and or a huge amount of labor if you build them yourself. Then go try to sell them, again keep track of your time and money doing that, then when your shelf is empty, do a final computation of your total net profit versus, and total expenditures and time over the complete cycle of the product, and see if you made or lost money.
In most cases you will have lost money or made a tiny bit, thus the only way to make of "biz" is to have 100-200 products and make a couple bucks on each. Or to sell 1000's of a single product per month. And embedded systems for the education sector tend to sell dozens to 100's a month at most. 100's a month is a "best seller" basically. Far and few between.
Anyway, hopefully this and the other posts by Ken are enough "biz dev" for everyone and we can back to technical discussions about the C3
The distributor margin issue is tough for me - A product could sell for much less direct, but then I wouldn't be able to sell enough to make it worthwhile (or even break even). There are easier ways to make money, but I love the hobby and love getting people excited about electronics.
Anyway - back to the C3; Product looks awesome! One question, just curious - is the board 2 layer or 4?
The board is 2 layer, but it was a nasty route with only 2 layers, like playing chess, since this board is so small and tight. I always like to let the autorouter give it a try, I have the very expensive electra router, what a mess it turned it into. But, I am very happy with the routing and PCB, its solid ground filled as well on both sides, and a very "flat" layout.
One of my techniques I use to route is to make screen captures of the board as I design, then pull them into photoshop then on other layers try "drawing" the traces, so I can create a number of traces and see "patterns" emerge without disturbing my design, then I take those ideas and alt-tab and implement them.
I just did a 6 layer GHZ board for a new medical imaging device I have been working on. That was very challenging in 4 layers, impossible in 2, nice in 6.
With the C3, I was more or less at the limit of 2 layers, anything more and you would definitely want to go to 4 layers. Also, the SMT stuff just kills you these days when it comes to routing, thru hole is so nice since you are on all layers for every signal, but I HATE punching vias down to get signals thru things, its so ghetto And don't get me started on BGAs, hate them -- ugly packages, I would prefer QFPs any day, by the time you get all the BGA signals exited, things look so ugly and you are on so many layers.
Since the C3 has 1MB SPI Flash, and (2)32Kx8 SPI SRAMS, how do you make use of this? You are going to have drivers that automatically handle the extra ram? Or do you have something else in mind. Of course there is always the possibility that their will be be new version of Spin that will have XMM. If it is a driver, then the object gets stored somewhere, and a couple lines of code in your main program activates the driver, is this a correct description of what you have in mind?
There is a driver in the OBEX for both Winbond flash and SPI SRAM memories. It needs to be modified to work with the C3's chip select circuitry, but this has already been done and Andre' has a modified version on his C3 developer's website that should be distributed with the C3 software. The C3 version is used exactly the same as the non-C3 version, so look at what's in the OBEX for details.
I have written examples in SPIN to talk to everything. Other than that, its up to you to do what you will with it, no need in trying to "guess" what people want to do. For example, here's the code to access the SPI RAMs, its all very clear, not in ASM, and designed to be easy to understand, most functions are 5-10 lines of code with 50 lines of comments!
PUB SRAM_Init ( ... ) - initializes the SRAMs and sets them to sequential mode.
PUB SRAM_Write( ... ) - writes bytes of data from a buffer to either SRAM.
PUB SRAM_Fill( ... ) - fills either SRAM with a constant value.
PUB SRAM_Read( ... ) - reads data from either SRAM into a buffer.
PUB SRAM64K_MREAD( ... ) - models the pair of 32K SRAMs as a single memory of 64K and reads a byte from it.
PUB SRAM64K_MWRITE( ... ) - models the pair of 32K SRAMs as a single memory of 64K and writes a single byte to it.
' /////////////////////////////////////////////////////////////////////////////
' SRAM API ////////////////////////////////////////////////////////////////////
' /////////////////////////////////////////////////////////////////////////////
PUB SRAM_Init ( mode ) | _spi_word
{{
This function initializes both banks of the Microchip 23K256 SRAMs
serial SPI SRAMs'. The initialization simply sets the STATUS register
of each SRAM into "byte", "page" or "sequential" read/write mode to allow more
efficient access of the SRAMs. The SRAM API currently relies on "sequential"
mode, so if yoo want to use them, this function should be called with SPI_MODE_SEQUENTIAL
The 23K256 supports a number of commands, we have
only implemented a couple here in these API functions (single byte read/write,
multiple byte read/write). However, there are many others you can implement, find
out more by reviewing the chip specs and data sheets found here:
[url]http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en539039[/url]
[url]http://ww1.microchip.com/downloads/en/DeviceDoc/22100E.pdf[/url]
PARMS: mode - %00_00000_1 = SPI_MODE_BYTE
%10_00000_1 = SPI_MODE_PAGE
%01_00000_1 = SPI_MODE_SEQUENTIAL
RETURNS: Nothing.
}}
' first set SRAM bank 0 to sequential access mode (see page 6 of data sheet)
SPI_Select_Channel( SPI_CHAN_SRAM0 )
' write status register command "sequential access mode" along with disable "HOLD" to setup SRAM for sequential reading/writing
SPI_Write_Read( 16, %0000000_1 << 8 | mode , $FF )
' now select SRAM bank 1
SPI_Select_Channel( SPI_CHAN_SRAM1 )
' write status register command "sequential access mode" along with disable "HOLD" to setup SRAM for sequential reading/writing
SPI_Write_Read( 16, %0000000_1 << 8 | mode , $FF )
' and finally de-select all SPI devices
SPI_Select_Channel( 0 )
' end SRAM_Init
' /////////////////////////////////////////////////////////////////////////////
PUB SRAM_Write( bank, addr, num_bytes, src_buffer_ptr) | _index, _data, _spi_word
{{
This function writes a number of bytes to either bank of the Microchip 23K256
serial SPI SRAMs' from a buffer. The 23K256 supports a number of commands, we have
only implemented a couple here in these API functions (single byte read/write,
multiple byte read/write). However, there are many others you can implement, find
out more by reviewing the chip specs and data sheets found here:
[url]http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en539039[/url]
[url]http://ww1.microchip.com/downloads/en/DeviceDoc/22100E.pdf[/url]
PARMS: bank - [0,1] the SRAM bank to write to, there are two banks, each holds 32K bytes
addr - address in SRAM to write to [0...32767]
num_bytes - number of bytes to write from source buffer to SRAM
src_buffer_ptr - pointer to the buffer of bytes to write to SRAM
RETURNS: number of bytes written
}}
' test if there is anything to write?
if (num_bytes => 1)
' select SPI channel for requested SRAM bank
SPI_Select_Channel( SPI_CHAN_SRAM0 + bank )
' set instruction word ( write sequential byte:8 | address:16 )
_spi_word := (%00000010 << 16) + (addr)
' and now send command to SRAM for sequential writing
SPI_Write_Read( 24, _spi_word, $FF )
' write the bytes into the SRAM
repeat _index from 0 to num_bytes-1
' get byte to write
_data := byte[ src_buffer_ptr][ _index ]
' write the byte
SPI_Write_Read( 8, _data, $FF )
' de-select SRAM SPI channel
SPI_Select_Channel( 0 )
' return bytes written
return( num_bytes )
else
' catch error
return 0
' end SRAM_Write
' /////////////////////////////////////////////////////////////////////////////
PUB SRAM_Fill( bank, addr, num_bytes, value) | _index, _data, _spi_word
{{
This function writes a constant value to either bank of the Microchip 23K256
serial SPI SRAMs' from a buffer. The 23K256 supports a number of commands, we have
only implemented a couple here in these API functions (single byte read/write,
multiple byte read/write). However, there are many others you can implement, find
out more by reviewing the chip specs and data sheets found here:
[url]http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en539039[/url]
[url]http://ww1.microchip.com/downloads/en/DeviceDoc/22100E.pdf[/url]
PARMS: bank - [0,1] the SRAM bank to write to, there are two banks, each holds 32K bytes
addr - address in SRAM to write to [0...32767]
num_bytes - number of bytes to write from source buffer to SRAM
value - byte value to write to SRAM
RETURNS: number of bytes written
}}
' test if there is anything to fill?
if (num_bytes => 1)
' select SPI channel for requested SRAM bank
SPI_Select_Channel( SPI_CHAN_SRAM0 + bank )
' set instruction word ( write byte sequential:8 | address:16 )
_spi_word := (%00000010 << 16) + (addr)
' setup for sequential byte write, this includes the command and address only
SPI_Write_Read( 24, _spi_word, $FF )
' now the chip is ready to receive bytes (as many as we want to send)
repeat _index from 0 to num_bytes-1
SPI_Write_Read( 8, value, $FF )
' de-select SRAM channel
SPI_Select_Channel( 0 )
' return bytes written
return( num_bytes )
else
' catch error
return 0
' end SRAM_Fill
' /////////////////////////////////////////////////////////////////////////////
PUB SRAM_Read(bank, addr, num_bytes, dest_buffer_ptr) | _index, _data, _spi_word
{{
This function reads a number of bytes from either bank of the SRAM into a buffer.
The 23K256 supports a number of commands, we have only implemented a couple here
in these API functions (single byte read/write, multiple byte read/write).
However, there are many others you can implement, find out more by reviewing
the chip specs and data sheets found here:
[url]http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en539039[/url]
[url]http://ww1.microchip.com/downloads/en/DeviceDoc/22100E.pdf[/url]
PARMS: bank - [0,1] the SRAM bank to read from, there are two banks, each holds 32K bytes
addr - address in SRAM to read from [0..32767]
num_bytes - number of bytes to read from SRAM into destination buffer
dest_buffer_ptr - pointer to the buffer of bytes to read SRAM into
RETURNS: number of bytes read
}}
' test for anything to read?
if (num_bytes => 1)
' select SPI channel for requested SRAM bank
SPI_Select_Channel( SPI_CHAN_SRAM0 + bank )
' set instruction word ( read byte sequential:8 | address:16 )
_spi_word := (%00000011 << 16) + (addr)
' setup for sequential byte read, this includes the command and address only
SPI_Write_Read( 24, _spi_word, $FF )
' now the chip is ready to be read from
repeat _index from 0 to num_bytes-1
' read next byte from SRAM into receiving buffer
byte [dest_buffer_ptr][_index] := SPI_Write_Read( 8, $00, $FF )
' de-select SRAM channel
SPI_Select_Channel( 0 )
' return bytes read
return( num_bytes )
else
' catch error
return 0
' end SRAM_Read
' /////////////////////////////////////////////////////////////////////////////
PUB SRAM64K_MREAD( addr ) | _spi_word, _data
{{
This function reads a single byte from either bank of the Microchip 23K256
serial SPI SRAMs'. This function is different from the SRAM_Read function
in that it accesses the two banks of SRAM as a contiguous region of 64K bytes
for you, and thus can be though of as a crude "array" access macro, rather
than a function. Ultimately, this should be converted to ASM along with
all the other important peripheral access methods.
The 23K256 supports a number of commands, we have
only implemented a couple here in these API functions (single byte read/write,
multiple byte read/write). However, there are many others you can implement, find
out more by reviewing the chip specs and data sheets found here:
[url]http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en539039[/url]
[url]http://ww1.microchip.com/downloads/en/DeviceDoc/22100E.pdf[/url]
PARMS: addr - address in SRAMs to write to [0...65535].
RETURNS: The 8-bit data from the SRAM.
}}
' the only tricky thing here is we need to take an address 0..65535 and then
' decide which bank it refers to and which byte in that bank, basically, some
' bit masking and shifts to accomplish this
' select SPI channel for requested SRAM bank
SPI_Select_Channel( SPI_CHAN_SRAM0 + (addr >> 15) )
' set instruction word ( read byte sequential:8 | address:16 | dummy:8 )
_spi_word := (%00000011 << 24) + (addr << 8) + 0
' read the byte of data
_data := SPI_Write_Read( 32, _spi_word, $FF )
' de-select SRAM SPI channel
SPI_Select_Channel( 0 )
' return data
return ( _data )
' end SRAM64K_READ
' /////////////////////////////////////////////////////////////////////////////
PUB SRAM64K_MWRITE( addr, data ) | _spi_word
{{
This function writes a single byte to either bank of the Microchip 23K256
serial SPI SRAMs'. This function is different from the SRAM_Write|Fill functions
in that it accesses the two banks of SRAM as a contiguous region of 64K bytes
for you, and thus can be though of as a crude "array" access macro, rather
than a function. Ultimately, this should be converted to ASM along with
all the other important peripheral access methods.
The 23K256 supports a number of commands, we have
only implemented a couple here in these API functions (single byte read/write,
multiple byte read/write). However, there are many others you can implement, find
out more by reviewing the chip specs and data sheets found here:
[url]http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en539039[/url]
[url]http://ww1.microchip.com/downloads/en/DeviceDoc/22100E.pdf[/url]
PARMS: addr - address in SRAMs to write to [0...65535].
data - the byte to write.
RETURNS: Nothing.
}}
' the only tricky thing here is we need to take an address 0..65535 and then
' decide which bank it refers to and which byte in that bank, basically, some
' bit masking and shifts to accomplish this
' select SPI channel for requested SRAM bank
SPI_Select_Channel( SPI_CHAN_SRAM0 + (addr >> 15) )
' set instruction word ( write sequential byte:8 | address:16 | data: 8)
_spi_word := (%00000010 << 24) + ( (addr & $7FFF) << 8) + data
' write the byte of data
SPI_Write_Read( 32, _spi_word, $FF )
' de-select SRAM SPI channel
SPI_Select_Channel( 0 )
' end SRAM64K_WRITE
Cole,
You get yourself a soldering iron and some very fine gauge lead-free solder at RadioShack and keep it at home (dorm or whatever). RadioShack even has some battery powered little soldering irons for doing small field repairs that would be adequate for a couple of connections like what I'm suggesting. Basic tools would include a small pair of wire cutters and needle nosed pliers.
I guess I didn't make myself clear enough. I'm at Job training for the Army. And its up to my commander what electronics I could have. I figured I could get away with a pre-made product but not sure if they would allow me to have a soldering Iron. I got plenty of equipment at home and several boards but there back in Ohio and I'm in Georga. Though I might ask my Sargent if I could have a soldering Iron.
Do you have any Ideas for a pre-assambled product that would have atleast an RCA out and hopefully under $100.
Not sure of what boards you have home, but I would spring for a Professional Development Board, now that you can get them for $99.99. OK, you have to get a Propeller chip too for $7.99. And it's got RCA, VGA, PS/2, RS232......
I guess I didn't make myself clear enough. I'm at Job training for the Army. And its up to my commander what electronics I could have. I figured I could get away with a pre-made product but not sure if they would allow me to have a soldering Iron. I got plenty of equipment at home and several boards but there back in Ohio and I'm in Georga. Though I might ask my Sargent if I could have a soldering Iron.
Do you have any Ideas for a pre-assambled product that would have atleast an RCA out and hopefully under $100.
I didn't realized that the you could get the PPDB for under $100. I been wanting to add one of these to prop family. I'll have to order one next friday when I get paid.
Thanks, just working on the manual now, I think I like the outline, so I am going to blast it out -- here is the outline, subject to change of course, as I write I change my mind, but this is the gist of it:
Manual
I. Quickstart (3)
II. Hardware Overview. (1)
- Power Management (3.3, 5V ) (2)
- Propeller Processor (reset + eeprom) (2)
- SPI Bus System (5)
- Serial Communications (2)
- Composite Video (2)
- VGA Video (+buffer) (2)
- Audio System (2)
- PS/2 Keyboard/Mouse Port (1)
- General IO Ports (2)
- FLASH Memory System (2)
- 32Kx2 SRAM Design (2)
- A/D System (2)
- Secure Digital (SD) Card Interface (1)
III. Demos and API (10)
LOCAL VERSION DEMOS PS/2 + NTSC monitor
for each: Overview, Pic, files, output
1. Keyboard test. (1)
2. Mouse test. (1)
3. VGA test. (1)
4. Servo port test. (1)
5. Analog to digital test. (1)
6. SRAM test. (1)
7. NES game pad test. (1)
8. Port A/B test. (1)
9. FLASH memory test. (1)
10. Audio test. (1)
11. SD card test. (1)
SERIAL VERSION DEMOS OVER UART
for each: Overview, Pic, files, output
1. Servo port test. (1)
2. Analog to digital test. (1)
3. SRAM test. (1)
4. AD + SRAM test. (1)
5. NES game pad test. (1)
6. Port A/B test. (1)
7. FLASH memory test. (1)
API Objects???
IV. Porting Applications from other Boards to C3 (3)
- Demo Board
- HYDRA
- Samples
Appendix
I. Schematic
II. Close up of PCB
This device is opening up a lot of possibilities that before, would have been hard to overcome... It's got VGA, SD and keyboards. Plus, the additional RAM and FLASH are very useful. Finally, a SBC with some power is being unleashed on the hobbyist market...I just can't wait to try one of these out. Oh, one more question. Roughly what kind of speed do you think that we can squeeze out of the SRAM?
Look at the VMCOG thread about the memory manager written by Bill Henning. There are some speed tests using this same kind of SRAM.
This is a serial SRAM and, even though it's fast, access, particularly random access, has a lot of overhead. Block reads and writes are relatively fast since a byte is transferred in 8 clock cycles and the several bytes of overhead are amortized over the whole block transfer.
It STANDARDIZES a bunch of the existing technologies which are used in various Propeller projects! I always figured that Dad (Chip) would have step in and do this, but Uncle Andre' stepped to solve the problem! <SMIRK>
Without having to fiddle with creating a dozen different designs to play with the exciting variations of cutting edge Propeller technology we can concentrate on pushing the envelope even further!!!
THANK YOU ANDRE! THANK YOU THANK YOU THANK YOU THANK YOU
THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU
THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU
THANK YOU THANK YOU THANK YOU
Thanks -- and this was the idea. I wanted to create a "platform" that people can use and build things with. Sure, there are better SRAMs setups, sure there are better graphics setups, sure there are better IO setups, etc. But, this is the best intersection of all possible users and optimizing all these variables at once that I could think of, so I think it will be a really good platform to build in the field applications with which is the idea.
I guess 10Mb's a second is pretty good. I am guessing random byte read and writes are gonna be pretty slow(still not as bad as a EEPROM).....can't wait!!
I would have put two PS ports on there if there was room. But, very few people actually use keyboard and mouse applications, so it wasn't a deal breaker, not to mention there was barely any room at all. But, that said, if you do need another PS port, you can always add one on the prototype shield port that piggy backs onto the C3 that I just sent to manufacturing. Attached is an image of it, so you can take a look. And you should be able to see the pin out of all the headers as well -- on the 2x16 header the left column is p23...p0, the right column is PS2, UART, power, reset, SPI bus, I2C, gnd.
P23...P16 is shared with the VGA port, but you can disconnect the VGA header from the IOs with a flip of a port IO bit.
Lastly, the analog port header top to bottom, analog in 0, 1, 5V, and gnd. Finally, to the left you see once again the "servo" ports these are heavily bypassed IO ports that can power a standard parallax servo, they share pins p7..p4.
And of course, this PCB fits on top of the C3 and and plugs into its headers, so I have replicated the headers 2-3 times where possible, so for each signal you can get to it 2-3 times before soldering globs onto the same pin.
Finally, there are power indicators and large 220uF - 470uf caps on each power rail, so the add on board can pull a couple amps for an instant and not make the C3 crazy
So it's a prototype board - nice. The pinout of the headers is clear now.
Can you tell me also the Propeller pin numbers for MISO, MOSI and SCLK?
And for the Clock and Reset of the 161 counter? Then I should have all I need.
Sure, better yet, here's the pin map from the test suite:
'//////////////////////////////////////////////////////////////////////////////
' C3 PIN MAP DEFINES //////////////////////////////////////////////////////////
'//////////////////////////////////////////////////////////////////////////////
' status/debug pin also controls VGA buffer enable
STATUS_LED_BUS_MUX = 15 ' pin that controls VGA enable as well as a status/debug LED
' SPI pins
SPI_SEL_CLK = 8 ' used to clock the SPI counter that feeds 4-bit value to SPI selection decoder, clocks on rising edge
SPI_SEL_CLR = 25 ' used to clear the SPI counter back to 0000b (NULL SPI device), active LOW
SPI_MOSI = 9 ' SPI master out serial in to slave
SPI_MISO = 10 ' SPI master in serial out from slave, 10 for good C3, change to 7 for BROKEN C3 with YELLOW jumper.
SPI_SCK = 11 ' SPI clock from master to all slaves
' SPI (serial peripheral interface) interface pins, secondary names for SD driver functions
spiDO = 10
spiCLK = 11
spiDI = 9
' SPI channels defines
SPI_CHAN_NULL = 0 ' NULL channel, disables all on/off board devices.
SPI_CHAN_SRAM0 = 1 ' 32K SRAM Bank 0.
SPI_CHAN_SRAM1 = 2 ' 32K SRAM Bank 1.
SPI_CHAN_FLASH = 3 ' 1MB FLASH Memory.
SPI_CHAN_AD = 4 ' MCP3202 2-Channel 12-bit A/D.
SPI_CHAN_SD = 5 ' Micro SD Card.
' interface header SPI selects
SPI_CHAN_SPI6 = 6 ' Header Interface SPI6.
SPI_CHAN_SPI7 = 7 ' Header Interface SPI7.
' PS/2 port pin defines
PS2_DATA = 26 ' PS/2 port clock pin
PS2_CLK = 27 ' PS/2 data pin
' Port A pin defines
PORTA0 = 0
PORTA1 = 1
PORTA2 = 2
PORTA3 = 3
PORTA4 = 4
PORTA5 = 5
PORTA6 = 6
PORTA7 = 7
' Servo port 3-pin header output pins (shared with Port A P4..P7)
' note 1: each I/O pins is buffered thru a 50 ohm resistor to minimize long transmission line effects from cables
' note 2: each "servo" port has a 3 pin header [signal, power, ground], each power is feed from a jumper adjacent to the
' servo port and has a 22uF cap across it as a current source, thus the "servo" ports aside from using the servo 3-pin cable
' pin outs, CAN drive servos!!! Care must be taken not to sink too much current, if you find that the board resets under harsh
' conditions while driving multiple simulataneous servos then you can add a bulk 2200uF cap for energy storage. There are two holes
' pre-drilled by the 2.1mm power entry port, simply solder a 2200uF cap under or above the board, just make sure to get the polarity
' correct: minus to the left (next to left edge of board), plus to the right (next to switch).
SERVO_P4 = 4
SERVO_P5 = 5
SERVO_P6 = 6
SERVO_P7 = 7
' Port B pin defines (muxed with VGA port)
PORTB0 = 16
PORTB1 = 17
PORTB2 = 18
PORTB3 = 19
PORTB4 = 20
PORTB5 = 21
PORTB6 = 22
PORTB7 = 23
' VGA port pin defines
VGA_HSYNC = 16
VGA_VSYNC = 17
VGA_B0 = 18
VGA_B1 = 19
VGA_G0 = 20
VGA_G1 = 21
VGA_R0 = 22
VGA_R1 = 23
' NTSC/PAL composite video pin defines
COMPVID0 = 12
COMPVID1 = 13
COMPVID2 = 14
' Audio output pin define (PWM)
AUDIO_MONO = 24
' I2C pin defines (standard Prop pins)
I2C_SCL = 28
I2C_SDA = 29
' TX/RX pin defines (standard Prop pins)
UART_TX = 31
UART_RX = 30
No, its a very simple function, a few lines of code. IF you want more robust control then what you would do is create a global variable semaphore and then "check out" the bus do your thing and release it. Then any other consumers that require it can wait on the bus semaphore or try again later.
My goal with all the illustrative drivers and functions is to make them very simple, in SPIN, so you can understand what they do then if you want to get all jedi multicore with them then you can
Yes and no, those are from the USB UART perspective or DCE, so TX/RX on the Prop is 30/31 respectively, but I keep changing my mind on TX/RX since from the outside world, people are used to connecting TX/RX and RX/TX, and its always a toss up, should you call the SIGNAL name of what it is OR what should it connect to, since TX goes to RX, anyway -- they haven't figured it out in 50 years, doubt we will in the next
But, it all works, and those are just defines for convenience.
Yes and no, those are from the USB UART perspective or DCE, so TX/RX on the Prop is 30/31 respectively, but I keep changing my mind on TX/RX since from the outside world, people are used to connecting TX/RX and RX/TX, and its always a toss up, should you call the SIGNAL name of what it is OR what should it connect to, since TX goes to RX, anyway -- they haven't figured it out in 50 years, doubt we will in the next
But, it all works, and those are just defines for convenience.
Andre'
Just jumping in on thread and I will toss in my 2 cents worth. If a signal name is always what it's function is then the rest is up to how you want to connect it. A pin labeled TX should always be an output to be connected to anything you like or not but usually RX
I have my own pet peeves when it comes to how things are done (and should not be). Let's not help those who are determined to confuse everyone. A spade is a spade, not a garden.
Are there any more specifics or a feel of this project you can give us before the launch?
Is there any way to reverse the pins of the board for the NES controllers if you don't want the wires hanging over the board as in the first picture? How would that work with a case?
With the 64K Eprom, can the propeller see more video memory?
Comments
So, to put further reality on it, say we have a final unit cost of $40 @1000 units, we want to retail it at $80. 40% off that is $48, so we sell it to the distro art $48, he makes $32/unit, we make $8. And this is just the COGs (cost of goods), I haven't even factored in the development, sales, marketing costs and ammortize them over the products cost. So, that $8 is really more like $3-4 net. So, we break even at 10-20K units
This is why SOFTWARE is so attractive as a business, a 10 cent CD/DVD for $50-100, that's a profit margin that's unheard of. People that develop and manufacture embedded systems especially like we do for education are crazy, since we sure aren't getting rich that much is for certain
The moral of the story is anyone that really wants a taste of manufacturing, go out build a product, keep track of your time and expenses, then build 100 - 1000 of them which will require a debt finance on your part for the stock and or a huge amount of labor if you build them yourself. Then go try to sell them, again keep track of your time and money doing that, then when your shelf is empty, do a final computation of your total net profit versus, and total expenditures and time over the complete cycle of the product, and see if you made or lost money.
In most cases you will have lost money or made a tiny bit, thus the only way to make of "biz" is to have 100-200 products and make a couple bucks on each. Or to sell 1000's of a single product per month. And embedded systems for the education sector tend to sell dozens to 100's a month at most. 100's a month is a "best seller" basically. Far and few between.
Anyway, hopefully this and the other posts by Ken are enough "biz dev" for everyone and we can back to technical discussions about the C3
Andre'
The distributor margin issue is tough for me - A product could sell for much less direct, but then I wouldn't be able to sell enough to make it worthwhile (or even break even). There are easier ways to make money, but I love the hobby and love getting people excited about electronics.
Anyway - back to the C3; Product looks awesome! One question, just curious - is the board 2 layer or 4?
One of my techniques I use to route is to make screen captures of the board as I design, then pull them into photoshop then on other layers try "drawing" the traces, so I can create a number of traces and see "patterns" emerge without disturbing my design, then I take those ideas and alt-tab and implement them.
I just did a 6 layer GHZ board for a new medical imaging device I have been working on. That was very challenging in 4 layers, impossible in 2, nice in 6.
With the C3, I was more or less at the limit of 2 layers, anything more and you would definitely want to go to 4 layers. Also, the SMT stuff just kills you these days when it comes to routing, thru hole is so nice since you are on all layers for every signal, but I HATE punching vias down to get signals thru things, its so ghetto
Andre'
Ray
PUB SRAM_Init ( ... ) - initializes the SRAMs and sets them to sequential mode.
PUB SRAM_Write( ... ) - writes bytes of data from a buffer to either SRAM.
PUB SRAM_Fill( ... ) - fills either SRAM with a constant value.
PUB SRAM_Read( ... ) - reads data from either SRAM into a buffer.
PUB SRAM64K_MREAD( ... ) - models the pair of 32K SRAMs as a single memory of 64K and reads a byte from it.
PUB SRAM64K_MWRITE( ... ) - models the pair of 32K SRAMs as a single memory of 64K and writes a single byte to it.
' ///////////////////////////////////////////////////////////////////////////// ' SRAM API //////////////////////////////////////////////////////////////////// ' ///////////////////////////////////////////////////////////////////////////// PUB SRAM_Init ( mode ) | _spi_word {{ This function initializes both banks of the Microchip 23K256 SRAMs serial SPI SRAMs'. The initialization simply sets the STATUS register of each SRAM into "byte", "page" or "sequential" read/write mode to allow more efficient access of the SRAMs. The SRAM API currently relies on "sequential" mode, so if yoo want to use them, this function should be called with SPI_MODE_SEQUENTIAL The 23K256 supports a number of commands, we have only implemented a couple here in these API functions (single byte read/write, multiple byte read/write). However, there are many others you can implement, find out more by reviewing the chip specs and data sheets found here: [url]http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en539039[/url] [url]http://ww1.microchip.com/downloads/en/DeviceDoc/22100E.pdf[/url] PARMS: mode - %00_00000_1 = SPI_MODE_BYTE %10_00000_1 = SPI_MODE_PAGE %01_00000_1 = SPI_MODE_SEQUENTIAL RETURNS: Nothing. }} ' first set SRAM bank 0 to sequential access mode (see page 6 of data sheet) SPI_Select_Channel( SPI_CHAN_SRAM0 ) ' write status register command "sequential access mode" along with disable "HOLD" to setup SRAM for sequential reading/writing SPI_Write_Read( 16, %0000000_1 << 8 | mode , $FF ) ' now select SRAM bank 1 SPI_Select_Channel( SPI_CHAN_SRAM1 ) ' write status register command "sequential access mode" along with disable "HOLD" to setup SRAM for sequential reading/writing SPI_Write_Read( 16, %0000000_1 << 8 | mode , $FF ) ' and finally de-select all SPI devices SPI_Select_Channel( 0 ) ' end SRAM_Init ' ///////////////////////////////////////////////////////////////////////////// PUB SRAM_Write( bank, addr, num_bytes, src_buffer_ptr) | _index, _data, _spi_word {{ This function writes a number of bytes to either bank of the Microchip 23K256 serial SPI SRAMs' from a buffer. The 23K256 supports a number of commands, we have only implemented a couple here in these API functions (single byte read/write, multiple byte read/write). However, there are many others you can implement, find out more by reviewing the chip specs and data sheets found here: [url]http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en539039[/url] [url]http://ww1.microchip.com/downloads/en/DeviceDoc/22100E.pdf[/url] PARMS: bank - [0,1] the SRAM bank to write to, there are two banks, each holds 32K bytes addr - address in SRAM to write to [0...32767] num_bytes - number of bytes to write from source buffer to SRAM src_buffer_ptr - pointer to the buffer of bytes to write to SRAM RETURNS: number of bytes written }} ' test if there is anything to write? if (num_bytes => 1) ' select SPI channel for requested SRAM bank SPI_Select_Channel( SPI_CHAN_SRAM0 + bank ) ' set instruction word ( write sequential byte:8 | address:16 ) _spi_word := (%00000010 << 16) + (addr) ' and now send command to SRAM for sequential writing SPI_Write_Read( 24, _spi_word, $FF ) ' write the bytes into the SRAM repeat _index from 0 to num_bytes-1 ' get byte to write _data := byte[ src_buffer_ptr][ _index ] ' write the byte SPI_Write_Read( 8, _data, $FF ) ' de-select SRAM SPI channel SPI_Select_Channel( 0 ) ' return bytes written return( num_bytes ) else ' catch error return 0 ' end SRAM_Write ' ///////////////////////////////////////////////////////////////////////////// PUB SRAM_Fill( bank, addr, num_bytes, value) | _index, _data, _spi_word {{ This function writes a constant value to either bank of the Microchip 23K256 serial SPI SRAMs' from a buffer. The 23K256 supports a number of commands, we have only implemented a couple here in these API functions (single byte read/write, multiple byte read/write). However, there are many others you can implement, find out more by reviewing the chip specs and data sheets found here: [url]http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en539039[/url] [url]http://ww1.microchip.com/downloads/en/DeviceDoc/22100E.pdf[/url] PARMS: bank - [0,1] the SRAM bank to write to, there are two banks, each holds 32K bytes addr - address in SRAM to write to [0...32767] num_bytes - number of bytes to write from source buffer to SRAM value - byte value to write to SRAM RETURNS: number of bytes written }} ' test if there is anything to fill? if (num_bytes => 1) ' select SPI channel for requested SRAM bank SPI_Select_Channel( SPI_CHAN_SRAM0 + bank ) ' set instruction word ( write byte sequential:8 | address:16 ) _spi_word := (%00000010 << 16) + (addr) ' setup for sequential byte write, this includes the command and address only SPI_Write_Read( 24, _spi_word, $FF ) ' now the chip is ready to receive bytes (as many as we want to send) repeat _index from 0 to num_bytes-1 SPI_Write_Read( 8, value, $FF ) ' de-select SRAM channel SPI_Select_Channel( 0 ) ' return bytes written return( num_bytes ) else ' catch error return 0 ' end SRAM_Fill ' ///////////////////////////////////////////////////////////////////////////// PUB SRAM_Read(bank, addr, num_bytes, dest_buffer_ptr) | _index, _data, _spi_word {{ This function reads a number of bytes from either bank of the SRAM into a buffer. The 23K256 supports a number of commands, we have only implemented a couple here in these API functions (single byte read/write, multiple byte read/write). However, there are many others you can implement, find out more by reviewing the chip specs and data sheets found here: [url]http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en539039[/url] [url]http://ww1.microchip.com/downloads/en/DeviceDoc/22100E.pdf[/url] PARMS: bank - [0,1] the SRAM bank to read from, there are two banks, each holds 32K bytes addr - address in SRAM to read from [0..32767] num_bytes - number of bytes to read from SRAM into destination buffer dest_buffer_ptr - pointer to the buffer of bytes to read SRAM into RETURNS: number of bytes read }} ' test for anything to read? if (num_bytes => 1) ' select SPI channel for requested SRAM bank SPI_Select_Channel( SPI_CHAN_SRAM0 + bank ) ' set instruction word ( read byte sequential:8 | address:16 ) _spi_word := (%00000011 << 16) + (addr) ' setup for sequential byte read, this includes the command and address only SPI_Write_Read( 24, _spi_word, $FF ) ' now the chip is ready to be read from repeat _index from 0 to num_bytes-1 ' read next byte from SRAM into receiving buffer byte [dest_buffer_ptr][_index] := SPI_Write_Read( 8, $00, $FF ) ' de-select SRAM channel SPI_Select_Channel( 0 ) ' return bytes read return( num_bytes ) else ' catch error return 0 ' end SRAM_Read ' ///////////////////////////////////////////////////////////////////////////// PUB SRAM64K_MREAD( addr ) | _spi_word, _data {{ This function reads a single byte from either bank of the Microchip 23K256 serial SPI SRAMs'. This function is different from the SRAM_Read function in that it accesses the two banks of SRAM as a contiguous region of 64K bytes for you, and thus can be though of as a crude "array" access macro, rather than a function. Ultimately, this should be converted to ASM along with all the other important peripheral access methods. The 23K256 supports a number of commands, we have only implemented a couple here in these API functions (single byte read/write, multiple byte read/write). However, there are many others you can implement, find out more by reviewing the chip specs and data sheets found here: [url]http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en539039[/url] [url]http://ww1.microchip.com/downloads/en/DeviceDoc/22100E.pdf[/url] PARMS: addr - address in SRAMs to write to [0...65535]. RETURNS: The 8-bit data from the SRAM. }} ' the only tricky thing here is we need to take an address 0..65535 and then ' decide which bank it refers to and which byte in that bank, basically, some ' bit masking and shifts to accomplish this ' select SPI channel for requested SRAM bank SPI_Select_Channel( SPI_CHAN_SRAM0 + (addr >> 15) ) ' set instruction word ( read byte sequential:8 | address:16 | dummy:8 ) _spi_word := (%00000011 << 24) + (addr << 8) + 0 ' read the byte of data _data := SPI_Write_Read( 32, _spi_word, $FF ) ' de-select SRAM SPI channel SPI_Select_Channel( 0 ) ' return data return ( _data ) ' end SRAM64K_READ ' ///////////////////////////////////////////////////////////////////////////// PUB SRAM64K_MWRITE( addr, data ) | _spi_word {{ This function writes a single byte to either bank of the Microchip 23K256 serial SPI SRAMs'. This function is different from the SRAM_Write|Fill functions in that it accesses the two banks of SRAM as a contiguous region of 64K bytes for you, and thus can be though of as a crude "array" access macro, rather than a function. Ultimately, this should be converted to ASM along with all the other important peripheral access methods. The 23K256 supports a number of commands, we have only implemented a couple here in these API functions (single byte read/write, multiple byte read/write). However, there are many others you can implement, find out more by reviewing the chip specs and data sheets found here: [url]http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en539039[/url] [url]http://ww1.microchip.com/downloads/en/DeviceDoc/22100E.pdf[/url] PARMS: addr - address in SRAMs to write to [0...65535]. data - the byte to write. RETURNS: Nothing. }} ' the only tricky thing here is we need to take an address 0..65535 and then ' decide which bank it refers to and which byte in that bank, basically, some ' bit masking and shifts to accomplish this ' select SPI channel for requested SRAM bank SPI_Select_Channel( SPI_CHAN_SRAM0 + (addr >> 15) ) ' set instruction word ( write sequential byte:8 | address:16 | data: 8) _spi_word := (%00000010 << 24) + ( (addr & $7FFF) << 8) + data ' write the byte of data SPI_Write_Read( 32, _spi_word, $FF ) ' de-select SRAM SPI channel SPI_Select_Channel( 0 ) ' end SRAM64K_WRITEAndre'
I guess I didn't make myself clear enough. I'm at Job training for the Army. And its up to my commander what electronics I could have. I figured I could get away with a pre-made product but not sure if they would allow me to have a soldering Iron. I got plenty of equipment at home and several boards but there back in Ohio and I'm in Georga. Though I might ask my Sargent if I could have a soldering Iron.
Do you have any Ideas for a pre-assambled product that would have atleast an RCA out and hopefully under $100.
These hobbyists don't seem to have any idea of how much money it takes to put a product on the market.
Russ
http://www.parallax.com/Store/Microcontrollers/PropellerDevelopmentBoards/tabid/514/CategoryID/73/List/0/SortField/0/Level/a/ProductID/698/Default.aspx
They do let you have hookup wire on the base. :smilewinkgrin:
Jim
Andre'
Just FYI, boys prefer blue instead of pink
JM
Manual I. Quickstart (3) II. Hardware Overview. (1) - Power Management (3.3, 5V ) (2) - Propeller Processor (reset + eeprom) (2) - SPI Bus System (5) - Serial Communications (2) - Composite Video (2) - VGA Video (+buffer) (2) - Audio System (2) - PS/2 Keyboard/Mouse Port (1) - General IO Ports (2) - FLASH Memory System (2) - 32Kx2 SRAM Design (2) - A/D System (2) - Secure Digital (SD) Card Interface (1) III. Demos and API (10) LOCAL VERSION DEMOS PS/2 + NTSC monitor for each: Overview, Pic, files, output 1. Keyboard test. (1) 2. Mouse test. (1) 3. VGA test. (1) 4. Servo port test. (1) 5. Analog to digital test. (1) 6. SRAM test. (1) 7. NES game pad test. (1) 8. Port A/B test. (1) 9. FLASH memory test. (1) 10. Audio test. (1) 11. SD card test. (1) SERIAL VERSION DEMOS OVER UART for each: Overview, Pic, files, output 1. Servo port test. (1) 2. Analog to digital test. (1) 3. SRAM test. (1) 4. AD + SRAM test. (1) 5. NES game pad test. (1) 6. Port A/B test. (1) 7. FLASH memory test. (1) API Objects??? IV. Porting Applications from other Boards to C3 (3) - Demo Board - HYDRA - Samples Appendix I. Schematic II. Close up of PCBThat ADC chip on board is a much desired feature, as are many of the other ones.
This is a serial SRAM and, even though it's fast, access, particularly random access, has a lot of overhead. Block reads and writes are relatively fast since a byte is transferred in 8 clock cycles and the several bytes of overhead are amortized over the whole block transfer.
It STANDARDIZES a bunch of the existing technologies which are used in various Propeller projects! I always figured that Dad (Chip) would have step in and do this, but Uncle Andre' stepped to solve the problem!
Without having to fiddle with creating a dozen different designs to play with the exciting variations of cutting edge Propeller technology we can concentrate on pushing the envelope even further!!!
THANK YOU ANDRE! THANK YOU THANK YOU THANK YOU THANK YOU
THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU
THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU
THANK YOU THANK YOU THANK YOU
OBC
Andre'
P23...P16 is shared with the VGA port, but you can disconnect the VGA header from the IOs with a flip of a port IO bit.
Lastly, the analog port header top to bottom, analog in 0, 1, 5V, and gnd. Finally, to the left you see once again the "servo" ports these are heavily bypassed IO ports that can power a standard parallax servo, they share pins p7..p4.
And of course, this PCB fits on top of the C3 and and plugs into its headers, so I have replicated the headers 2-3 times where possible, so for each signal you can get to it 2-3 times before soldering globs onto the same pin.
Finally, there are power indicators and large 220uF - 470uf caps on each power rail, so the add on board can pull a couple amps for an instant and not make the C3 crazy
Andre'
So it's a prototype board - nice. The pinout of the headers is clear now.
Can you tell me also the Propeller pin numbers for MISO, MOSI and SCLK?
And for the Clock and Reset of the 161 counter? Then I should have all I need.
Thank you
Andy
Does SPI_Select_Channel block if a channel is selected in another cog? Or return a value indicating that the SPI is in use?
John Abshier
My goal with all the illustrative drivers and functions is to make them very simple, in SPIN, so you can understand what they do then if you want to get all jedi multicore with them then you can
Andre'
Shouldn't the UART_TX & UART_RX pins be reversed?
I refer to them as SI (P31) as serial in, and SO (P30) as serial out, which is more consistent with the prop definitions.
But, it all works, and those are just defines for convenience.
Andre'
Just jumping in on thread and I will toss in my 2 cents worth. If a signal name is always what it's function is then the rest is up to how you want to connect it. A pin labeled TX should always be an output to be connected to anything you like or not but usually RX
I have my own pet peeves when it comes to how things are done (and should not be). Let's not help those who are determined to confuse everyone. A spade is a spade, not a garden.
BTW, your board looks good.
Is there any way to reverse the pins of the board for the NES controllers if you don't want the wires hanging over the board as in the first picture? How would that work with a case?
With the 64K Eprom, can the propeller see more video memory?