I am working with one of my boards that has two one megabit EEproms on it. I was wondering if the print$ code would be easy to point to the upper EEprom and maybe even expand it from 32k to 64k.
if you just want an equivalent to PRINT$ ( stringAddr -- ) then you can use this from Peter's EPRINT module
You store your strings 0 or 8-bit terminated to EEPROM and just print them with EPRINT$ ($ added for symmetry with PRINT$)
pub EPRINT$ ( EEaddr -- )
@EEWAIT EERD DROP
BEGIN 0 I2C@ DUP 9 $7E WITHIN WHILE EMIT REPEAT 1 I2C@ 2DROP I2CSTOP
;
A "one-liner" a driver does not make.......except in Tachyon Forth
I noticed that your stack comments were incorrect but since there could be 8 device addresses and we really want to read back a word and not 2 bytes then how about this:
$91 == @adc \ 90 is this device’s I2C base address
\ I2C read-only address is then 9B for default device %101
pub ADC@ ( addr -- data12 ) \ this is a 1 of 8 read-only device - returns with 12-bit ADC data
I2CSTART 2* @adc + I2C! 0 I2C@ 8 SHL 1 I2C@ + I2CSTOP
;
pub showit 5 ADC@ SPACE . ;
Hey Dave, are you going to show the rest of the project you are using this in??
A "one-liner" a driver does not make.......except in Tachyon Forth
I noticed that your stack comments were incorrect but since there could be 8 device addresses and we really want to read back a word and not 2 bytes then how about this:
$91 == @adc \ 90 is this device’s I2C base address
\ I2C read-only address is then 9B for default device %101
pub ADC@ ( addr -- data12 ) \ this is a 1 of 8 read-only device - returns with 12-bit ADC data
I2CSTART 2* @adc + I2C! 0 I2C@ 8 SHL 1 I2C@ + I2CSTOP
;
pub showit 5 ADC@ SPACE . ;
Hey Dave, are you going to show the rest of the project you are using this in??
Thanks for the tips, help. Here is Rev0 of a IO5500 module carrier board for the project, will update more soon. It does feature a 6-36v dual 3.3 5.0v switching power supply to the right of the IO5500 foot print.
Update of project with IO5500 Module split mount between board with all the fancy components and Tachyon lurking in the background.
Yes the next board gets more R for the LED, currently pulling 14ma and blindingly bright. Really impressed with the little switcher using the LT3509
The switcher may seem to be overkill but the the design is rated for 6-36V with 60V transients and rated for industrial/automotive use. Fully loaded the board area barley gets warm, really nice.
Update of project with IO5500 Module split mount between board with all the fancy components and Tachyon lurking in the background.
Yes the next board gets more R for the LED, currently pulling 14ma and blindingly bright. Really impressed with the little switcher using the LT3509
The switcher may seem to be overkill but the the design is rated for 6-36V with 60V transients and rated for industrial/automotive use. Fully loaded the board area barley gets warm, really nice.
Looks like it might look good....if you had a better shot of it that is Even if you leave your phone/camera on auto you can direct some stronger light onto the board which should look a lot better though I'd be inclined to go and change that LED resistor sooner before later.
So now I see what that small row of smd pads are for that I saw on your pcb preview. That's how you are getting access to the additional I/O on the Prop pitch castellations, great, that's the first time it's been used! Did they solder up easily enough?
For higher voltage switchers I've used the LM5010A which is rated at 75V in, 1A out, @1MHz. This is setup as 5V switcher as I prefer to always linear regulate from 5V down to 3.3V for a ripple free supply plus I can easily distribute linear regs where they are needed. I'd be interested to have a better look at the board to see how the LT3509 is implemented.
Do we get to hear about some other aspects of this project or is it "shop secret"?
I'm not a photographer and this is my first attempt at surface mount devices with help from my tutor doing most of the difficult work and me learning the art of solder paste without a stencil. I really like it and encourage all those who haven't tried surface mount to just give it a try.
The next board is for me to assemble completely, gads. I did buy one of those Chinese ovens, replaced the firmware with the Swiss stuff, replace the howling fan and added the hack of 1wire real thermocouple chips from TI. All told the over and hacks cost < 450.00. Can't wait to try it out, the new firmware is really nice and after replacing the masking tape with kapton that was used to shield the circuit board the mystery smell is gone.
Well the board is no shop secret but will be used to control various agriculture systems and mycology experiments in house. The board is not the most price conscious or optimized but the quality of the PCB is outstanding from oshpark.com
More to come after the software is finished up and translated to C++ for production quality and portability, ha ha ha ha, ha
oh and under that little switcher are 10 13 mil vias to sink heat to the other layer as per linear.
That LM5010A chip is nice and has fewer components. Of course you only get one voltage. The AC ripple on the 3.3 is < 2 ma.
I'm not a photographer and this is my first attempt at surface mount devices with help from my tutor doing most of the difficult work and me learning the art of solder paste without a stencil. I really like it and encourage all those who haven't tried surface mount to just give it a try.
The next board is for me to assemble completely, gads. I did buy one of those Chinese ovens, replaced the firmware with the Swiss stuff, replace the howling fan and added the hack of 1wire real thermocouple chips from TI. All told the over and hacks cost < 450.00. Can't wait to try it out, the new firmware is really nice and after replacing the masking tape with kapton that was used to shield the circuit board the mystery smell is gone.
Well the board is no shop secret but will be used to control various agriculture systems and mycology experiments in house. The board is not the most price conscious or optimized but the quality of the PCB is outstanding from oshpark.com
More to come after the software is finished up and translated to C++ for production quality and portability, ha ha ha ha, ha
oh and under that little switcher are 10 13 mil vias to sink heat to the other layer as per linear.
That LM5010A chip is nice and has fewer components. Of course you only get one voltage. The AC ripple on the 3.3 is < 2 ma.
I'm finding it easier these days to use those little 3-pin 7805T switching regulator replacements, they only cost around $2 and I place my MCP1700s close to where I need them for the 3.3V supplies. You can see one in-situ in the top right hand corner of the first pcb with one linear reg just below it for the CPU section and one down on the left for the comms and I/O. My own modules based on the LM5010A is shown in-situ in the lower left side of the second pcb with a picture of the board in the third shot which btw includes a 3.3V regulator on the module.
What I was curious about is how you are using the networking side of it. I mainly use it for FTP and Telnet but I am hoping to fire up some dynamic web content although I'd like to see what MJB comes up with to wow us
When the new forum becomes active we it might become a little easier to size these images:
I'm finding it easier these days to use those little 3-pin 7805T switching regulator replacements, they only cost around $2 and I place my MCP1700s close to where I need them for the 3.3V supplies. You can see one in-situ in the top right hand corner of the first pcb with one linear reg just below it for the CPU section and one down on the left for the comms and I/O. My own modules based on the LM5010A is shown in-situ in the lower left side of the second pcb with a picture of the board in the third shot which btw includes a 3.3V regulator on the module.
What I was curious about is how you are using the networking side of it. I mainly use it for FTP and Telnet but I am hoping to fire up some dynamic web content although I'd like to see what MJB comes up with to wow us
When the new forum becomes active we it might become a little easier to size these images:
Do you mean something similar to this at $8.12 quantity 1. Heck that LM chip was $7.00 alone not to mention the coils and all the rest, ouch! Also this one has much higher efficiency....
I'm a little concerned by the 3 Million Hours MTBF though, ha ha ha
And to rub it in so I don't forget those little MCP1700s are $0.31 cents quantity 1.
But but what about the beautiful layout that surely must be worth, ah heck forget it. Thanks for the pro tip.
Do you mean something similar to this at $8.12 quantity 1. Heck that LM chip was $7.00 alone not to mention the coils and all the rest, ouch! Also this one has much higher efficiency....
I'm a little concerned by the 3 Million Hours MTBF though, ha ha ha
And to rub it in so I don't forget those little MCP1700s are $0.31 cents quantity 1.
But but what about the beautiful layout that surely must be worth, ah heck forget it. Thanks for the pro tip.
$8.12 apiece, yikes! Those LT parts are nice for sure, though hardly ever economical. But your pcb layout looks good
The Recom 78E series is a lot cheaper and around $2.10 in reel quantities but only $2.79 one off. I can make my LM5010 design for about the same price, so why bother I say.
Don't forget too that the MCP1700 requires 1uF ceramics as well, and that adds another 2 cents apiece for those too!
BTW, the inductor I used with the LM5010A only cost me around 30 cents each.
What I was curious about is how you are using the networking side of it. I mainly use it for FTP and Telnet but I am hoping to fire up some dynamic web content although I'd like to see what MJB comes up with to wow us
Hi Peter,
I had a basically working version with dynamic pages and JSON connected to JS gauges with moving needles
on the old Spinneret W5100 version, which is shared with you and D.P.
as MJB-HTTP.fth
You tried it D.P. , didn't you?
But I could not get it to run on the updated W5100 code and gave up.
So it is there, but needs some cleanup and polishing - after it is working again.
Hi Peter,
I had a basically working version with dynamic pages and JSON connected to JS gauges with moving needles
on the old Spinneret W5100 version, which is shared with you and D.P.
as MJB-HTTP.fth
You tried it D.P. , didn't you?
But I could not get it to run on the updated W5100 code and gave up.
So it is there, but needs some cleanup and polishing - after it is working again.
Yes I was able to get it to run with the gauges on the 5100 but not with the 5500 as you state.
Really neat to have 1 cog gather the sensor data and the main cog display the data as dynamic JS gauges.
$8.12 apiece, yikes! Those LT parts are nice for sure, though hardly ever economical. But your pcb layout looks good
The Recom 78E series is a lot cheaper and around $2.10 in reel quantities but only $2.79 one off. I can make my LM5010 design for about the same price, so why bother I say.
Don't forget too that the MCP1700 requires 1uF ceramics as well, and that adds another 2 cents apiece for those too!
BTW, the inductor I used with the LM5010A only cost me around 30 cents each.
There's also the Murata OKI-78SR-5 series, which is a little more expensive($4.30 for 1, $3.78 qty 100), but for higher current (1.5A).
@Ding-Batty: Yeah, I've got those too although they are a bit tall for some designs, the Murata part also has a slightly higher input voltage rating which is also useful.
@MJB & D.P: I will have to see what the problem is with the W5500 then although I feel it must be very minor, which means it may take some time to find
@MJB & D.P: I will have to see what the problem is with the W5500 then although I feel it must be very minor, which means it may take some time to find
I am not sure it is a problem with the W5500 - could not test it there yet.
In porting my working version of the dynamic webserver from the old W5100 / Spinneret /EASYNET
to the updated W5100 / EASYNET I encountered problems I could not solve without debugging
deep inside the low level NW/W5100 code
and gave up after several unsuccessful attempts.
Just a little driver to use the inexpensive DS1302 RTC modules (1.49ea with battery qty 10) and set the TACHYON RTC routines.
Uses the same syntax as the TACHYON RTC routines i.e
150429 DATE! --- tachyon rtc set date to YYMMDD
150429 DSDATE! --- set the DS1302 date
130100 TIME! --- tachyon rtc set time HHMMSS 24hr
130100 DSTIME! --- you get the picture by now
Also includes words to SET RAM (DSSETRAM) and GET RAM ( DSGETRAM ) to read and write the battery backed ram.
One last word SETDST reads the DS1302 Date and Time and sets the RTC routines in tachyon, great for boot up sync from a cheap time source.
Just use the EEPROM I2C lines and one extra pin for Chip Enable.
Just a little driver to use the inexpensive DS1302 RTC modules (1.49ea with battery qty 10) and set the TACHYON RTC routines.
Uses the same syntax as the TACHYON RTC routines i.e
150429 DATE! --- tachyon rtc set date to YYMMDD
150429 DSDATE! --- set the DS1302 date
130100 TIME! --- tachyon rtc set time HHMMSS 24hr
130100 DSTIME! --- you get the picture by now
Also includes words to SET RAM (DSSETRAM) and GET RAM ( DSGETRAM ) to read and write the battery backed ram.
One last word SETDST reads the DS1302 Date and Time and sets the RTC routines in tachyon, great for boot up sync from a cheap time source.
Just use the EEPROM I2C lines and one extra pin for Chip Enable.
That's good David, using the I2C lines on SPI chips is sensible as the DS1302 clocks data out on the trailing edge, so it's not possible for it to generate conditions that are seen as START and STOP by other I2C devices on the same bus.
Oh, and good to see you are being logical and rebelling against tradition by using YYMMDD
There is probably no need to have special RTC words as the soft RTC in Tachyon is meant to be bypassed as soon as an RTC driver is added. In fact, this might be a good place to use revectoring as any existing words that reference the soft RTC can automatically use the new driver.
REVECTOR DATE! DSDATE!
etc
BTW, I think we have a little line-up of RTCs that have been used with Tachyon:
That's good David, using the I2C lines on SPI chips is sensible as the DS1302 clocks data out on the trailing edge, so it's not possible for it to generate conditions that are seen as START and STOP by other I2C devices on the same bus.
Oh, and good to see you are being logical and rebelling against tradition by using YYMMDD
Well there must be a good reason for this format. I would like to create some general words for comparing times for scheduling etc, wondering if you convert to BCD to do the "math"?
Well there must be a good reason for this format. I would like to create some general words for comparing times for scheduling etc, wondering if you convert to BCD to do the "math"?
BCD is fine for calculators and 4-bit CPUs, we don't want none of that nonsense around here!
Since dates and times are numerically ordered there is no problem doing direct comparisons. Have you seen the scheduling I do for electric gate timer? The schedule is a readable list that I can load into the unit like this:
SCHEDULE
08.00 AM DAILY WILL OPEN
10.00 PM DAILY WILL CLOSE --- ensure gates are closed by now
07.00 PM MON WILL CLOSE
07.45 PM SAT WILL CLOSE
07.00 PM SUN WILL CLOSE
05.30 PM TUE WILL OPEN
05.30 PM WED WILL OPEN
05.30 PM THU WILL OPEN
08.00 AM 4 JUL WILL CLOSE --- don't bother opening (overrides any previous schedule opening)
08.00 AM 25 DEC WILL CLOSE
15 AUTOCLOSE --- will close automatically 15 mins after remotely opened
DONE
BCD is fine for calculators and 4-bit CPUs, we don't want none of that nonsense around here!
Since dates and times are numerically ordered there is no problem doing direct comparisons. Have you seen the scheduling I do for electric gate timer? The schedule is a readable list that I can load into the unit like this:
SCHEDULE
08.00 AM DAILY WILL OPEN
10.00 PM DAILY WILL CLOSE --- ensure gates are closed by now
07.00 PM MON WILL CLOSE
07.45 PM SAT WILL CLOSE
07.00 PM SUN WILL CLOSE
05.30 PM TUE WILL OPEN
05.30 PM WED WILL OPEN
05.30 PM THU WILL OPEN
08.00 AM 4 JUL WILL CLOSE --- don't bother opening (overrides any previous schedule opening)
08.00 AM 25 DEC WILL CLOSE
15 AUTOCLOSE --- will close automatically 15 mins after remotely opened
DONE
The resources link for the EGATE doc say is it not published?
Update: EGATE.fth is in the dropbox under apps though but I don't see the SCHEDULE code in that file.
I've been busy writing a MODBUS RTU slave in Tachyon Forth. Anyone have a recommendation for a good simulator, especially if it runs in Linux? ModbusPal would work except it needs rxtx which doesn't seem to be available and I've tried several others.
I've been busy writing a MODBUS RTU slave in Tachyon Forth. Anyone have a recommendation for a good simulator, especially if it runs in Linux? ModbusPal would work except it needs rxtx which doesn't seem to be available and I've tried several others.
Nice,
Are you implementing Serial, TCP or RTU. Or all three Can I ask what you are gonna stick on the bus?
Are you implementing Serial, TCP or RTU. Or all three Can I ask what you are gonna stick on the bus?
I've done these before but now I am implementing serial RTU (mainly RS485) in Tachyon Forth. I've decided that the easier way to handle MODBUS start-of-packet address and end-of-packet timeout is just that, let the packet timeout before processing so that the listen routine doesn't worry anymore, it just assumes that the first character received is the address. The code is looking very simple and it makes it very easy to patch in new or edited MODBUS functions at runtime too. At present I am testing with a simple serial routines running in the same cog as the MODBUS task.
I have a customer who wants to use one of my Prop products as remote flow/valve I/O in irrigation systems.
I've done these before but now I am implementing serial RTU (mainly RS485) in Tachyon Forth. I've decided that the easier way to handle MODBUS start-of-packet address and end-of-packet timeout is just that, let the packet timeout before processing so that the listen routine doesn't worry anymore, it just assumes that the first character received is the address. The code is looking very simple and it makes it very easy to patch in new or edited MODBUS functions at runtime too. At present I am testing with a simple serial routines running in the same cog as the MODBUS task.
I have a customer who wants to use one of my Prop products as remote flow/valve I/O in irrigation systems.
I just worked my way though a Tachyon application to run an Aquaponics System, 453 lines of pure state machine logic. While probably not the prettiest (at times I was about to give up) now that it's working it is such a joy to tweak and show the customer, flashy things, buzzer things LCDs oh my.
Next I'll squeeze in some TCP/IP magic and SD Card Logging!
While it was not an easy hill to learn Forth and Tachyon to be productive I'm so glad to have gone to the light. Now if I could only get that FFT to work in Tachyon, for Heater if your viewing
\ mcp1308 stuff PPDB
--- IFNDEF =miso \ Define I/O lines if not already defined
#12 |< CONSTANT =mcp \ Select mcp3208 chip
#09 |< CONSTANT =sck \ SCK mask
#11 |< CONSTANT =mosi \ MOSI
#10 |< CONSTANT =miso \ MISO data
--- }
\ Send a command to the MCP3208 and read back 12-bits of data
pub ADC@ ( ch -- data )
\ First 5 msbs are [start,s/d,d2,d1,0] then 3 dummy clocks and then 12 bits of data are read in
\ SPIO mode clocks msb first and left shifts new data into lsbs
=mosi OUTCLR \ MOSI output
=sck OUTCLR \ clock output
$18 OR \ Start bit + single mode
#27 REV \ flip around for slow right shift
=mosi SWAP \ Setup up output mask for SHROUT instruction ( iomask data -- iomask data/2)
=mcp OUTCLR \ select MCP3208 chip
8 FOR \ just shift out the instruction first + dummy clocks
SHROUT \ shift out a bit
=sck OUTSET \ clock it
=sck OUTCLR
NEXT
DROP \ discard data
INPUTS \ float mosi (allows mosi and miso to share the same I/O)
=miso 0 \ setup input mask and data
#12 FOR \ get data bits
SHRINP \ read and shift in next data bit
=sck OUTSET \ clock it
=sck OUTCLR
NEXT
NIP \ discard input mask
=mcp OUTSET \ deselect
#20 SHR \ right justify data
#20 REV \ flip msb<>lsb
;
Hmmm, looks like the code is a bit old and a few little things have changed although I'd probably like to change it again to standardize it a little bit more. However here is the revised snippet which should work, I've also updated the Google docs version as there is also one slight change in SETPINS.
\ Init the ADC using the pins specified
pub !ADC ( &pins -- ) \ long encoded pin descriptor &1 (i.e. &00.01.02.03)
DUP MODPINS \ set pin masks although chip select needs to be set elsewhere
#19 3 COGREG! \ Set bit count as 5 control bits, 2 dummy, 12 data
#24 SHR MASK ' #adc 1+ ! \ set mask for adc chip select
[SPIOD] \ Use SPIOD module (programmable delay) in VM kernel
1 4 COGREG! \ delay to slow down to 2Mhz = 100ksps
#adc OUTSET \ chip select high
;
For instance, using the information you supplied you would use:
&12.10.11.09 !ADC
Just rebuilt from google docs both Tachyon and Extend, No Joy. Bit bang code does work still with latest build.
?
Guess it's time for my little logic analyzer.
I will try a chip on there a little later to find out what's going on. There was a change in SETPINS from "3 >" to "2 >" which made sure that the clock and mosi were set to outputs. You can check with an lsio if that is so. A scope is normally fine to check this with, just leave one trace on the clock and check the other signals as you go. I've got one of those DigView logic analysers which aren't too bad at all.
Tachyon is really fast and unconventional. Could I get a simple description of the actions of this definition, it will help me congeal my understanding of Tachyon's language extension technique.
Tachyon is really fast and unconventional. Could I get a simple description of the actions of this definition, it will help me congeal my understanding of Tachyon's language extension technique.
Using the example:
ALIAS { {HELP \ preferred form to be compatible with Kernel source compiled through Prop Spin compiler
[COMPILE] is an immediate word and forces the next word in the text stream to compile even if it's immediate
NFA' at runtime will read in the next word in the text stream and find the Name Field Address of that word "{" if it exists, leaving the address (or zero) on the stack
GRAB forces the temporary compiled code to execute so as to "grab" any compiled parameters and put them on the stack. Because TF always compiles.
C@++ + will fetch the first byte of the Name Field which is the string length and also increment the fetch address to point to the string then add the length to the string to point to the attribute byte. NFA' { 10 DUMP
0000_6F9E: 01 7B A2 C4 0B 01 7D A2 11 0F 06 49 46 4E 44 45 .{....}....IFNDE ok
CREATEWORD reads in the next word in the text stream at runtime (which is {HELP) and creates a header for that in the dictionary
@HATR (at Header Attribute) returns with the pointer to the latest header attribute (so the new entry for {HELP)
3 CMOVE then copies 3 bytes using the source address of the "{" attribute field and the destination address for the {HELP attribute field.
So this simply replaces the new header with the attribute and code field bytes from the old header which makes the new word behave exactly like the old word.
There are times that I wish that TF didn't compile everything but it's more of an advantage that it does than a disadvantage plus it means I don't need to dedicate a TIB text input buffer for the longest line I need to read plus it compiles each word as soon as it encounters it which is faster. So I have work arounds such as GRAB for want of a better name to make all the preceding words execute although most of the time this is to grab parameters and put them onto the stack for other immediate words to use.
Comments
if you just want an equivalent to PRINT$ ( stringAddr -- ) then you can use this from Peter's EPRINT module
You store your strings 0 or 8-bit terminated to EEPROM and just print them with EPRINT$ ($ added for symmetry with PRINT$)
pub EPRINT$ ( EEaddr -- ) @EEWAIT EERD DROP BEGIN 0 I2C@ DUP 9 $7E WITHIN WHILE EMIT REPEAT 1 I2C@ 2DROP I2CSTOP ;MCP3221 ADC Doc
A "one-liner" a driver does not make.......except in Tachyon Forth
I noticed that your stack comments were incorrect but since there could be 8 device addresses and we really want to read back a word and not 2 bytes then how about this:
$91 == @adc \ 90 is this device’s I2C base address \ I2C read-only address is then 9B for default device %101 pub ADC@ ( addr -- data12 ) \ this is a 1 of 8 read-only device - returns with 12-bit ADC data I2CSTART 2* @adc + I2C! 0 I2C@ 8 SHL 1 I2C@ + I2CSTOP ; pub showit 5 ADC@ SPACE . ;Hey Dave, are you going to show the rest of the project you are using this in??
Thanks for the tips, help. Here is Rev0 of a IO5500 module carrier board for the project, will update more soon. It does feature a 6-36v dual 3.3 5.0v switching power supply to the right of the IO5500 foot print.
Yes the next board gets more R for the LED, currently pulling 14ma and blindingly bright. Really impressed with the little switcher using the LT3509
The switcher may seem to be overkill but the the design is rated for 6-36V with 60V transients and rated for industrial/automotive use. Fully loaded the board area barley gets warm, really nice.
Looks like it might look good....if you had a better shot of it that is
So now I see what that small row of smd pads are for that I saw on your pcb preview. That's how you are getting access to the additional I/O on the Prop pitch castellations, great, that's the first time it's been used! Did they solder up easily enough?
For higher voltage switchers I've used the LM5010A which is rated at 75V in, 1A out, @1MHz. This is setup as 5V switcher as I prefer to always linear regulate from 5V down to 3.3V for a ripple free supply plus I can easily distribute linear regs where they are needed. I'd be interested to have a better look at the board to see how the LT3509 is implemented.
Do we get to hear about some other aspects of this project or is it "shop secret"?
The next board is for me to assemble completely, gads. I did buy one of those Chinese ovens, replaced the firmware with the Swiss stuff, replace the howling fan and added the hack of 1wire real thermocouple chips from TI. All told the over and hacks cost < 450.00. Can't wait to try it out, the new firmware is really nice and after replacing the masking tape with kapton that was used to shield the circuit board the mystery smell is gone.
Well the board is no shop secret but will be used to control various agriculture systems and mycology experiments in house. The board is not the most price conscious or optimized but the quality of the PCB is outstanding from oshpark.com
More to come after the software is finished up and translated to C++ for production quality and portability, ha ha ha ha, ha
oh and under that little switcher are 10 13 mil vias to sink heat to the other layer as per linear.
That LM5010A chip is nice and has fewer components. Of course you only get one voltage. The AC ripple on the 3.3 is < 2 ma.
I'm finding it easier these days to use those little 3-pin 7805T switching regulator replacements, they only cost around $2 and I place my MCP1700s close to where I need them for the 3.3V supplies. You can see one in-situ in the top right hand corner of the first pcb with one linear reg just below it for the CPU section and one down on the left for the comms and I/O. My own modules based on the LM5010A is shown in-situ in the lower left side of the second pcb with a picture of the board in the third shot which btw includes a 3.3V regulator on the module.
What I was curious about is how you are using the networking side of it. I mainly use it for FTP and Telnet but I am hoping to fire up some dynamic web content although I'd like to see what MJB comes up with to wow us
When the new forum becomes active we it might become a little easier to size these images:
Do you mean something similar to this at $8.12 quantity 1. Heck that LM chip was $7.00 alone not to mention the coils and all the rest, ouch! Also this one has much higher efficiency....
I'm a little concerned by the 3 Million Hours MTBF though, ha ha ha
And to rub it in so I don't forget those little MCP1700s are $0.31 cents quantity 1.
But but what about the beautiful layout that surely must be worth, ah heck forget it. Thanks for the pro tip.
Recom 78 Series
$8.12 apiece, yikes! Those LT parts are nice for sure, though hardly ever economical. But your pcb layout looks good
The Recom 78E series is a lot cheaper and around $2.10 in reel quantities but only $2.79 one off. I can make my LM5010 design for about the same price, so why bother I say.
Don't forget too that the MCP1700 requires 1uF ceramics as well, and that adds another 2 cents apiece for those too!
BTW, the inductor I used with the LM5010A only cost me around 30 cents each.
I had a basically working version with dynamic pages and JSON connected to JS gauges with moving needles
on the old Spinneret W5100 version, which is shared with you and D.P.
as MJB-HTTP.fth
You tried it D.P. , didn't you?
But I could not get it to run on the updated W5100 code and gave up.
So it is there, but needs some cleanup and polishing - after it is working again.
Yes I was able to get it to run with the gauges on the 5100 but not with the 5500 as you state.
Really neat to have 1 cog gather the sensor data and the main cog display the data as dynamic JS gauges.
Let me know how I can help debug et al.
There's also the Murata OKI-78SR-5 series, which is a little more expensive($4.30 for 1, $3.78 qty 100), but for higher current (1.5A).
@MJB & D.P: I will have to see what the problem is with the W5500 then although I feel it must be very minor, which means it may take some time to find
In porting my working version of the dynamic webserver from the old W5100 / Spinneret /EASYNET
to the updated W5100 / EASYNET I encountered problems I could not solve without debugging
deep inside the low level NW/W5100 code
and gave up after several unsuccessful attempts.
Just a little driver to use the inexpensive DS1302 RTC modules (1.49ea with battery qty 10) and set the TACHYON RTC routines.
Uses the same syntax as the TACHYON RTC routines i.e
150429 DATE! --- tachyon rtc set date to YYMMDD
150429 DSDATE! --- set the DS1302 date
130100 TIME! --- tachyon rtc set time HHMMSS 24hr
130100 DSTIME! --- you get the picture by now
Also includes words to SET RAM (DSSETRAM) and GET RAM ( DSGETRAM ) to read and write the battery backed ram.
One last word SETDST reads the DS1302 Date and Time and sets the RTC routines in tachyon, great for boot up sync from a cheap time source.
Just use the EEPROM I2C lines and one extra pin for Chip Enable.
DS1302mini.fth
That's good David, using the I2C lines on SPI chips is sensible as the DS1302 clocks data out on the trailing edge, so it's not possible for it to generate conditions that are seen as START and STOP by other I2C devices on the same bus.
Oh, and good to see you are being logical and rebelling against tradition by using YYMMDD
There is probably no need to have special RTC words as the soft RTC in Tachyon is meant to be bypassed as soon as an RTC driver is added. In fact, this might be a good place to use revectoring as any existing words that reference the soft RTC can automatically use the new driver.
REVECTOR DATE! DSDATE!
etc
BTW, I think we have a little line-up of RTCs that have been used with Tachyon:
1. DS1302 -SPI
2. PCF8563 - I2C
3. MCP79410 - I2C (very cheap)
4. DS3231 - I2C
5. S-35290A - I2C (mangled)
Well there must be a good reason for this format. I would like to create some general words for comparing times for scheduling etc, wondering if you convert to BCD to do the "math"?
BCD is fine for calculators and 4-bit CPUs, we don't want none of that nonsense around here!
Since dates and times are numerically ordered there is no problem doing direct comparisons. Have you seen the scheduling I do for electric gate timer? The schedule is a readable list that I can load into the unit like this:
The resources link for the EGATE doc say is it not published?
Update: EGATE.fth is in the dropbox under apps though but I don't see the SCHEDULE code in that file.
Sorry, fixed that now. EGATE.fth
I've been busy writing a MODBUS RTU slave in Tachyon Forth. Anyone have a recommendation for a good simulator, especially if it runs in Linux? ModbusPal would work except it needs rxtx which doesn't seem to be available and I've tried several others.
Nice,
Are you implementing Serial, TCP or RTU. Or all three
I've done these before but now I am implementing serial RTU (mainly RS485) in Tachyon Forth. I've decided that the easier way to handle MODBUS start-of-packet address and end-of-packet timeout is just that, let the packet timeout before processing so that the listen routine doesn't worry anymore, it just assumes that the first character received is the address. The code is looking very simple and it makes it very easy to patch in new or edited MODBUS functions at runtime too. At present I am testing with a simple serial routines running in the same cog as the MODBUS task.
I have a customer who wants to use one of my Prop products as remote flow/valve I/O in irrigation systems.
I just worked my way though a Tachyon application to run an Aquaponics System, 453 lines of pure state machine logic. While probably not the prettiest (at times I was about to give up) now that it's working it is such a joy to tweak and show the customer, flashy things, buzzer things LCDs oh my.
Next I'll squeeze in some TCP/IP magic and SD Card Logging!
While it was not an easy hill to learn Forth and Tachyon to be productive I'm so glad to have gone to the light. Now if I could only get that FFT to work in Tachyon, for Heater if your viewing
Thank you Peter for Tachyon.
The code shows &01.02.03.04
Can anyone confirm this is clk.miso.mosi.cs ?
I'm just not getting expected results, thanks.
update, I found cs so so far CS.MISO.MOSI.CLK?
Chip is good because this code works
\ mcp1308 stuff PPDB --- IFNDEF =miso \ Define I/O lines if not already defined #12 |< CONSTANT =mcp \ Select mcp3208 chip #09 |< CONSTANT =sck \ SCK mask #11 |< CONSTANT =mosi \ MOSI #10 |< CONSTANT =miso \ MISO data --- } \ Send a command to the MCP3208 and read back 12-bits of data pub ADC@ ( ch -- data ) \ First 5 msbs are [start,s/d,d2,d1,0] then 3 dummy clocks and then 12 bits of data are read in \ SPIO mode clocks msb first and left shifts new data into lsbs =mosi OUTCLR \ MOSI output =sck OUTCLR \ clock output $18 OR \ Start bit + single mode #27 REV \ flip around for slow right shift =mosi SWAP \ Setup up output mask for SHROUT instruction ( iomask data -- iomask data/2) =mcp OUTCLR \ select MCP3208 chip 8 FOR \ just shift out the instruction first + dummy clocks SHROUT \ shift out a bit =sck OUTSET \ clock it =sck OUTCLR NEXT DROP \ discard data INPUTS \ float mosi (allows mosi and miso to share the same I/O) =miso 0 \ setup input mask and data #12 FOR \ get data bits SHRINP \ read and shift in next data bit =sck OUTSET \ clock it =sck OUTCLR NEXT NIP \ discard input mask =mcp OUTSET \ deselect #20 SHR \ right justify data #20 REV \ flip msb<>lsb ;Hmmm, looks like the code is a bit old and a few little things have changed although I'd probably like to change it again to standardize it a little bit more. However here is the revised snippet which should work, I've also updated the Google docs version as there is also one slight change in SETPINS.
\ Init the ADC using the pins specified pub !ADC ( &pins -- ) \ long encoded pin descriptor &1 (i.e. &00.01.02.03) DUP MODPINS \ set pin masks although chip select needs to be set elsewhere #19 3 COGREG! \ Set bit count as 5 control bits, 2 dummy, 12 data #24 SHR MASK ' #adc 1+ ! \ set mask for adc chip select [SPIOD] \ Use SPIOD module (programmable delay) in VM kernel 1 4 COGREG! \ delay to slow down to 2Mhz = 100ksps #adc OUTSET \ chip select high ;For instance, using the information you supplied you would use:
&12.10.11.09 !ADC
?
Guess it's time for my little logic analyzer.
I will try a chip on there a little later to find out what's going on. There was a change in SETPINS from "3 >" to "2 >" which made sure that the clock and mosi were set to outputs. You can check with an lsio if that is so. A scope is normally fine to check this with, just leave one trace on the clock and check the other signals as you go. I've got one of those DigView logic analysers which aren't too bad at all.
Thanks
Using the example:
ALIAS { {HELP \ preferred form to be compatible with Kernel source compiled through Prop Spin compiler
[COMPILE] is an immediate word and forces the next word in the text stream to compile even if it's immediate
NFA' at runtime will read in the next word in the text stream and find the Name Field Address of that word "{" if it exists, leaving the address (or zero) on the stack
GRAB forces the temporary compiled code to execute so as to "grab" any compiled parameters and put them on the stack. Because TF always compiles.
C@++ + will fetch the first byte of the Name Field which is the string length and also increment the fetch address to point to the string then add the length to the string to point to the attribute byte.
NFA' { 10 DUMP
0000_6F9E: 01 7B A2 C4 0B 01 7D A2 11 0F 06 49 46 4E 44 45 .{....}....IFNDE ok
CREATEWORD reads in the next word in the text stream at runtime (which is {HELP) and creates a header for that in the dictionary
@HATR (at Header Attribute) returns with the pointer to the latest header attribute (so the new entry for {HELP)
3 CMOVE then copies 3 bytes using the source address of the "{" attribute field and the destination address for the {HELP attribute field.
Header for the { word
[font=courier] LEN { ATR CODE BYTES 0000_6F9E: 01 7B A2 C4 0B [/font]So this simply replaces the new header with the attribute and code field bytes from the old header which makes the new word behave exactly like the old word.There are times that I wish that TF didn't compile everything but it's more of an advantage that it does than a disadvantage plus it means I don't need to dedicate a TIB text input buffer for the longest line I need to read plus it compiles each word as soon as it encounters it which is faster. So I have work arounds such as GRAB for want of a better name to make all the preceding words execute although most of the time this is to grab parameters and put them onto the stack for other immediate words to use.