64bit multiply and divide
Cncjerry
Posts: 64
Hello, new to the prop, but years on pic and recent arduino.
I need to do 64bit multiply and divide. I have assembler routines for AVR and PIC I can convert, I guess, but would rather keep the development all in C. I really only need 48bit and can send two bytes of zeros to the device to make the 64. I am clocking frequency to a DDS chip and it takes 64 bit input and the tuning word = (2^48 / clock ) * frequency. The clock is 180mhz on the DDS chip. I need to multiply the frequency by 2^48 first using integer to keep from losing bits, also it is just a shift so I guess I only need 64 bit divide. The code I used in the past was all 48 bit.
When I converted to the arduino, I found the LL (long long) data type and even that at 64bits took some screwing around to get working in integer.
Would GCC be an option? I looked at the assembler (after writing it 10 years ago) and can convert. I did the conversion once from PIC to AVR.
Jerry
I need to do 64bit multiply and divide. I have assembler routines for AVR and PIC I can convert, I guess, but would rather keep the development all in C. I really only need 48bit and can send two bytes of zeros to the device to make the 64. I am clocking frequency to a DDS chip and it takes 64 bit input and the tuning word = (2^48 / clock ) * frequency. The clock is 180mhz on the DDS chip. I need to multiply the frequency by 2^48 first using integer to keep from losing bits, also it is just a shift so I guess I only need 64 bit divide. The code I used in the past was all 48 bit.
When I converted to the arduino, I found the LL (long long) data type and even that at 64bits took some screwing around to get working in integer.
Would GCC be an option? I looked at the assembler (after writing it 10 years ago) and can convert. I did the conversion once from PIC to AVR.
Jerry
Comments
The bonus is that you can use SimpleIDE to show you the generated assembly language by right clicking on the filename.
Yes, the DDS clock is 180mhz in this case but can go to 300mhz. A typical use would be (10,000,000 * 2^48) / 180,000,000 which is 0x0E38E38E38E4, so 48 bits.
We have considered plans to make a library with the OBEX Spin/PASM COG code for use with Propeller GCC programs. A 64 bit version would be very welcome.
Thanks,
--Steve
#include <stdint.h> uint64_t mul64(uint64_t a, uint64_t b) { return a*b; }That's the type I use for the AVR unit64_t and I wrote the routines already so I guess I need to study the GCC implementation. This is great since the arduino compiler is GCC I believe. I assume I can kick-off cogs using the GCC compiler? That is the primary reason for switching. I want a cog for the DDS chip, the encoders, switches, joystick and LCD. The implementation today waits on the LCD updates which slows everything down. If I move the frequency changes to a cog then the response is better and the LCD can catch up.
Thanks
( and nobody I know in the rf worId uses mili hz vs mega hz M v m :-)
We are still working on more documents for explaining all the options for starting Propeller COGs - there are several ways to do it.
There is some information in the propgcc wiki and docs in the repository http://propgcc.googlecode.com/hg/doc/Library.html#Threads
The toggle demos show many of the different ways.
Please look here: http://code.google.com/p/propgcc/source/browse/#hg%2Fdemos%2Ftoggle
The next release will have support for "ecog" loading as demonstrated in the cog_loader demo.
Please look here: http://code.google.com/p/propgcc/source/browse/#hg%2Fdemos%2Fcog_loader
As for mHz ... I find the idea of pompous pedantic cats moderately amusing. :blank:
Since I have your attention, why do I get inconsistent results for (load ram vs load eprom) vs (load eprom and uplug usb and replug)? So I started with the Spin environment to get a handle on this chip and will be switching to C to solve the 64 bit divide / multiply (or recode the routines I have in assembler) . In the meantime, I can't get consistent results from the quickstart board in a development environment.
This simple code below is all indented correctly in that the repeat is followed by Delay, Y:= and If; under the If are the move, dec and Yold instructions. I have tried to visually align them as below. For some reason, if I add or remove the 'if' statement, I have to unplug the board and replug after loading eprom. I only figured this out after a lot of screwing around. I am using the quickstart board as I mentioned. So I have the main cog and two others. One reads buttons, another acts on the buttons and the main cog just looks at a variable, XXX, and then prints to the LCD, ideally if it is changed from a prior value. In this test, I only want to update the LCD if the returnded value in XXX (moved to Y) is below 9 and not equal to the prior value stored in Yold (which I removed for simplicity). So to be clear, if I remove the 'if' compile and load ram, it doesn't run. If I add or remove the 'if' compile and load eprom, it doesn't run unless I unplug the board, and replug. It could be something in the LCD routine but I know that stuff cold and all the timing looks fine. This is the last question on this topic and then I will move the future problems to new topics.
REPEAT 1000
DELAY.pause1ms(70)
Y:=XXX
if ( Y < 9 )
MOVE(1,2)
dec(Y)
Yold := Y
This is most likely because of a Quickstart feature. We have this all worked out in Spin and Propeller-GCC, but the software isn't there just yet AFAIK.
There may be other issues of course, but please try the suggestions below.
Until the software updates are released, try these:
- Most reliable:
- if you have a 10K ohm or greater resistor connect it as shown in the attachment
- Another possibility if you don't use P30 serial output
- Add DIRA[30] := 1 and OUTA[30] := 1
- Generally for now:
- Don't leave the Quickstart laying on a table or hold it in your hand while programming
- Position the board so that none of the 8 blue LEDs are on if they are not programmed.
For code formatting use code tags around your code: http://forums.parallax.com/misc.php?do=bbcode#codeGot most of it figured out. Tried the resistor, still not starting reliably. Could be just the LCD though I never had problems like this before with this LCD. Must be timing though I have it calculated right.
Setting this aside, the challenge I have mostly is debugging. I have both the lcd and serial setup to write debug messages but I wish I could single step and at least, look at memory. Maybe someone could point me at the state of the art in debugging.
I don't know why but I can't get consistency. Some of it I know is related to the quickstart board. I am thinking about just dumping it, getting a chip and building up a breadboard. I think there is a plug for USB and debugging i am going to look for tomorrow. This will take the resistive switches out of the loop.
Is there a PC (or mac) based emulator?
Thanks again.
Jerry
Hi Jerry,
I'm in San Jose - it may be worth trying to have a periodic Valley Propeller SIG Meetup considering the number of local users.
I suspect that maybe you just have a software issue now. Can you post your code as a .zip here so we can look for possibly obvious things. Even posting the main spin file here in the [ code ] tags as mentioned in the link I posted might help.
As far as Spin debuggers/emulators go, Dave Hein's spinsim can run spin/pasm programs on the PC. It allows console and file io with conio.spin and fileio.spin, but physical pin support is limited. Not sure where the latest full package is though ... Dave?
Here's a little test program:
[FONT=courier new]con[/FONT] [FONT=courier new] _clkmode = xtal1 + pll16x[/FONT] [FONT=courier new] _clkfreq = 80000000[/FONT] [FONT=courier new]obj[/FONT] [FONT=courier new] io : "conio.spin" ' simulated console io[/FONT] [FONT=courier new] pio : "fds.spin" ' real propeller console io[/FONT] [FONT=courier new] fio : "fileio.spin" ' simulated file io[/FONT] [FONT=courier new]pub main[/FONT] [FONT=courier new] io.str(string("Hello world",$d,$a))[/FONT] [FONT=courier new] repeat [/FONT]Attached is a package containing conio.spin, fds.spin, fileio.spin, bstc.exe, spinsim.exe, and user.txt.
The programs are compiled for windows - I can post mac versions of them too. See user.txt for a few simple steps for use.
There are other tools. Search for GEAR which has some plugins for tv, and ViewPort($) which has a spin debugger. I can't figure out either one of them. ymmv.
The only inconsistency left is the LCD doesn't always init even if I lengthen the "busy" routine which is not actually checking the busy state. Might have something to do with running it off less than 5v. I'll fix that later.
The biggest hang-up I have is not having a cog and/or hub memory dump. That would make things so much simpler. While I am griping, not having single instruction register bit operations is a little lame. Not to start a debate but I have a feeling the prop chip wasn't oriented towards low level conrol where you have a ton of pins with pwm and A/D converters. I really like the idea of asynchronous cogs since in my previous control system designs I typically used tertiary processors to handle button, lcd, encoders, etc. like I am trying to design here.
Lastly, the UI for assembly needs some work. I would be nice to have a button bar / toolbar.
BTW, someone metioned raspberry PI. I think mine, ordered on day one, just landed on my deck. I heard UPS up there. So now I will have the prop quickstart, arduino, pic and rPI on my desk. Getting hard to focus.
I wrote a PASM debugger that can do that ... there are others too. Please check the Propeller Resources Index sticky.
http://forums.parallax.com/showthread.php?111166-Propeller-Resource-Index&p=791527&viewfull=1#post791527
This has a link to my debugger.
http://forums.parallax.com/showthread.php?111166-Propeller-Resource-Index&p=1008959&viewfull=1#post1008959
I know how you feel. So many shiny things.